rfc9483.original.xml		rfc9483.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='utf-8'?>
	<!-- This ID was written based on the davies-template-bare-06.xml
	available on https://tools.ietf.org/tools/templates/
	The template was designed for creating an Internet Draft using xml2rfc,
	which is available here: http://xml.resource.org . -->
	<!-- <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> -->
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!-- declare nbsp and friends -->		<!ENTITY nbsp "&#160;">
	<!ENTITY nbsp "&#xa0;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#x2011;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#x2060;">		<!ENTITY wj "&#8288;">
	]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>		]>
	<!-- For a complete list and description of processing instructions (PIs),
	please see http://xml.resource.org/authoring/README.html. -->
	<?rfc strict="yes" ?>
	<?rfc toc="yes"?>
	<?rfc tocdepth="4"?>
	<!-- the number of levels of subsections in ToC. default: 3 -->
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes" ?>
	<?rfc compact="yes" ?>
	<?rfc subcompact="no" ?>
	<?rfc iprnotified="no" ?>
	<!-- end of list of popular I-D processing instructions -->
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude"		<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
	category="std"		category="std"
	consensus="true"		consensus="true"
			number="9483"
	docName="draft-ietf-lamps-lightweight-cmp-profile-21"		docName="draft-ietf-lamps-lightweight-cmp-profile-21"
	ipr="trust200902"		ipr="trust200902"
	obsoletes=""		obsoletes=""
	updates=""		updates=""
	submissionType="IETF"		submissionType="IETF"
	xml:lang="en"		xml:lang="en"
	tocInclude="true"		tocInclude="true"
	tocDepth="4"		tocDepth="4"
	symRefs="true"		symRefs="true"
	sortRefs="true"		sortRefs="true"
	version="3">		version="3">
	<!-- xml2rfc v2v3 conversion 3.5.0 -->		<!-- xml2rfc v2v3 conversion 3.5.0 -->
	<front>		<front>
	<title abbrev="Lightweight CMP Profile">Lightweight Certificate Management P		<title abbrev="LCMPP">Lightweight Certificate Management Protocol (CMP) Prof
	rotocol (CMP) Profile</title>		ile</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-lightweight-cmp-pr		<seriesInfo name="RFC" value="9483"/>
	ofile-21"/>
	<!-- add 'role="editor"' below for the editors if appropriate -->
	<!-- Another author who claims to be an editor -->
	<author fullname="Hendrik Brockhaus" initials="H." surname="Brockhaus">		<author fullname="Hendrik Brockhaus" initials="H." surname="Brockhaus">
	<organization abbrev="Siemens">Siemens</organization>		<organization abbrev="Siemens">Siemens</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Werner-von-Siemens-Strasse 1</street>		<street>Werner-von-Siemens-Strasse 1</street>
	<code>80333</code>		<code>80333</code>
	<city>Munich</city>		<city>Munich</city>
	<country>Germany</country>		<country>Germany</country>
	</postal>		</postal>
	<email>hendrik.brockhaus@siemens.com</email>		<email>hendrik.brockhaus@siemens.com</email>
	skipping to change at line 84 ¶		skipping to change at line 67 ¶
	<postal>		<postal>
	<street>Werner-von-Siemens-Strasse 1</street>		<street>Werner-von-Siemens-Strasse 1</street>
	<code>80333</code>		<code>80333</code>
	<city>Munich</city>		<city>Munich</city>
	<country>Germany</country>		<country>Germany</country>
	</postal>		</postal>
	<email>steffen.fries@siemens.com</email>		<email>steffen.fries@siemens.com</email>
	<uri>https://www.siemens.com</uri>		<uri>https://www.siemens.com</uri>
	</address>		</address>
	</author>		</author>
	<date year="2023"/>		<date year="2023" month="October"/>
	<!-- If the month and year are both specified and are the current ones, xml2
	rfc will fill
	in the current day for you. If only the current year is specified, xml2r
	fc will fill
	in the current day and month for you. If the year is not the current one
	, it is
	necessary to specify at least a month (xml2rfc assumes day="1" if not sp
	ecified for the
	purpose of calculating the expiry date). With drafts it is normally suf
	ficient to
	specify just the year. -->
	<area>Internet</area>		<area>Internet</area>
	<workgroup>LAMPS Working Group</workgroup>		<workgroup>LAMPS Working Group</workgroup>
	<!-- WG name at the upperleft corner of the doc,
	IETF is fine for individual submissions.
	If this element is not present, the default is "Network Working Group",
	which is used by the RFC Editor as a nod to the history of the IETF. -->
	<keyword>CMP</keyword>		<keyword>CMP</keyword>
	<abstract>		<abstract>
	<t>This document aims at simple, interoperable, and automated PKI manageme nt operations covering typical use cases of industrial and IoT scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightwei ght as possible, only the most crucial types of operations and options are speci fied as mandatory. More specialized or complex use cases are supported with opt ional features.</t>		<t>This document aims at simple, interoperable, and automated PKI manageme nt operations covering typical use cases of industrial and Internet of Things (I oT) scenarios. This is achieved by profiling the Certificate Management Protoco l (CMP), the related Certificate Request Message Format (CRMF), and transfer bas ed on HTTP or Constrained Application Protocol (CoAP) in a succinct but sufficie ntly detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the m ost crucial types of operations and options are specified as mandatory. More sp ecialized or complex use cases are supported with optional features.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="Introduction" numbered="true" toc="default">		<section anchor="Introduction" numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<t>[RFC Editor:</t>		<t>This document specifies PKI management operations supporting machine-to
	<t>Please perform the following substitution.</t>		-machine and IoT use cases. Its focus is to maximize automation and interoperabi
	<ul spacing="normal">		lity between all involved PKI entities, ranging from end entities (EEs) over any
	<li>RFCXXXX --> the assigned numerical RFC value for this draft</li>		number of intermediate PKI management entities, such as registration authoritie
	<li>RFCAAAA --> the assigned numerical RFC value for <xref target="I-D		s (RAs), to the <xref target="RFC4210" format="default">Certificate Management P
	.ietf-lamps-cmp-updates" format="default"/></li>		rotocol (CMP)</xref> endpoints of certification authority (CA) systems. This pr
	<li>RFCBBBB --> the assigned numerical RFC value for <xref target="I-D		ofile makes use of the concepts and syntax specified in <xref target="RFC4210" f
	.ietf-lamps-cmp-algorithms" format="default"/></li>		ormat="default">CMP</xref> <xref target="RFC9480" format="default"/> <xref targe
	</ul>		t="RFC9481" format="default"/>, <xref target="RFC4211" format="default">Certific
	<t>Please also update the following references to associated drafts in		ate Request Message Format (CRMF)</xref> <xref target="RFC9045" format="default"
	progress to reflect their final RFC assignments, if available:</t>		/>, <xref target="RFC5652" format="default">Cryptographic Message Syntax (CMS)</
	<ul spacing="normal">		xref> <xref target="RFC8933" format="default"/>, <xref target="RFC6712" format="
	<li><xref target="I-D.ietf-lamps-cmp-updates" format="default"/></li>		default">HTTP transfer for CMP</xref>, and <xref target="RFC9482" format="defaul
	<li><xref target="I-D.ietf-lamps-cmp-algorithms" format="default"/></l		t">CoAP transfer for CMP</xref>. CMP, CRMF, and CMS are feature-rich specificat
	i>		ions, but most application scenarios use only a limited subset of the same speci
	<li><xref target="I-D.ietf-ace-cmpv2-coap-transport" format="default"/		fied functionality. Additionally, the standards are not always precise enough o
	></li>		n how to interpret and implement the described concepts. Therefore, this docume
	<li><xref target="I-D.ietf-netconf-sztp-csr" format="default"/></li>		nt aims to tailor the available options and specify how to use them in adequate
	<li><xref target="I-D.ietf-anima-brski-ae" format="default"/></li>		detail to make the implementation of interoperable automated certificate managem
	<li><xref target="I-D.ietf-anima-brski-prm" format="default"/></li>		ent as straightforward and lightweight as possible.</t>
	</ul>		<t>While this document was being developed, documents intended to obsol
	<t>]</t>		ete RFC 4210 <xref target="I-D.ietf-lamps-rfc4210bis" format="default"/> and RF
	<t>This document specifies PKI management operations supporting machine-to		C 6712 <xref target="I-D.ietf-lamps-rfc6712bis" format="default"/> were posted,
	-machine and IoT use cases. Its focus is to maximize automation and interoperabi		and they include the full set of changes described in <xref target="RFC9480" for
	lity between all involved PKI entities, ranging from end entities (EE) over any		mat="default">CMP Updates</xref>.</t>
	number of intermediate PKI management entities such as Registration Authorities
	(RA) to the CMP endpoints of Certification Authority (CA) systems. This profile
	makes use of the concepts and syntax specified in <xref target="RFC4210" format
	="default">CMP</xref>, <xref target="I-D.ietf-lamps-cmp-updates" format="default
	"/>, and <xref target="I-D.ietf-lamps-cmp-algorithms" format="default"/>, <xref
	target="RFC4211" format="default">CRMF</xref> and <xref target="RFC9045" format=
	"default"/>, <xref target="RFC5652" format="default">CMS</xref> and <xref target
	="RFC8933" format="default"/>, <xref target="RFC6712" format="default">HTTP tran
	sfer for CMP</xref>, and <xref target="I-D.ietf-ace-cmpv2-coap-transport" format
	="default">CoAP transfer for CMP</xref>. CMP, CRMF and CMS are feature-rich spe
	cifications, but most application scenarios use only a limited subset of the sam
	e specified functionality. Additionally, the standards are not always precise e
	nough on how to interpret and implement the described concepts. Therefore, this
	document aims to tailor the available options and specify how to use them in ad
	equate detail to make the implementation of interoperable automated certificate
	management as straightforward and lightweight as possible.</t>
	<t>Note: In the meantime <xref target="I-D.ietf-lamps-rfc4210bis" forma
	t="default">RFC4210bis</xref> and <xref target="I-D.ietf-lamps-rfc6712bis" forma
	t="default">RFC6712bis</xref> drafts were submitted incorporating the changes li
	sted in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates</
	xref> into the original RFC text.</t>
	<section anchor="How_to_read" numbered="true" toc="default">		<section anchor="How_to_read" numbered="true" toc="default">
	<name>How to Read This Document</name>		<name>How to Read This Document</name>
	<t>This document has become longer than the authors would have li		<t>This document has become longer than the authors would have li
	ked it to be. Yet apart from studying <xref target="GenericParts" format="defau		ked it to be. Yet apart from studying <xref target="GenericParts" format="defau
	lt"/>, which contains general requirements, the reader does not have to work thr		lt"/>, which contains general requirements, the reader does not have to work thr
	ough the whole document. The guidance in Sections <xref target="Structure" form		ough the whole document. The guidance in Sections <xref target="Structure" form
	at="counter"/> and <xref target="Conformity" format="counter"/> should be used t		at="counter"/> and <xref target="Conformity" format="counter"/> should be used t
	o figure out which parts of <xref target="EE_UseCases" format="default"/> to <xr		o figure out which parts of Sections <xref target="EE_UseCases" format="counter"
	ef target="Transfer_types" format="default"/> are relevant for the target certif		/> to <xref target="Transfer_types" format="counter"/> are relevant for the targ
	icate management solution depending on the PKI management operations, their vari		et certificate management solution, depending on the PKI management operations,
	ants, and types of message transfer needed.</t>		their variants, and types of message transfer needed.</t>
	<t>Since conformity to this document can be achieved by implement		<t>Since conformity to this document can be achieved by implement
	ing only the functionality declared mandatory in <xref target="Conformity" forma		ing only the functionality declared mandatory in <xref target="Conformity" forma
	t="default"/>, the profile can still be called lightweight because in particular		t="default"/>, the profile can still be called lightweight because, in particula
	for end entities the mandatory-to-implement set of features is rather limited.<		r for end entities, the mandatory-to-implement set of features is rather limited
	/t>		.</t>
	</section>		</section>
	<section anchor="Convention_Terminology" numbered="true" toc="default">		<section anchor="Convention_Terminology" numbered="true" toc="default">
	<name>Conventions and Terminology</name>		<name>Conventions and Terminology</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
	SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" i		14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp1
	n this document are to be interpreted as described in BCP 14 <xref target="RFC21		4>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<
	19" format="default"/> <xref target="RFC8174" format="default"/> when, and only		bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp1
	when, they appear in all capitals, as shown here.</t>		4>" in this document are to be interpreted as described in BCP 14 <xref target="
	<t>The key word "PROHIBITED" is to be interpreted to mean that th		RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and
	e respective ASN.1 field SHALL NOT be present or used.</t>		only when, they appear in all capitals, as shown here.</t>
	<t keepWithNext="true">Technical terminology is used in conformance with		<t>The term "PROHIBITED" is to be interpreted to mean that the re
	<xref target="RFC4210" format="default">RFC&nbsp;4210</xref>, <xref target="RFC		spective ASN.1 field <bcp14>SHALL NOT</bcp14> be present or used.</t>
	4211" format="default">RFC&nbsp;4211</xref>, <xref target="RFC5280" format="defa		<t keepWithNext="true">Technical terminology is used in conformance with
	ult">RFC&nbsp;5280</xref>, and <xref target="IEEE.802.1AR_2018" format="default"		<xref target="RFC4210" format="default"/>, <xref target="RFC4211" format="defau
	>IEEE&nbsp;802.1AR</xref>. The following key words are used:</t>		lt"/>, <xref target="RFC5280" format="default"/>, and <xref target="IEEE.802.1AR
			_2018" format="default">IEEE&nbsp;802.1AR</xref>. The following terminology is u
			sed:</t>
	<dl newline="false" spacing="normal" indent="7">		<dl newline="false" spacing="normal" indent="7">
	<dt>CA:</dt>		<dt>CA:</dt>
	<dd>Certification authority, which issues certificates.</dd>		<dd>Certification authority, which issues certificates.</dd>
	<dt>RA:</dt>		<dt>RA:</dt>
	<dd>Registration authority, an optional PKI component to which a CA de legates certificate management functions such as end entity authentication and a uthorization checks for incoming requests. An RA can also provide conversion bet ween various certificate management protocols and other protocols providing some operations related to certificate management.</dd>		<dd>Registration authority, an optional PKI component to which a CA de legates certificate management functions, such as end entity authentication and authorization checks for incoming requests. An RA can also provide conversion be tween various certificate management protocols and other protocols providing som e operations related to certificate management.</dd>
	<dt>LRA:</dt>		<dt>LRA:</dt>
	<dd>		<dd>
	<t>Local registration authority, a specific form of RA wi		<t>Local registration authority, a specific form of RA with proximity
	th proximity to the end entities.</t>		to the end entities.</t>
	<t>Note: For ease of reading, this document uses the term		<t>Note: For ease of reading, this document also uses the term "R
	"RA" also for LRAs in all cases where the difference is not relevant.</t>		A" for LRAs in all cases where the difference is not relevant.</t>
	</dd>		</dd>
	<dt>KGA:</dt>		<dt>KGA:</dt>
	<dd>Key generation authority, an optional system component, typically co-located with an RA or CA, that offers key generation services to end entities .</dd>		<dd>Key generation authority, an optional system component, typically colocated with an RA or CA, that offers key generation services to end entities. </dd>
	<dt>EE:</dt>		<dt>EE:</dt>
	<dd>End entity, typically a device or service that holds a public-priv ate key pair for which it manages a public-key certificate. An identifier for th e EE is given as the subject of its certificate.</dd>		<dd>End entity, typically a device or service that holds a public-priv ate key pair for which it manages a public key certificate. An identifier for th e EE is given as the subject of its certificate.</dd>
	</dl>		</dl>
	<t keepWithNext="true">The following terminology is reused from <xref ta		<t keepWithNext="true">The following terminology is reused from <xref ta
	rget="RFC4210" format="default">RFC&nbsp;4210</xref>, as follows:</t>		rget="RFC4210" format="default"/> as follows:</t>
	<dl newline="false" spacing="normal" indent="28">		<dl newline="false" spacing="normal" indent="29">
	<dt>PKI management operation:</dt>		<dt>PKI management operation:</dt>
	<dd>All CMP messages belonging to a single transaction. The transacti on is identified by the transactionID field of the message headers.</dd>		<dd>All CMP messages belonging to a single transaction. The transacti on is identified by the transactionID field of the message headers.</dd>
	<dt>PKI management entity:</dt>		<dt>PKI management entity:</dt>
	<dd>A non-EE PKI entity, i.e., RA or CA.</dd>		<dd>A non-EE PKI entity, i.e., an RA or a CA.</dd>
	<dt>PKI entity:</dt>		<dt>PKI entity:</dt>
	<dd>An EE or PKI management entity.</dd>		<dd>An EE or PKI management entity.</dd>
	</dl>		</dl>
	<t>CMP messages are referred to by the names of PKIBody choices d efined in <xref target="RFC4210" format="default">RFC&nbsp;4210 Section 5.1.2</x ref> and are further described in <xref target="EE_UseCases" format="default"/> of this document.</t>		<t>CMP messages are referred to by the names of PKIBody choices d efined in <xref target="RFC4210" format="default" sectionFormat="of" section="5. 1.2"/> and are further described in <xref target="EE_UseCases" format="default"/ > of this document.</t>
	<t keepWithNext="true">The following terms are introduced in this docume nt:</t>		<t keepWithNext="true">The following terms are introduced in this docume nt:</t>
	<dl newline="false" spacing="normal" indent="30">		<dl newline="false" spacing="normal" indent="29">
	<dt>CMP protection key:</dt>		<dt>CMP protection key:</dt>
	<dd>The private key used to sign a CMP message.</dd>		<dd>The private key used to sign a CMP message.</dd>
	<dt>CMP protection certificate:</dt>		<dt>CMP protection certificate:</dt>
	<dd>The certificate related to the CMP protection key. If the keyUsag e extension is present, it MUST include digitalSignature.</dd>		<dd>The certificate related to the CMP protection key. If the keyUsag e extension is present, it <bcp14>MUST</bcp14> include digitalSignature.</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="Motivation" numbered="true" toc="default">		<section anchor="Motivation" numbered="true" toc="default">
	<name>Motivation for a Lightweight Profile of CMP</name>		<name>Motivation for a Lightweight Profile of CMP</name>
	<t>CMP was standardized in 1999 and is implemented in several PKI produc ts. In 2005, a completely reworked and enhanced version 2 of <xref target="RFC42 10" format="default">CMP</xref> and <xref target="RFC4211" format="default">CRMF </xref> has been published, followed by a document specifying a transfer mechani sm for CMP messages using HTTP <xref target="RFC6712" format="default"/> in 2012 .</t>		<t>CMP was standardized in 1999 and is implemented in several PKI produc ts. In 2005, a completely reworked and enhanced version 2 of <xref target="RFC42 10" format="default">CMP</xref> and <xref target="RFC4211" format="default">CRMF </xref> has been published, followed by a document specifying a transfer mechani sm for CMP messages using HTTP <xref target="RFC6712" format="default"/> in 2012 .</t>
	<t>CMP is a capable protocol and could be used more widely. <xref target		<t>CMP is a capable protocol and could be used more widely. <xref target
	="RFC4210" format="default">RFC&nbsp;4210</xref> and <xref target="I-D.ietf-lamp		="RFC4210" format="default">CMP</xref> and <xref target="RFC9480" format="defaul
	s-cmp-updates" format="default">CMP Updates</xref> offer a very large set of fea		t">CMP Updates</xref> offer a very large set of features and options. On one ha
	tures and options. On the one hand, this makes CMP applicable to a very wide ra		nd, this makes CMP applicable to a very wide range of scenarios; on the other ha
	nge of scenarios, but on the other hand, a full implementation supporting all op		nd, a full implementation supporting all options is not realistic because this w
	tions is not realistic because this would take undue effort.</t>		ould take undue effort.</t>
	<t>In order to reduce complexity, the set of mandatory PKI manage		<t>In order to reduce complexity, the set of mandatory PKI management ope
	ment operations and variants required by this specification has been kept lean.		rations and variants required by this specification has been kept lean. This li
	This limits development effort and minimizes resource needs, which is particula		mits development efforts and minimizes resource needs, which is particularly imp
	rly important for memory-constrained devices. To this end, when there was desig		ortant for memory-constrained devices. To this end, when there was design flexi
	n flexibility to either have necessary complexity on the EE or in the PKI manage		bility to either have necessary complexity on the EE or in the PKI management en
	ment entity, this profile chose to include it in the PKI management entities whe		tity, this profile chose to include it in the PKI management entities where typi
	re typically more computational resources are available. Additional recommended		cally more computational resources are available. Additional recommended PKI ma
	PKI management operations and variants support some more complex scenarios that		nagement operations and variants support some more complex scenarios that are co
	are considered beneficial for environments with more specific demands or bounda		nsidered beneficial for environments with more specific demands or boundary cond
	ry conditions. The optional PKI management operations support less common scena		itions. The optional PKI management operations support less common scenarios an
	rios and requirements.</t>		d requirements.</t>
	<t>Moreover, many details of the CMP protocol have been left open or hav		<t>Moreover, many details of the Certificate Management Protocol have be
	e not been specified in full preciseness. The profiles specified in <xref target		en left open or have not been specified in full preciseness. The profiles specif
	="RFC4210" format="default">Appendix D and E of RFC&nbsp;4210</xref> define some		ied in Appendices <xref target="RFC4210" sectionFormat="bare" section="D"/> and
	more detailed PKI management operations. Yet, the specific needs of highly auto		<xref target="RFC4210" sectionFormat="bare" section="E"/> of <xref target="RFC42
	mated scenarios for a machine-to-machine communication are not covered sufficien		10" format="default"/> define some more detailed PKI management operations. Yet
	tly.</t>		the specific needs of highly automated scenarios for machine-to-machine communic
	<t>Profiling is a way to reduce feature richness and complexity of stand		ation are not covered sufficiently.</t>
	ards to what is needed for specific use cases. 3GPP and UNISIG already use profi		<t>Profiling is a way to reduce feature richness and complexity of stand
	ling of CMP as a way to cope with these challenges. To profile means to take ad		ards to what is needed for specific use cases. 3GPP and UNISIG already use profi
	vantage of the strengths of the given protocol, while explicitly narrowing down		ling of CMP as a way to cope with these challenges. To profile means to take ad
	the options it provides to those needed for the purpose(s) at hand and eliminati		vantage of the strengths of the given protocol while explicitly narrowing down t
	ng all identified ambiguities. In this way the general aspects of the protocol a		he options it provides to those needed for the purpose(s) at hand and eliminatin
	re utilized and only the special requirements of the target scenarios need to be		g all identified ambiguities. In this way, the general aspects of the protocol a
	dealt with using distinct features the protocol offers.</t>		re utilized and only the special requirements of the target scenarios need to be
	<t>Defining a profile for a new target environment takes high effort bec		dealt with using distinct features the protocol offers.</t>
	ause the range of available options needs to be well understood and the selected		<t>Defining a profile for a new target environment takes high effort bec
	options need to be consistent with each other and suitably cover the intended a		ause the range of available options needs to be well understood and the selected
	pplication scenario. Since most industrial PKI management use cases typically h		options need to be consistent with each other and suitably cover the intended a
	ave much in common it is worth sharing this effort, which is the aim of this doc		pplication scenario. Since most industrial PKI management use cases typically h
	ument. Other standardization bodies can reference this document and further tai		ave much in common, it is worth sharing this effort, which is the aim of this do
	lor the PKI management operations to their needs to avoid coming up with individ		cument. Other standardization bodies can reference this document and further ta
	ual profiles from scratch.</t>		ilor the PKI management operations to their needs to avoid coming up with indivi
			dual profiles from scratch.</t>
	</section>		</section>
	<section anchor="Lightweight_profile" numbered="true" toc="default">		<section anchor="Lightweight_profile" numbered="true" toc="default">
	<name>Special Requirements of Industrial and IoT Scenarios</name>		<name>Special Requirements of Industrial and IoT Scenarios</name>
	<t>The profiles specified in <xref target="RFC4210" format="default">App		<t>The profiles specified in Appendices <xref target="RFC4210" format="d
	endix D and E of RFC&nbsp;4210</xref> have been developed particularly for manag		efault" sectionFormat="bare" section="D"/> and <xref target="RFC4210" sectionFor
	ing certificates of human end entities. With the evolution of distributed system		mat="bare" section="E"/> of <xref target="RFC4210"/> have been developed particu
	s and client-server architectures, certificates for machines and applications on		larly for managing certificates of human end entities. With the evolution of dis
	them have become widely used. This trend has strengthened even more in emerging		tributed systems and client-server architectures, certificates for machines and
	industrial and IoT scenarios. CMP is sufficiently flexible to support them well		applications on them have become widely used. This trend has strengthened even m
	.</t>		ore in emerging industrial and IoT scenarios. CMP is sufficiently flexible to su
	<t>Today's IT security architectures for industrial solutions typically		pport them well.</t>
	use certificates for endpoint authentication within protocols like IPsec, TLS, o		<t>Today's IT security architectures for industrial solutions typically
	r SSH. Therefore, the security of these architectures highly relies upon the sec		use certificates for endpoint authentication within protocols like IPsec, TLS, o
	urity and availability of the implemented certificate management operations.</t>		r Secure Shell (SSH). Therefore, the security of these architectures highly reli
	<t>Due to increasing security and availability needs in operational tech		es upon the security and availability of the implemented certificate management
	nology, especially when used for critical infrastructures and systems with a hig		operations.</t>
	h number of certificates, a state-of-the-art certificate management system must		<t>Due to increasing security and availability needs in operational tech
	be constantly available and cost-efficient, which calls for high automation and		nology, especially when used for critical infrastructures and systems with a hig
	reliability. Consequently, the <xref target="NIST.CSWP.04162018" format="defaul		h number of certificates, a state-of-the-art certificate management system must
	t">NIST Framework for Improving Critical Infrastructure Cybersecurity</xref> ref		be constantly available and cost-efficient, which calls for high automation and
	ers to proper processes for issuance, management, verification, revocation, and		reliability. Consequently, <xref target="NIST.CSWP.04162018" format="default"> "
	audit for authorized devices, users, and processes involving identity and creden		Framework for Improving Critical Infrastructure Cybersecurity"</xref> refers to
	tial management. Such PKI management operations according to commonly accepted b		proper processes for issuance, management, verification, revocation, and audit o
	est practices are also required in <xref target="IEC.62443-3-3" format="default"		f authorized devices, users, and processes involving identity and credential man
	>IEC&nbsp;62443-3-3</xref> for security level 2 and higher.</t>		agement. According to commonly accepted best practices, such PKI management oper
	<t>Further challenges in many industrial systems are network segmentatio		ations are also required in <xref target="IEC.62443-3-3" format="default"/> for
	n and asynchronous communication. Also, PKI management entities like Certificati		security level 2 and higher.</t>
	on Authorities (CA) typically are not deployed on-site but in a highly protected		<t>Further challenges in many industrial systems are network segmentatio
	data center environment, e.g., operated according to <xref target="ETSI-EN.3194		n and asynchronous communication. Also, PKI management entities like certificati
	11-1" format="default">ETSI Policy and security requirements for Trust Service P		on authorities (CAs) are not typically deployed on-site but in a highly protecte
	roviders issuing certificates</xref>. Certificate management must be able to co		d data center environment, e.g., operated according to <xref target="ETSI-EN.319
	pe with such network architectures. CMP offers the required flexibility and func		411-1" format="default">ETSI Policy and security requirements for Trust Service
	tionality, namely authenticated self-contained messages, efficient polling, and		Providers issuing certificates</xref>. Certificate management must be able to c
	support for asynchronous message transfer while retaining end-to-end authenticat		ope with such network architectures. CMP offers the required flexibility and fun
	ion.</t>		ctionality, namely authenticated self-contained messages, efficient polling, and
			support for asynchronous message transfer while retaining end-to-end authentica
			tion.</t>
	</section>		</section>
	<section anchor="Existing_profiles" numbered="true" toc="default">		<section anchor="Existing_profiles" numbered="true" toc="default">
	<name>Existing CMP Profiles</name>		<name>Existing CMP Profiles</name>
	<t>As already stated, <xref target="RFC4210" format="default">RFC&nbsp;4		<t>As already stated, <xref target="RFC4210" format="default"/> contains
	210</xref> contains profiles with mandatory and optional PKI management operatio		profiles with mandatory and optional PKI management operations in Appendices <x
	ns in Appendix D and E. Those profiles focus on management of human user certifi		ref target="RFC4210" sectionFormat="bare" section="D"/> and <xref target="RFC421
	cates and only partly address the specific needs of certificate management autom		0" sectionFormat="bare" section="E"/> of <xref target="RFC4210"/>. Those profile
	ation for unattended devices or machine-to-machine application scenarios.</t>		s focus on management of human user certificates and only partly address the spe
	<t>Both Appendixes D and E focus on EE-to-RA/CA PKI management operation		cific needs of certificate management automation for unattended devices or machi
	s and do not address further profiling of RA-to-CA communication as typically ne		ne-to-machine application scenarios.</t>
	eded for full backend automation. All requirements regarding algorithm support		<t>Both Appendices <xref target="RFC4210" sectionFormat="bare" section="
	for <xref target="RFC4210" format="default">RFC&nbsp;4210 Appendix D and E</xref		D"/> and <xref target="RFC4210" sectionFormat="bare" section="E"/> of <xref targ
	> have been updated by <xref target="I-D.ietf-lamps-cmp-algorithms" format="defa		et="RFC4210"/> focus on PKI management operations between an EE and an RA or CA.
	ult">CMP Algorithms Section 7.1</xref>.</t>		They do not address further profiling of RA-to-CA communication, which is typic
	<t>3GPP makes use of <xref target="RFC4210" format="default">CMP</xref>		ally needed for full backend automation. All requirements regarding algorithm s
	in its <xref target="ETSI-3GPP.33.310" format="default">Technical Specification		upport for Appendices <xref target="RFC4210" format="default" sectionFormat="bar
	33.310</xref> for automatic management of IPsec certificates in 3G, LTE, and 5G		e" section="D"/> and <xref target="RFC4210" sectionFormat="bare" section="E"/> o
	backbone networks. Since 2010, a dedicated CMP profile for initial certificate e		f <xref target="RFC4210"/> have been updated by <xref target="RFC9481" format="d
	nrollment and certificate update operations between EE and RA/CA is specified in		efault" sectionFormat="of" section="7.1">CMP Algorithms</xref>.</t>
	that document.</t>		<t>3GPP makes use of <xref target="RFC4210" format="default">CMP</xref>
	<t>UNISIG has included a CMP profile for enrollment of TLS certificates		in its <xref target="ETSI-3GPP.33.310" format="default">Technical Specification
	in the Subset-137 specifying the <xref target="UNISIG.Subset-137" format="defaul		33.310</xref> for automatic management of IPsec certificates in 3G, LTE, and 5G
	t">ETRAM/ETCS on-line key management for train control systems</xref> in 2015.</		backbone networks. Since 2010, a dedicated CMP profile for initial certificate e
	t>		nrollment and certificate update operations between EEs and RAs/CAs is specified
			in that document.</t>
			<t>In 2015, UNISIG included a CMP profile for enrollment of TLS certific
			ates in the Subset-137 specifying the <xref target="UNISIG.Subset-137" format="d
			efault">ETRAM/ETCS online key management for train control systems</xref>.</t>
	<t>Both standardization bodies tailor <xref target="RFC4210" format="def ault">CMP</xref>, <xref target="RFC4211" format="default">CRMF</xref>, and <xref target="RFC6712" format="default">HTTP transfer for CMP</xref> for highly autom ated and reliable PKI management operations for unattended devices and services. </t>		<t>Both standardization bodies tailor <xref target="RFC4210" format="def ault">CMP</xref>, <xref target="RFC4211" format="default">CRMF</xref>, and <xref target="RFC6712" format="default">HTTP transfer for CMP</xref> for highly autom ated and reliable PKI management operations for unattended devices and services. </t>
	</section>		</section>
	<section anchor="Compatibility" numbered="true" toc="default">		<section anchor="Compatibility" numbered="true" toc="default">
	<name>Compatibility with Existing CMP Profiles</name>		<name>Compatibility with Existing CMP Profiles</name>
	<t keepWithNext="true">The profile specified in this document is compati ble with <xref target="RFC4210" format="default">RFC&nbsp;4210 Appendixes D and E (PKI Management Message Profiles)</xref>, with the following exceptions:</t>		<t keepWithNext="true">The profile specified in this document is compati ble with Appendices <xref target="RFC4210" format="default" sectionFormat="bare" section="D"/> and <xref target="RFC4210" format="default" sectionFormat="bare" section="E"/> of <xref target="RFC4210"/>, with the following exceptions:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>signature-based protection is the default protection; an initial P KI management operation may also use MAC-based protection,</li>		<li>signature-based protection is the default protection; an initial P KI management operation may also use protection based on the message authenticat ion code (MAC),</li>
	<li>certification of a second key pair within the same PKI management operation is not supported,</li>		<li>certification of a second key pair within the same PKI management operation is not supported,</li>
	<li>proof-of-possession (POPO) with self-signature of the certTemplate according to <xref target="RFC4211" format="default">RFC&nbsp;4211 Section 4.1< /xref> clause 3 is the recommended default POPO method (deviations are possible for EEs when requesting central key generation, for RAs when using raVerified, a nd if the newly generated keypair is technically not capable to generate digital signatures),</li>		<li>proof-of-possession (POP) with the self-signature of the certReq c ontaining the certTemplate (according to <xref target="RFC4211" format="default" sectionFormat="comma" section="4.1"/>, clause 3) is the recommended default POP method (deviations are possible for EEs when requesting central key generation, for RAs when using raVerified, and if the newly generated keypair is technicall y not capable to generate digital signatures),</li>
	<li>confirmation of newly enrolled certificates may be omitted, and</l i>		<li>confirmation of newly enrolled certificates may be omitted, and</l i>
	<li>all PKI management operations consist of request-response message pairs originating at the EE, i.e., announcement messages (requiring a push model , a CMP server on the EE) are excluded in favor of a lightweight implementation on the EE.</li>		<li>all PKI management operations consist of request-response message pairs originating at the EE, i.e., announcement messages (requiring a push model , a CMP server on the EE) are excluded in favor of a lightweight implementation on the EE.</li>
	</ul>		</ul>
	<t keepWithNext="true">The profile specified in this document is compati ble with the CMP profile for 3G, LTE, and 5G network domain security and authent ication framework <xref target="ETSI-3GPP.33.310" format="default"/>, except tha t:</t>		<t keepWithNext="true">The profile specified in this document is compati ble with the CMP profile for 3G, LTE, and 5G network domain security and authent ication framework <xref target="ETSI-3GPP.33.310" format="default"/>, except tha t:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>protection of initial PKI management operations may be MAC-based,< /li>		<li>protection of initial PKI management operations may be MAC-based,< /li>
	<li>the subject field is mandatory in certificate templates, and</li>		<li>the subject field is mandatory in certificate templates, and</li>
	<li>confirmation of newly enrolled certificates may be omitted.</li>		<li>confirmation of newly enrolled certificates may be omitted.</li>
	</ul>		</ul>
	<t keepWithNext="true">The profile specified in this document is compati ble with the CMP profile for on-line key management in rail networks as specifie d in <xref target="UNISIG.Subset-137" format="default">UNISIG Subset-137</xref>, except that:</t>		<t keepWithNext="true">The profile specified in this document is compati ble with the CMP profile for online key management in rail networks as specified in <xref target="UNISIG.Subset-137" format="default"/>, except that:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>A certificate enrollment request message consists of only one cer tificate request (CertReqMsg).</li>		<li>A certificate enrollment request message consists of only one cer tificate request (CertReqMsg).</li>
	<li>		<li>
	<t><xref target="RFC4210" format="default">RFC&nbsp;4210<		<t><xref target="RFC4210" format="default"/> requires tha
	/xref> requires that the messageTime is Greenwich Mean Time coded as generalized		t the messageTime is Greenwich Mean Time coded as generalizedTime.</t>
	Time.</t>		<t>Note: As Table 5 of <xref target="UNISIG.Subset-137" format="d
	<t>Note: As <xref target="UNISIG.Subset-137" format="defa		efault"/> explicitly states that the messageTime is required to be "UTC time", i
	ult">UNISIG Subset-137 Table 5</xref> explicitly states that the messageTime in		t is not clear if this means a coding as UTCTime or generalizedTime and if time
	required to be "UTC time", it is not clear if this means a coding as UTCTime or		zones other than Greenwich Mean Time shall be allowed. Both time formats are des
	generalizedTime and if other time zones than Greenwich Mean Time shall be allowe		cribed in <xref target="RFC5280" format="default" sectionFormat="of" section="4.
	d. Both time formats are described in <xref target="RFC5280" format="default">RF		1.2.5"/>.</t>
	C&nbsp;5280 Section 4.1.2.5</xref>.</t>
	</li>		</li>
	<li>The same type of protection is required to be used for all message s of one PKI management operation. This means, in case the request message prote ction is MAC-based, also the response, certConf, and pkiConf messages must have a MAC-based protection.</li>		<li>The same type of protection is required to be used for all message s of one PKI management operation. This means, in case the request message prote ction is MAC-based, the response, certConf, and pkiConf messages must also have MAC-based protection.</li>
	<li>		<li>
	<t>Use of caPubs is not required but typically allowed in		<t>Use of caPubs is not required but is typically allowed
	combination with MAC-based protected PKI management operations. On the other h		in combination with MAC-based protected PKI management operations. On the othe
	and <xref target="UNISIG.Subset-137" format="default">UNISIG Subset-137 Table 12		r hand, Table 12 of <xref target="UNISIG.Subset-137" format="default"/> requires
	</xref> requires using caPubs.</t>		using caPubs.</t>
	<t>Note: It remains unclear from UNISIG Subset-137 for wh		<t>Note: It remains unclear from UNISIG Subset-137 which
	ich certificate(s) the caPubs field should be used. For security reasons, it can		certificate(s) for the caPubs field should be used. For security reasons, it can
	not be used for delivering the root CA certificate needed for validating the sig		not be used for delivering the root CA certificate needed to validate the signat
	nature-based protection of the given response message (as stated indirectly also		ure-based protection of the given response message (as stated indirectly also in
	in its <xref target="UNISIG.Subset-137" format="default">UNISIG Subset-137 Sect		Section 6.3.1.5.2 b of <xref target="UNISIG.Subset-137" format="default"/>).</t
	ion 6.3.1.5.2 b</xref>).</t>		>
	</li>		</li>
	<li>		<li>
	<t>This profile requires that the certConf message has on		<t>This profile requires that the certConf message have o
	e CertStatus element where the statusInfo field is recommended.</t>		ne CertStatus element where the statusInfo field is recommended.</t>
	<t>Note: In contrast, <xref target="UNISIG.Subset-137" fo		<t>Note: In contrast, Table 18 of <xref target="UNISIG.Su
	rmat="default">UNISIG Subset-137 Table 18</xref> requires that the certConf mess		bset-137" format="default"/> requires that the certConf message has one CertStat
	age has one CertStatus element where the statusInfo field must be absent. This p		us element where the statusInfo field must be absent. This precludes sending a n
	recludes sending a negative certConf message in case the EE rejects the newly en		egative certConf message in case the EE rejects the newly enrolled certificate.
	rolled certificate. This results in violating the general rule that a certificat		This results in violating the general rule that a certificate request transactio
	e request transaction must include a certConf message (since moreover, using imp		n must include a certConf message (moreover, since using implicitConfirm is not
	licitConfirm is not allowed there, either).</t>		allowed there either).</t>
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="ZTO" numbered="true" toc="default">		<section anchor="ZTO" numbered="true" toc="default">
	<name>Use of CMP in SZTP and BRSKI Environments</name>		<name>Use of CMP in SZTP and BRSKI Environments</name>
	<t>In <xref target="RFC8572" format="default">Secure Zero Touch P		<t>In <xref target="RFC8572" format="default">Secure Zero Touch P
	rovisioning (SZTP)</xref> and other environments using NETCONF/YANG modules, <xr		rovisioning (SZTP)</xref> and other environments using Network Configuration Pro
	ef target="I-D.ietf-netconf-sztp-csr" format="default">SZTP-CSR</xref> offers a		tocol (NETCONF) / YANG modules, <xref target="I-D.ietf-netconf-sztp-csr" format=
	YANG module that includes several types of certificate requests to obtain a publ		"default"/> offers a YANG module that includes several types of certificate requ
	ic-key certificate for a locally generated key pair. Such messages are of the f		ests to obtain a public key certificate for a locally generated key pair. Such
	orm ietf-ztp-types:cmp-csr from module ietf-ztp-csr and offer both proof-of-poss		messages are of the form ietf-ztp-types:cmp-csr from module ietf-ztp-csr and off
	ession and proof-of-identity. To allow PKI management entities that use the mod		er both proof-of-possession and proof-of-identity. To allow PKI management enti
	ule ietf-ztp-csr and also wish to comply with this profile, the ir, cr, kur, or		ties that use the module ietf-ztp-csr and also wish to comply with this profile,
	p10cr message MUST be formatted by the EE as described in <xref target="EE_reque		the ir, cr, kur, or p10cr message <bcp14>MUST</bcp14> be formatted by the EE as
	st" format="default"/>, and it MAY be forwarded as specified in <xref target="RA		described in <xref target="EE_request" format="default"/>, and it <bcp14>MAY</b
	_forwarde_messages" format="default"/>.</t>		cp14> be forwarded, as specified in <xref target="RA_forwarde_messages" format="
	<t>In <xref target="RFC8995" format="default">Bootstrapping Remot		default"/>.</t>
	e Secure Key Infrastructure (BRSKI)</xref> environments, <xref target="I-D.ietf-		<t>In <xref target="RFC8995" format="default">Bootstrapping Remot
	anima-brski-ae" format="default">BRSKI-AE: Alternative Enrollment Protocols in B		e Secure Key Infrastructure (BRSKI)</xref> environments, <xref target="I-D.ietf-
	RSKI</xref> describes a generalization regarding the employed enrollment protoco		anima-brski-ae" format="default">"BRSKI-AE: Alternative Enrollment Protocols in
	ls to allow alternatives to <xref target="RFC7030" format="default">EST</xref>.		BRSKI"</xref> describes a generalization regarding the employed enrollment proto
	For the use of CMP, it requires adherence to this profile.</t>		cols to allow alternatives to <xref target="RFC7030" format="default">Enrollment
			over Secure Transport (EST)</xref>. For the use of CMP, it requires adherence t
			o this profile.</t>
	</section>		</section>
	<section anchor="Scope" numbered="true" toc="default">		<section anchor="Scope" numbered="true" toc="default">
	<name>Scope of this Document</name>		<name>Scope of This Document</name>
	<t>This profile on the one hand intends to reduce the flexibility		<t>On one hand, this profile intends to reduce the flexibility of
	of CMP to the generic needs of automated certificate management of machine end		CMP to the generic needs of automated certificate management of machine end ent
	entities. On the other hand, it offers a variety of PKI management operations a		ities. On the other hand, it offers a variety of PKI management operations and
	nd options relevant for industrial use cases. Therefore, it is still a framewor		options relevant for industrial use cases. Therefore, it is still a framework t
	k that supports further profiling by those addressing a specific use case or sce		hat supports further profiling by those addressing a specific use case or scenar
	nario, e.g., 3GPP/ETSI or UNISIG. There is room for further tailoring this prof		io, e.g., 3GPP/ETSI or UNISIG. There is room to further tailor this profile. T
	ile. This enables stricter profiling to the needs of concrete application areas		his enables stricter profiling to meet the concrete needs in application areas.<
	.</t>		/t>
	<t>To minimize ambiguity and complexity through needless variety, this d		<t>To minimize ambiguity and complexity through needless variety, this d
	ocument specifies exhaustive requirements for generating PKI management messages		ocument specifies exhaustive requirements for generating PKI management messages
	on the sender side. On the other hand, it gives only minimal requirements on c		on the sender side. However, it gives only minimal requirements on checks by t
	hecks by the receiving side and how to handle error cases.</t>		he receiving side and how to handle error cases.</t>
	<t>Especially on the EE side this profile aims at a lightweight implemen		<t>Especially on the EE side, this profile aims at a lightweight impleme
	tation. This means that the number of PKI management operations implementations		ntation. This means that the number of PKI management operation implementations
	are reduced to a reasonable minimum to support typical certificate management us		are reduced to a reasonable minimum to support typical certificate management us
	e cases in industrial machine-to-machine environments. On the EE side only limit		e cases in industrial machine-to-machine environments. On the EE side, only limi
	ed resources are expected, while on the side of the PKI management entities the		ted resources are expected, while on the side of the PKI management entities, th
	profile accepts higher requirements.</t>		e profile accepts higher requirements.</t>
	<t>For the sake of interoperability and robustness, implementations shou		<t>For the sake of interoperability and robustness, implementations shou
	ld, as far as security is not affected, adhere to Postel's law: "Be conservative		ld, so long as security is not affected, adhere to Postel's law: "Be conservativ
	in what you do, be liberal in what you accept from others" (often reworded as:		e in what you do, be liberal in what you accept from others" (often reworded as:
	"Be conservative in what you send, be liberal in what you receive").</t>		"Be conservative in what you send, be liberal in what you receive").</t>
	<t>Fields used in ASN.1 syntax in <xref target="GenericParts" format="de		<t>Fields used in ASN.1 syntax in Sections <xref target="GenericParts" f
	fault"/>, <xref target="EE_UseCases" format="default"/>, or <xref target="RA_Use		ormat="counter"/>, <xref target="EE_UseCases" format="counter"/>, or <xref targe
	Cases" format="default"/> are specified in <xref target="RFC4210" format="defaul		t="RA_UseCases" format="counter"/> are specified in <xref target="RFC4210" forma
	t">CMP</xref> <xref target="I-D.ietf-lamps-cmp-updates" format="default"/>, <xre		t="default">CMP</xref> <xref target="RFC9480" format="default"/>, <xref target="
	f target="RFC4211" format="default">CRMF</xref>, and <xref target="RFC5652" form		RFC4211" format="default">CRMF</xref>, and <xref target="RFC5652" format="defaul
	at="default">CMS</xref> <xref target="RFC8933" format="default"/>. When these se		t">CMS</xref> <xref target="RFC8933" format="default"/>. When these sections do
	ctions do not explicitly discuss a field, then the field SHOULD NOT be used by t		not explicitly discuss a field, then the field <bcp14>SHOULD NOT</bcp14> be used
	he sending entity. The receiving entity MUST NOT require the absence of such a f		by the sending entity. The receiving entity <bcp14>MUST NOT</bcp14> require the
	ield, and if the field is present, MUST handle it gracefully.</t>		absence of such a field and, if the field is present, <bcp14>MUST</bcp14> handl
			e it gracefully.</t>
	</section>		</section>
	<section anchor="Structure" numbered="true" toc="default">		<section anchor="Structure" numbered="true" toc="default">
	<name>Structure of this Document</name>		<name>Structure of This Document</name>
	<t><xref target="Architecture" format="default"/> introduces the general PKI architecture and approach to certificate management that is assumed in this document.</t>		<t><xref target="Architecture" format="default"/> introduces the general PKI architecture and approach to certificate management that is assumed in this document.</t>
	<t><xref target="GenericParts" format="default"/> profiles the generic a spects of the PKI management operations specified in detail in Sections <xref ta rget="EE_UseCases" format="counter"/> and <xref target="RA_UseCases" format="cou nter"/> to minimize redundancy in the description and to ease implementation. Th is covers the general structure and protection of messages, as well as generic p rerequisites, validation, and error handling.</t>		<t><xref target="GenericParts" format="default"/> profiles the generic a spects of the PKI management operations specified in detail in Sections <xref ta rget="EE_UseCases" format="counter"/> and <xref target="RA_UseCases" format="cou nter"/> to minimize redundancy in the description and to ease implementation. Th is covers the general structure and protection of messages, as well as generic p rerequisites, validation, and error handling.</t>
	<t><xref target="EE_UseCases" format="default"/> profiles the exchange o f CMP messages between an EE and the PKI management entity. There are various fl avors of certificate enrollment requests, optionally with polling, central key g eneration, revocation, and general support PKI management operations.</t>		<t><xref target="EE_UseCases" format="default"/> profiles the exchange o f CMP messages between an EE and the PKI management entity. There are various fl avors of certificate enrollment requests, optionally with polling, central key g eneration, revocation, and general support PKI management operations.</t>
	<t><xref target="RA_UseCases" format="default"/> profiles responding to requests, exchanges between PKI management entities, and operations on behalf of other PKI entities. This may include delayed delivery of messages, which invol ves polling for responses, and nesting of messages.</t>		<t><xref target="RA_UseCases" format="default"/> profiles responding to requests, exchanges between PKI management entities, and operations on behalf of other PKI entities. This may include delayed delivery of messages, which invol ves polling for responses, and nesting of messages.</t>
	<t><xref target="Transfer_types" format="default"/> outlines several mec hanisms for CMP message transfer, including HTTP-based transfer <xref target="RF C6712" format="default"/> optionally using TLS, and CoAP-based transfer <xref ta rget="I-D.ietf-ace-cmpv2-coap-transport" format="default"/> optionally using DTL S, and offline file-based transport.</t>		<t><xref target="Transfer_types" format="default"/> outlines several mec hanisms for CMP message transfer, including HTTP-based transfer <xref target="RF C6712" format="default"/> optionally using TLS, CoAP-based transfer <xref target ="RFC9482" format="default"/> optionally using DTLS, and offline file-based tran sport.</t>
	<t><xref target="Conformity" format="default"/> defines which par ts of the profile are mandatory, recommended, optional, or not relevant to imple ment for which type of entity.</t>		<t><xref target="Conformity" format="default"/> defines which par ts of the profile are mandatory, recommended, optional, or not relevant to imple ment for which type of entity.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="Architecture" numbered="true" toc="default">		<section anchor="Architecture" numbered="true" toc="default">
	<name>Solution Architecture</name>		<name>Solution Architecture</name>
	<t>To facilitate secure automatic certificate enrollment, the device hosti		<t>To facilitate secure automatic certificate enrollment, the device hosti
	ng an EE is typically equipped with a manufacturer-issued device certificate. S		ng an EE is typically equipped with a manufacturer-issued device certificate. S
	uch a certificate is typically installed during production and is meant to ident		uch a certificate is typically installed during production and is meant to ident
	ify the device throughout its lifetime. This certificate can be used to protect		ify the device throughout its lifetime. This certificate can be used to protect
	the initial enrollment of operational certificates after installation of the EE		the initial enrollment of operational certificates after installation of the EE
	in its operational environment. In contrast to the manufacturer-issued device		in its operational environment. In contrast to the manufacturer-issued device
	certificate, operational certificates are issued by the owner or operator of the		certificate, operational certificates are issued by the owner or operator of the
	device to identify the device or one of its components for operational use, e.g		device to identify the device or one of its components for operational use, e.g
	., in a security protocol like IPsec, TLS, or SSH. In <xref target="IEEE.802.1A		., in a security protocol like IPsec, TLS, or SSH. In <xref target="IEEE.802.1A
	R_2018" format="default">IEEE&nbsp;802.1AR</xref> a manufacturer-issued device c		R_2018" format="default">IEEE&nbsp;802.1AR</xref>, a manufacturer-issued device
	ertificate is called IDevID certificate and an operational certificate is called		certificate is called an Initial Device Identifier (IDevID) certificate and an o
	LDevID certificate.</t>		perational certificate is called a Locally Significant Device Identifier (LDevID
	<t>Note: The owner or operator using the manufacturer-issued device certif		) certificate.</t>
	icate for authenticating the device during initial enrollment of operational cer		<t>Note: The owner or operator using the manufacturer-issued device certif
	tificates MUST trust the respective trust anchor provided by the manufacturer.</		icate for authenticating the device during initial enrollment of operational cer
	t>		tificates <bcp14>MUST</bcp14> trust the respective trust anchor provided by the
	<t>Note: According to <xref target="IEEE.802.1AR_2018" format="default">IE		manufacturer.</t>
	EE&nbsp;802.1AR</xref> a DevID comprises the triple of the certificate, the corr		<t>Note: According to <xref target="IEEE.802.1AR_2018" format="default">I
	esponding private key, and the certificate chain.</t>		EEE&nbsp;802.1AR</xref>, a DevID comprises the triple of the certificate, the co
	<t>All certificate management operations specified in this document fol		rresponding private key, and the certificate chain.</t>
	low the pull model, i.e., are initiated by an EE (or by an RA acting as an EE).		<t>All certificate management operations specified in this document fol
	The EE creates a CMP request message, protects it using some asymmetric credent		low the pull model, i.e., they are initiated by an EE (or by an RA acting as an
	ial or shared secret information and sends it to a PKI management entity. This		EE). The EE creates a CMP request message, protects it using some asymmetric cr
	PKI management entity may be a CA or more typically an RA, which checks the requ		edential or shared secret information, and sends it to a PKI management entity.
	est, responds to it itself, or forwards the request upstream to the next PKI man		This PKI management entity may be a CA or more typically an RA, which checks th
	agement entity. In case an RA changes the CMP request message header or body or		e request and responds to it itself or forwards the request upstream to the next
	wants to demonstrate successful verification or authorization, it can apply a p		PKI management entity. In case an RA changes the CMP request message header or
	rotection of its own. The communication between an LRA and RA can be performed		body or wants to demonstrate successful verification or authorization, it can a
	synchronously or asynchronously. Asynchronous communication typically leads to		pply a protection of its own. The communication between an LRA and RA can be pe
	delayed message delivery as described in <xref target="EE_Polling" format="defau		rformed synchronously or asynchronously. Asynchronous communication typically l
	lt"/>.</t>		eads to delayed message delivery as described in <xref target="EE_Polling" forma
			t="default"/>.</t>
	<figure anchor="CertManUseCasesFigure">		<figure anchor="CertManUseCasesFigure">
	<name>Certificate Management Architecture Example</name>		<name>Certificate Management Architecture Example</name>
	<artwork align="center" name="" type="" alt=""><![CDATA[		<artwork align="center" name="" type="" alt=""><![CDATA[
	+-----+ +-----+ +-----+ +-----+		+-----+ +-----+ +-----+ +-----+
	| | | | | | | |		| | | | | | | |
	| EE |<---------->| LRA |<-------------->| RA |<---------->| CA |		| EE |<---------->| LRA |<-------------->| RA |<---------->| CA |
	| | | | | | | |		| | | | | | | |
	+-----+ +-----+ +-----+ +-----+		+-----+ +-----+ +-----+ +-----+
	synchronous (a)synchronous (a)synchronous		synchronous (a)synchronous (a)synchronous
	+----connection----+------connection------+----connection----+		+----connection----+------connection------+----connection----+
	operators service partner		operators service partner
	+---------on site---------+---back-end services--+---trust center--+		+---------on site---------+---back-end services--+---trust center--+
	<--- downstream <--- | ---> upstream --->		<--- downstream <--- | ---> upstream --->
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>In operational environments the certificate management architecture can		<t>In operational environments, the certificate management architecture ca
	have multiple LRAs bundling requests from multiple EEs at dedicated locations a		n have multiple LRAs bundling requests from multiple EEs at dedicated locations
	nd one (or more than one) central RA aggregating the requests from the LRAs. Ev		and one (or more than one) central RA aggregating the requests from the LRAs. E
	ery LRA in this scenario has shared secret information (one per EE) for MAC-base		very LRA in this scenario has shared secret information (one per EE) for MAC-bas
	d protection or a CMP protection key and certificate allowing it to protect CMP		ed protection or a CMP protection key and certificate, allowing it to protect CM
	messages it processes using its own credentials. The figure above shows an arch		P messages it processes using its own credentials. The figure above shows an ar
	itectural example with one LRA, RA, and CA. It is also possible not to have an		chitectural example with one LRA, RA, and CA. It is also possible not to have a
	RA or LRA or that there is no CA with a CMP interface. Depending on the network		n RA or LRA or that there is no CA with a CMP interface. Depending on the netwo
	infrastructure, the message transfer between PKI management entities may be bas		rk infrastructure, the message transfer between PKI management entities may be b
	ed on synchronous online connections, asynchronous connections, or even offline		ased on synchronous online connections, asynchronous connections, or even offlin
	(e.g., file-based) transfer.</t>		e (e.g., file-based) transfer.</t>
	<t>Note: In contrast to the pull model used in this document, other specif		<t>Note: In contrast to the pull model used in this document, other spe
	ications could use the messages specified in this document implementing the push		cifications could use the messages specified in this document to implement the p
	model. In this case the EE is pushed (triggered) by the PKI management entity		ush model. In this case, the EE is pushed (triggered) by the PKI management ent
	to provide the CMP request, and therefore, EE acts as the receiver, not initiati		ity to provide the CMP request; therefore, the EE acts as the receiver, not init
	ng the interaction with the PKI. For example, when the device itself does only a		iating the interaction with the PKI. For example, when the device itself only ac
	ct as a server as described in <xref target="I-D.ietf-anima-brski-prm" format="d		ts (as a server as described in <xref target="I-D.ietf-anima-brski-prm" format="
	efault">BRSKI with Pledge in Responder Mode (BRSKI-PRM)</xref>, support of certi		default">BRSKI with Pledge in Responder Mode</xref>), support of certificate enr
	ficate enrollment in a push model is needed. While BRSKI-PRM currently utilizes		ollment in a push model is needed. While BRSKI-PRM currently utilizes its own fo
	its own format for the exchanges, CMP in general and the messages specified in t		rmat for the exchanges, CMP in general and the messages specified in this profil
	his profile offer all required capabilities. Nevertheless, the message flow and		e offer all required capabilities. Nevertheless, the message flow and state mach
	state machine as described in <xref target="EE_State_Machine" format="default"/>		ine as described in <xref target="EE_State_Machine" format="default"/> must be a
	must be adapted to implement a push model.</t>		dapted to implement a push model.</t>
	<t>Note: Third-party CAs, not conforming to this document, may implement o		<t>Note: Third-party CAs not conforming to this document may implement oth
	ther variants of CMP, different standardized protocols, or even proprietary inte		er variants of CMP, different standardized protocols, or even proprietary interf
	rfaces for certificate management. In such cases, an RA needs to adapt the exch		aces for certificate management. In such cases, an RA needs to adapt the exchan
	anged CMP messages to the flavor of certificate management interaction required		ged CMP messages to the flavor of certificate management interaction required by
	by such a non-conformant CA.</t>		such a nonconformant CA.</t>
	</section>		</section>
	<section anchor="GenericParts" numbered="true" toc="default">		<section anchor="GenericParts" numbered="true" toc="default">
	<name>Generic Aspects of PKI Messages and PKI Management Operations</name>		<name>Generic Aspects of PKI Messages and PKI Management Operations</name>
	<t>This section covers the generic aspects of the PKI management operation s specified in Sections <xref target="EE_UseCases" format="counter"/> and <xref target="RA_UseCases" format="counter"/> as upfront general requirements to minim ize redundancy in the description and to ease implementation.</t>		<t>This section covers the generic aspects of the PKI management operation s specified in Sections <xref target="EE_UseCases" format="counter"/> and <xref target="RA_UseCases" format="counter"/> as upfront general requirements to minim ize redundancy in the description and to ease implementation.</t>
	<t keepWithNext="true">As described in <xref target="RFC4210" format="defa ult">Section 5.1 of RFC&nbsp;4210</xref>, all CMP messages have the following ge neral structure:</t>		<t keepWithNext="true">As described in <xref target="RFC4210" format="defa ult" sectionFormat="of" section="5.1"/>, all CMP messages have the following gen eral structure:</t>
	<figure anchor="CMP_messageStructure">		<figure anchor="CMP_messageStructure">
	<name>CMP Message Structure</name>		<name>CMP Message Structure</name>
	<artwork align="center" name="" type="" alt=""><![CDATA[		<artwork align="center" name="" type="" alt=""><![CDATA[
	+--------------------------------------------+		+--------------------------------------------+
	| PKIMessage |		| PKIMessage |
	| +----------------------------------------+ |		| +----------------------------------------+ |
	| | header | |		| | header | |
	| +----------------------------------------+ |		| +----------------------------------------+ |
	| +----------------------------------------+ |		| +----------------------------------------+ |
	| | body | |		| | body | |
	skipping to change at line 305 ¶		skipping to change at line 259 ¶
	| +----------------------------------------+ |		| +----------------------------------------+ |
	| +----------------------------------------+ |		| +----------------------------------------+ |
	| | extraCerts (OPTIONAL) | |		| | extraCerts (OPTIONAL) | |
	| +----------------------------------------+ |		| +----------------------------------------+ |
	+--------------------------------------------+		+--------------------------------------------+
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>The general contents of the message header, protection, and extraCerts fields are specified in the following three subsections.</t>		<t>The general contents of the message header, protection, and extraCerts fields are specified in the following three subsections.</t>
	<t>In case a specific PKI management operation needs different contents in the header, protection, or extraCerts fields, the differences are described in the respective subsections of Sections <xref target="EE_UseCases" format="counte r"/> and <xref target="RA_UseCases" format="counter"/>.</t>		<t>In case a specific PKI management operation needs different contents in the header, protection, or extraCerts fields, the differences are described in the respective subsections of Sections <xref target="EE_UseCases" format="counte r"/> and <xref target="RA_UseCases" format="counter"/>.</t>
	<t>The CMP message body contains the PKI management operation-specific inf ormation. It is described in Sections <xref target="EE_UseCases" format="counter "/> and <xref target="RA_UseCases" format="counter"/>.</t>		<t>The CMP message body contains the PKI management operation-specific inf ormation. It is described in Sections <xref target="EE_UseCases" format="counter "/> and <xref target="RA_UseCases" format="counter"/>.</t>
	<t>Note: In the description of CMP messages, the presence of some fiel		<t>Note: In the description of CMP messages, the presence of some fiel
	ds is stated as OPTIONAL or RECOMMENDED. The following text that states require		ds is stated as <bcp14>OPTIONAL</bcp14> or <bcp14>RECOMMENDED</bcp14>. The foll
	ments on such a field applies only if the field is present.</t>		owing text that states requirements on such a field applies only if the field is
	<t>The generic prerequisites needed by the PKI entities in order to be abl		present.</t>
	e to perform PKI management operations are described in <xref target="Prereq" fo		<t>The generic prerequisites needed by the PKI entities in order to per
	rmat="default"/>.</t>		form PKI management operations are described in <xref target="Prereq" format="de
	<t>The generic validation steps to be performed by PKI entities on receivi		fault"/>.</t>
	ng a CMP message are described in <xref target="Validation" format="default"/>.<		<t>The generic validation steps to be performed by PKI entities upon recei
	/t>		ving a CMP message are described in <xref target="Validation" format="default"/>
			.</t>
	<t>The generic aspects of handling and reporting errors are described in < xref target="Error" format="default"/>.</t>		<t>The generic aspects of handling and reporting errors are described in < xref target="Error" format="default"/>.</t>
	<section anchor="Header" numbered="true" toc="default">		<section anchor="Header" numbered="true" toc="default">
	<name>General Description of the CMP Message Header</name>		<name>General Description of the CMP Message Header</name>
	<t>This section describes the generic header fields of all CMP messages. </t>		<t>This section describes the generic header fields of all CMP messages. </t>
	<t>Any PKI management operation-specific fields or variations are		<t>Any fields or variations specific to PKI management operation are desc
	described in Sections <xref target="EE_UseCases" format="counter"/> and <xref t		ribed in Sections <xref target="EE_UseCases" format="counter"/> and <xref target
	arget="RA_UseCases" format="counter"/>.</t>		="RA_UseCases" format="counter"/>.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	header		header
	pvno REQUIRED		pvno REQUIRED
	-- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData		-- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData
	-- is supported and expected to be used in the current		-- is supported and expected to be used in the current
	-- PKI management operation		-- PKI management operation
	-- MUST be 3 to indicate CMP v3 in certConf messages when using		-- MUST be 3 to indicate CMP v3 in certConf messages when using
	-- the hashAlg field		-- the hashAlg field
	-- MUST be 2 to indicate CMP v2 in all other cases		-- MUST be 2 to indicate CMP v2 in all other cases
	-- For details on version negotiation see RFCAAAA		-- For details on version negotiation, see [RFC9480]
	sender REQUIRED		sender REQUIRED
	-- Contains a name representing the originator which also		-- Contains a name representing the originator, which also
	-- protects the message		-- protects the message
	-- For signature-based protection MUST be the subject of the CMP		-- For signature-based protection, MUST be the subject field of
	-- protection certificate		-- the CMP protection certificate
	-- For MAC-based protection MUST be the subject name of the		-- For MAC-based protection, MUST contain a name the PKI
	-- certificate request, if available; otherwise, the NULL-DN		-- management entity can use to identify the shared secret
	-- (a zero-length SEQUENCE OF RelativeDistinguishedNames) MUST		-- information. This name MUST be placed in the commonName
	-- be used		-- field of the directoryName choice.
	-- In a multi-hop scenario, the receiving entity cannot rely		-- In a multihop scenario, the receiving entity cannot rely
	-- on the correctness of the sender field.		-- on the correctness of the sender field.
	recipient REQUIRED		recipient REQUIRED
	-- SHOULD be the name of the intended recipient; otherwise, the		-- SHOULD be the name of the intended recipient; otherwise, the
	-- NULL-DN MUST be used		-- NULL-DN MUST be used
	-- In the first message of a PKI management operation: SHOULD be		-- In the first message of a PKI management operation, SHOULD be
	-- the subject DN of the CA the PKI management operation is		-- the subject DN of the CA the PKI management operation is
	-- requested from		-- requested from
	-- In all other messages: SHOULD contain the value of the sender		-- In all other messages, SHOULD contain the value of the sender
	-- field of the previous message in the same PKI management		-- field of the previous message in the same PKI management
	-- operation		-- operation
	-- The recipient field shall be handled gracefully by the		-- The recipient field shall be handled gracefully by the
	-- receiving entity, because in a multi-hop scenario its		-- receiving entity, because in a multihop scenario, its
	-- correctness cannot be guaranteed.		-- correctness cannot be guaranteed.
	messageTime OPTIONAL		messageTime OPTIONAL
	-- MUST be present if the confirmWaitTime field is present		-- MUST be present if the confirmWaitTime field is present
	-- MUST be the time at which the message was produced, if present		-- MUST be the time at which the message was produced, if present
	-- MAY be set by a PKI management entity to provide the current		-- MAY be set by a PKI management entity to provide the current
	-- time		-- time
	-- MAY be used by the end entity for time synchronization if the		-- MAY be used by the end entity for time synchronization if the
	-- response was received within a short time frame		-- response was received within a short time frame
	protectionAlg REQUIRED		protectionAlg REQUIRED
	-- MUST be an algorithm identifier indicating the algorithm		-- MUST be an algorithm identifier indicating the algorithm
	-- used for calculating the protection bits		-- used for calculating the protection bits
	-- If it is a signature algorithm its type MUST be a		-- If it is a signature algorithm, its type MUST be
	-- MSG_SIG_ALG as specified in [RFCBBBB] Section 3 and		-- MSG_SIG_ALG as specified in Section 3 of [RFC9481] and
	-- MUST be consistent with the subjectPublicKeyInfo field of		-- MUST be consistent with the subjectPublicKeyInfo field of
	-- the CMP protection certificate		-- the CMP protection certificate
	-- If it is a MAC algorithm its type MUST be a MSG_MAC_ALG as		-- If it is a MAC algorithm, its type MUST be MSG_MAC_ALG, as
	-- specified in [RFCBBBB] Section 6.1		-- specified in [RFC9481], Section 6.1
	senderKID RECOMMENDED		senderKID RECOMMENDED
	-- For signature-based protection MUST be used and contain the		-- For signature-based protection, MUST be used and contain the
	-- value of the SubjectKeyIdentifier if present in the CMP		-- value of the SubjectKeyIdentifier if present in the CMP
	-- protection certificate		-- protection certificate
	-- For MAC-based protection MUST be used and contain a name the		-- For MAC-based protection, MUST be used and contain the same
	-- PKI management entity can use to identify the shared secret		-- name as in the commonName field of the sender field
	-- information
	transactionID REQUIRED		transactionID REQUIRED
	-- In the first message of a PKI management operation: MUST be		-- In the first message of a PKI management operation, MUST be
	-- 128 bits of random data, to minimize the probability of		-- 128 bits of random data to minimize the probability of
	-- having the transactionID already in use at the server		-- having the transactionID already in use at the server
	-- In all other messages: MUST be the value from the previous		-- In all other messages, MUST be the value from the previous
	-- message in the same PKI management operation		-- message in the same PKI management operation
	senderNonce REQUIRED		senderNonce REQUIRED
	-- MUST be cryptographically secure and fresh 128 random bits		-- MUST be cryptographically secure and fresh 128 random bits
	recipNonce RECOMMENDED		recipNonce RECOMMENDED
	-- If this is the first message of a transaction: MUST be absent		-- If this is the first message of a transaction, MUST be absent
	-- If this is a delayed response message: MUST be present and		-- If this is a delayed response message, MUST be present and
	-- contain the value of the senderNonce of the respective		-- contain the value of the senderNonce of the respective
	-- request message in the same transaction		-- request message in the same transaction
	-- In all other messages: MUST be present and contain the value		-- In all other messages, MUST be present and contain the value
	-- of the senderNonce of the previous message in the same		-- of the senderNonce of the previous message in the same
	-- transaction		-- transaction
	generalInfo OPTIONAL		generalInfo OPTIONAL
	implicitConfirm OPTIONAL		implicitConfirm OPTIONAL
	-- RECOMMENDED in ir/cr/kur/p10cr messages,		-- RECOMMENDED in ir/cr/kur/p10cr messages,
	-- OPTIONAL in ip/cp/kup response messages, and		-- OPTIONAL in ip/cp/kup response messages, and
	-- PROHIBITED in other types of messages		-- PROHIBITED in other types of messages
	-- Added to request messages to request omission of the certConf		-- Added to request messages to request omission of the certConf
	-- message		-- message
	-- Added to response messages to grant omission of the certConf		-- Added to response messages to grant omission of the certConf
	-- message		-- message
	-- See [RFC4210] Section 5.1.1.1.		-- See [RFC4210], Section 5.1.1.1.
	ImplicitConfirmValue REQUIRED		ImplicitConfirmValue REQUIRED
	-- ImplicitConfirmValue MUST be NULL		-- ImplicitConfirmValue MUST be NULL
	confirmWaitTime OPTIONAL		confirmWaitTime OPTIONAL
	-- RECOMMENDED in ip/cp/kup messages if implicitConfirm is		-- RECOMMENDED in ip/cp/kup messages if implicitConfirm is
	-- not included		-- not included
	-- PROHIBITED if implicitConfirm is included		-- PROHIBITED if implicitConfirm is included
	-- See [RFC4210] Section 5.1.1.2.		-- See [RFC4210], Section 5.1.1.2.
	ConfirmWaitTimeValue REQUIRED		ConfirmWaitTimeValue REQUIRED
	-- ConfirmWaitTimeValue MUST be a GeneralizedTime value		-- ConfirmWaitTimeValue MUST be a GeneralizedTime value
	-- specifying the point in time up to which the PKI management		-- specifying the point in time up to which the PKI management
	-- entity will wait for the certConf message. The accepted		-- entity will wait for the certConf message. The accepted
	-- length of the waiting period will vary by use case.		-- length of the waiting period will vary by use case.
	certProfile OPTIONAL		certProfile OPTIONAL
	-- MAY be present in ir/cr/kur/p10cr and in genm messages of type		-- MAY be present in ir/cr/kur/p10cr and in genm messages of type
	-- id-it-certReqTemplate		-- id-it-certReqTemplate
	-- MUST be omitted in all other messages		-- MUST be omitted in all other messages
	-- See [RFCAAAA]		-- See [RFC9480].
	CertProfileValue REQUIRED		CertProfileValue REQUIRED
	-- MUST contain a sequence of one UTF8String element		-- MUST contain a sequence of one UTF8String element
	-- MUST contain the name of a certificate profile		-- MUST contain the name of a certificate profile
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="Protection" numbered="true" toc="default">		<section anchor="Protection" numbered="true" toc="default">
	<name>General Description of the CMP Message Protection</name>		<name>General Description of the CMP Message Protection</name>
	<t>This section describes the generic protection field contents of all C		<t>This section describes the generic protection field contents of all C
	MP messages. For signature-based protection, which is the default protection me		MP messages. For signature-based protection, which is the default protection me
	chanism for all CMP messages described in this profile, the CMP protection key a		chanism for all CMP messages described in this profile, the CMP protection key a
	nd CMP protection certificate are used. For MAC-based protection shared secret i		nd CMP protection certificate are used. For MAC-based protection, shared secret
	nformation is used as described in <xref target="EE_MAC" format="default"/>.</t>		information is used as described in <xref target="EE_MAC" format="default"/>.</t
	<artwork align="left" name="" type="" alt=""><![CDATA[		>
			<sourcecode type="pseudocode"><![CDATA[
	protection		protection
	-- If present, the same kind of protection MUST be used for all		-- If present, the same kind of protection MUST be used for all
	-- messages of that PKI management operation.		-- messages of that PKI management operation.
	-- MUST be present, except if protection is not possible for		-- MUST be present, except if protection is not possible for
	-- error messages as described in Section 3.6.4.		-- error messages as described in Section 3.6.4
	-- For signature-based protection MUST contain the signature		-- For signature-based protection, MUST contain the signature
	-- calculated using the CMP protection key of the entity		-- calculated using the CMP protection key of the entity
	-- protecting the message.		-- protecting the message
	-- For MAC-based protection MUST contain a MAC calculated using		-- For MAC-based protection, MUST contain a MAC calculated using
	-- the shared secret information.		-- the shared secret information
	-- The protection algorithm used MUST be given in the		-- The protection algorithm used MUST be given in the
	-- protectionAlg field.		-- protectionAlg field.
	]]></artwork>		]]></sourcecode>
	<t>The CMP message protection provides, if available, message origin aut hentication and integrity protection for the header and body. The CMP message ex traCerts field is not covered by this protection.</t>		<t>The CMP message protection provides, if available, message origin aut hentication and integrity protection for the header and body. The CMP message ex traCerts field is not covered by this protection.</t>
	<t>Note: The extended key usages described in <xref target="I-D.ietf-lam ps-cmp-updates" format="default">CMP Updates Section 2.2</xref> can be used for authorization of a sending PKI management entity.</t>		<t>Note: The extended key usages described in <xref target="RFC9480" for mat="default" sectionFormat="of" section="2.2">CMP Updates</xref> can be used fo r authorization of a sending PKI management entity.</t>
	</section>		</section>
	<section anchor="extraCerts" numbered="true" toc="default">		<section anchor="extraCerts" numbered="true" toc="default">
	<name>General Description of CMP Message ExtraCerts</name>		<name>General Description of CMP Message ExtraCerts</name>
	<t>This section describes the generic extraCerts field of all CMP messag es. Any specific requirements on the extraCerts are specified in the respective PKI management operation.</t>		<t>This section describes the generic extraCerts field of all CMP messag es. Any specific requirements on the extraCerts are specified in the respective PKI management operation.</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	extraCerts		extraCerts
	-- MUST be present for signature-based protection and contain the		-- MUST be present for signature-based protection and contain the
	-- CMP protection certificate together with its chain for the		-- CMP protection certificate together with its chain for the
	-- first request and response message of a PKI management		-- first request and response message of a PKI management
	-- operation. MAY be omitted in certConf, PKIConf, pollReq, and		-- operation. MAY be omitted in certConf, PKIConf, pollReq,
	-- pollRep messages. The first certificate in this field MUST		-- and pollRep messages. The first certificate in this field
	-- be the CMP protection certificate followed by its chain		-- MUST be the CMP protection certificate followed by its
	-- where each element should directly certify the one		-- chain, where each element should directly certify the one
	-- immediately preceding it.		-- immediately preceding it.
	-- MUST be present in ip, cp, and kup messages and contain the		-- MUST be present in ip, cp, and kup messages and contain the
	-- chain of a newly issued certificate.		-- chain of a newly issued certificate.
	-- Self-signed certificates should be omitted from extraCerts and		-- Self-signed certificates should be omitted from extraCerts and
	-- MUST NOT be trusted based on their inclusion in any case		-- MUST NOT be trusted based on their inclusion in any case
	]]></artwork>		]]></sourcecode>
	<t>Note: One reason for adding a self-signed certificate to extraCerts i		<t>Note: One reason for adding a self-signed certificate to extraCerts i
	s if it is the CMP protection certificate or a successor root CA self-signed cer		s if it is the CMP protection certificate or a successor root CA self-signed cer
	tificate as indicated in the HashOfRootKey extension of the current root CA cert		tificate as indicated in the HashOfRootKey extension of the current root CA cert
	ificate, see <xref target="RFC8649" format="default"></xref>. Another reason for		ificate; see <xref target="RFC8649" format="default"></xref>.
	including self-signed certificates in the extraCerts is, for instance due to st		Another reason
	orage limitations, a receiving PKI entity may not have the complete trust anchor		for including self-signed certificates in the extraCerts is, for
	as self-signed certificate available but just unique identification of it, and		instance, due to storage limitations. A receiving PKI entity may not
	thus needs the full self-signed certificate for further processing (see also <xr		have the complete trust anchor information available
	ef target="Security" format="default"/>).</t>		but just a unique identification of it and thus needs the full
	<t>For maximum interoperability, all implementations SHOULD be pr		trust anchor information carried in a self-signed certificate for further
	epared to handle potentially additional certificates and arbitrary orderings of		processing (see <xref target="Security" format="default"/>).</t>
	the certificates.</t>		<t>For maximum interoperability, all implementations <bcp14>SHOUL
			D</bcp14> be prepared to handle potentially additional certificates and arbitrar
			y orderings of the certificates.</t>
	</section>		</section>
	<section anchor="Prereq" numbered="true" toc="default">		<section anchor="Prereq" numbered="true" toc="default">
	<name>Generic PKI Management Operation Prerequisites</name>		<name>Generic PKI Management Operation Prerequisites</name>
	<t>This subsection describes what is generally needed by the PKI entitie s to be able to perform PKI management operations.</t>		<t>This subsection describes what is generally needed by the PKI entitie s to be able to perform PKI management operations.</t>
	<t keepWithNext="true">Identification of PKI entities:</t>		<t keepWithNext="true">Identification of PKI entities:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>For signature-based protection each EE knows its own identity from the CMP protection certificate and for MAC-based protection it MAY know its ide ntity to fill the sender field.</li>		<li>For signature-based protection, each EE knows its own identity fro m the CMP protection certificate; for MAC-based protection, it <bcp14>MAY</bcp14 > know its identity to fill the sender field.</li>
	<li>		<li>
	<t>Each EE MAY know the intended recipient of its request		<t>Each EE <bcp14>MAY</bcp14> know the intended recipient of its requ
	s to fill the recipient field, e.g., the name of the addressed CA.</t>		ests to fill the recipient field, e.g., the name of the addressed CA.</t>
	<t>Note: This name may be established using an enrollment		<t>Note: This name may be established using an enrollment
	voucher, e.g., <xref target="RFC8366" format="default"></xref>, the issuer fiel		voucher (as described in <xref target="RFC8366" format="default"></xref>), the
	d from a CertReqTemplate response message content, or by other configuration mea		issuer field from a CertReqTemplate response message content, or by other config
	ns.</t>		uration means.</t>
	</li>		</li>
	</ul>		</ul>
	<t keepWithNext="true">Routing of CMP messages:</t>		<t keepWithNext="true">Routing of CMP messages:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>Each PKI entity sending messages upstream MUST know th		<t>Each PKI entity sending messages upstream <bcp14>MUST<
	e address needed for transferring messages to the next PKI management entity in		/bcp14> know the address needed for transferring messages to the next PKI manage
	case online-transfer is used.</t>		ment entity in case online transfer is used.</t>
	<t>Note: This address may depend on the recipient, the ce		<t>Note: This address may depend on the recipient, the ce
	rtificate profile, and on the used transfer mechanism.</t>		rtificate profile, and the used transfer mechanism.</t>
	</li>		</li>
	</ul>		</ul>
	<t keepWithNext="true">Authentication of PKI entities:</t>		<t keepWithNext="true">Authentication of PKI entities:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Each PKI entity MUST have credentials to authenticate itself. For signature-based protection it MUST have a private key and the corresponding cert ificate along with its chain.</li>		<li>Each PKI entity <bcp14>MUST</bcp14> have credentials to authentica te itself. For signature-based protection, it <bcp14>MUST</bcp14> have a private key and the corresponding certificate along with its chain.</li>
	<li>		<li>
	<t>Each PKI entity MUST be able to establish trust in PKI		<t>Each PKI entity <bcp14>MUST</bcp14> be able to establi
	it receives responses from. When signature-based protection is used, it MUST ha		sh trust in the PKI it receives responses from. When signature-based protection
	ve the trust anchor(s) and any certificate status information needed to perform		is used, it <bcp14>MUST</bcp14> have the trust anchor(s) and any certificate sta
	path validation of CMP protection certificates used for signature-based protecti		tus information needed to perform path validation of CMP protection certificates
	on.</t>		used for signature-based protection.</t>
	<t>Note: A trust anchor usually is a root certificate of		<t>Note: A trust anchor is usually a root certificate of
	the PKI addressed by the requesting EE. It may be established by configuration o		the PKI addressed by the requesting EE. It may be established by configuration o
	r in an out-of-band manner. For an EE it may be established using an enrollment		r in an out-of-band manner. For an EE, it may be established using an enrollmen
	voucher <xref target="RFC8366" format="default"></xref> or in-band of CMP by th		t voucher <xref target="RFC8366" format="default"></xref> or in-band of CMP by t
	e caPubs field in a certificate response message.</t>		he caPubs field in a certificate response message.</t>
	</li>		</li>
	</ul>		</ul>
	<t keepWithNext="true">Authorization of PKI management operations:</t>		<t keepWithNext="true">Authorization of PKI management operations:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>Each EE or RA MUST have sufficient information to be a		<t>Each EE or RA <bcp14>MUST</bcp14> have sufficient info
	ble to authorize the PKI management entity for performing the upstream PKI manag		rmation to be able to authorize the PKI management entity to perform the upstrea
	ement operation.</t>		m PKI management operation.</t>
	<t>Note: This may be achieved for example by using the cm		<t>Note: This may be achieved, for example, by using the
	cRA extended key usage in server certificates, by local configuration such as sp		cmcRA extended key usage in server certificates, by local configuration (such as
	ecific name patterns for subject DN or SAN portions that may identify an RA, and		specific name patterns for subject Distinguished Name (DN) or Subject Alternati
	/or by having a dedicated root CA usable only for authenticating PKI management		ve Name (SAN) portions that may identify an RA) and/or by having a dedicated roo
	entities.</t>		t CA usable only for authenticating PKI management entities.</t>
	</li>		</li>
	<li>		<li>
	<t>Each PKI management entity MUST have sufficient inform		<t>Each PKI management entity <bcp14>MUST</bcp14> have su
	ation to be able to authorize the downstream PKI entity requesting the PKI manag		fficient information to be able to authorize the downstream PKI entity requestin
	ement operation.</t>		g the PKI management operation.</t>
	<t>Note: For authorizing an RA the same examples apply as		<t>Note: For authorizing an RA, the same examples apply a
	above. The authorization of EEs can be very specific to the application domain		s above. The authorization of EEs can be very specific to the application domain
	based on local PKI policy.</t>		based on local PKI policy.</t>
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="Validation" numbered="true" toc="default">		<section anchor="Validation" numbered="true" toc="default">
	<name>Generic Validation of a PKI Message</name>		<name>Generic Validation of a PKI Message</name>
	<t>This section describes generic validation steps of each PKI entity re		<t>This section describes generic validation steps of each PKI entity re
	ceiving a PKI request or response message before any further processing or forwa		ceiving a PKI request or response message before any further processing or forwa
	rding. If a PKI management entity decides to terminate a PKI management operati		rding. If a PKI management entity decides to terminate a PKI management operati
	on because a check failed, it MUST send a negative response or an error message		on because a check failed, it <bcp14>MUST</bcp14> send a negative response or an
	as described in <xref target="Error" format="default"/>. The PKIFailureInfo bits		error message as described in <xref target="Error" format="default"/>. The PKIF
	given below in parentheses MAY be used in the failInfo field of the PKIStatusIn		ailureInfo bits given below in parentheses <bcp14>MAY</bcp14> be used in the fai
	fo as described in <xref target="Error_reporting" format="default"/>, see also <		lInfo field of the PKIStatusInfo as described in <xref target="Error_reporting"
	xref target="RFC4210" format="default">RFC&nbsp;4210 Appendix F</xref>.</t>		format="default"/>; also see <xref target="RFC4210" format="default" sectionForm
	<t>All PKI message header fields not mentioned in this section like the		at="of" section="F"/>.</t>
	recipient and generalInfo fields SHOULD be handled gracefully on reception.</t>		<t>All PKI message header fields not mentioned in this section, like the
	<t keepWithNext="true">The following list describes the basic set of mes		recipient and generalInfo fields, <bcp14>SHOULD</bcp14> be handled gracefully u
	sage input validation steps. Without these checks the protocol becomes dysfuncti		pon receipt.</t>
	onal.</t>		<t keepWithNext="true">The following list describes the basic set of mes
			sage input validation steps. Without these checks, the protocol becomes dysfunct
			ional.</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The formal ASN.1 syntax of the whole message MUST be compliant wit		<li>The formal ASN.1 syntax of the whole message <bcp14>MUST</bcp14> b
	h the definitions given in <xref target="RFC4210" format="default">CMP</xref> an		e compliant with the definitions given in <xref target="RFC4210" format="default
	d <xref target="I-D.ietf-lamps-cmp-updates" format="default"/>, <xref target="RF		">CMP</xref> <xref target="RFC9480" format="default"/>, <xref target="RFC4211" f
	C4211" format="default">CRMF</xref>, and <xref target="RFC5652" format="default"		ormat="default">CRMF</xref>, and <xref target="RFC5652" format="default">CMS</xr
	>CMS</xref> and <xref target="RFC8933" format="default"/>. (failInfo: badDataFor		ef> <xref target="RFC8933" format="default"/>. (failInfo: badDataFormat)</li>
	mat)</li>		<li>The pvno <bcp14>MUST</bcp14> be cmp2000(2) or cmp2021(3). (failInf
	<li>The pvno MUST be cmp2000(2) or cmp2021(3). (failInfo bit: unsuppor		o bit: unsupportedVersion)</li>
	tedVersion)</li>		<li>The transactionID <bcp14>MUST</bcp14> be present. (failInfo bit: b
	<li>The transactionID MUST be present. (failInfo bit: badDataFormat)</		adDataFormat)</li>
	li>		<li>The PKI message body type <bcp14>MUST</bcp14> be one of the messag
	<li>The PKI message body type MUST be one of the message types support		e types supported by the receiving PKI entity and <bcp14>MUST</bcp14> be allowed
	ed by the receiving PKI entity and MUST be allowed in the current state of the P		in the current state of the PKI management operation identified by the given tr
	KI management operation identified by the given transactionID. (failInfo bit: ba		ansactionID. (failInfo bit: badRequest)</li>
	dRequest)</li>
	</ul>		</ul>
	<t keepWithNext="true">The following list describes the set of message i nput validation steps required to ensure secure protocol operation:</t>		<t keepWithNext="true">The following list describes the set of message i nput validation steps required to ensure secure protocol operation:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The senderNonce MUST be present and MUST contain at least 128 bits of data. (failInfo bit: badSenderNonce)</li>		<li>The senderNonce <bcp14>MUST</bcp14> be present and <bcp14>MUST</bc p14> contain at least 128 bits of data. (failInfo bit: badSenderNonce)</li>
	<li>		<li>
	<t>Unless the PKI message is the first message of a PKI management o peration,</t>		<t>Unless the PKI message is the first message of a PKI management o peration,</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>the recipNonce MUST be present and MUST equal the senderNonce of the previous message or equal the senderNonce of the most recent request mess age for which the response was delayed, in case of delayed delivery as specified in <xref target="EE_Polling" format="default"/>. (failInfo bit: badRecipientNon ce)</li>		<li>the recipNonce <bcp14>MUST</bcp14> be present and <bcp14>MUST< /bcp14> equal the senderNonce of the previous message or equal the senderNonce o f the most recent request message for which the response was delayed, in case of delayed delivery as specified in <xref target="EE_Polling" format="default"/>. (failInfo bit: badRecipientNonce)</li>
	</ul>		</ul>
	</li>		</li>
	<li>Messages without protection MUST be rejected except for err or messages as described in <xref target="Error_reporting" format="default"/>.</ li>		<li>Messages without protection <bcp14>MUST</bcp14> be rejected except for error messages as described in <xref target="Error_reporting" format ="default"/>.</li>
	<li>		<li>
	<t>The message protection MUST be validated when present and message s with an invalid protection MUST be rejected.</t>		<t>The message protection <bcp14>MUST</bcp14> be validated when pres ent, and messages with an invalid protection <bcp14>MUST</bcp14> be rejected.</t >
	<ul spacing="normal">		<ul spacing="normal">
	<li>The protection MUST be signature-based except if MAC-based pro		<li>The protection <bcp14>MUST</bcp14> be signature-based except i
	tection is used as described in <xref target="EE_MAC" format="default"/> and <xr		f MAC-based protection is used as described in Sections <xref target="EE_MAC" fo
	ef target="EE_KGPB" format="default"/>. (failInfo bit: wrongIntegrity)</li>		rmat="counter"/> and <xref target="EE_KGPB" format="counter"/>. (failInfo bit:
	<li>If present, the senderKID MUST identify the key material neede		wrongIntegrity)</li>
	d for verifying the message protection. (failInfo bit: badMessageCheck)</li>		<li>If present, the senderKID <bcp14>MUST</bcp14> identify the key
	<li>If signature-based protection is used, the CMP protection cert		material needed for verifying the message protection. (failInfo bit: badMessage
	ificate MUST be successfully validated including path validation using a trust a		Check)</li>
	nchor and MUST be authorized according to local policies. If the keyUsage extens		<li>If signature-based protection is used, the CMP protection cert
	ion is present in the CMP protection certificate the digitalSignature bit MUST b		ificate <bcp14>MUST</bcp14> be successfully validated, including path validation
	e set. (failInfo bit: badAlg, badMessageCheck, or signerNotTrusted)</li>		using a trust anchor, and <bcp14>MUST</bcp14> be authorized according to local
	<li>The sender of a request message MUST be authorized		policies. If the keyUsage extension is present in the CMP protection certificate
	for requesting the operation according to PKI policies. (failInfo bit: notAuthor		, the digitalSignature bit <bcp14>MUST</bcp14> be set. (failInfo bit: badAlg, ba
	ized)</li>		dMessageCheck, or signerNotTrusted)</li>
			<li>The sender of a request message <bcp14>MUST</bcp14>
			be authorized to request the operation according to PKI policies. (failInfo bit
			: notAuthorized)</li>
	</ul>		</ul>
	</li>		</li>
	<li></li>
	</ul>		</ul>
	<t>Note: The requirements for checking certificates given in <xre f target="RFC5280" format="default">RFC&nbsp;5280</xref> MUST be followed for si gnature-based CMP message protection. Unless the message is a positive ip/cp/ku p where the issuing CA certificate of the newly enrolled certificate is the same as the CMP protection certificate of that message, certificate status checking SHOULD be performed on the CMP protection certificates. If the response message contains the caPubs field to transfer new trust anchor information, the CMP pro tection is crucial and certificate status checking is REQUIRED. For other cases it MAY be acceptable to omit certificate status checking when respective inform ation is not available.</t>		<t>Note: The requirements for checking certificates given in <xre f target="RFC5280" format="default"/> <bcp14>MUST</bcp14> be followed for signat ure-based CMP message protection. Unless the message is a positive ip/cp/kup, w here the issuing CA certificate of the newly enrolled certificate is the same as the CMP protection certificate of that message, certificate status checking <bc p14>SHOULD</bcp14> be performed on the CMP protection certificates. If the resp onse message contains the caPubs field to transfer new trust anchor information, the CMP protection is crucial and certificate status checking is <bcp14>REQUIRE D</bcp14>. For other cases, it <bcp14>MAY</bcp14> be acceptable to omit certifi cate status checking when respective information is not available.</t>
	<t keepWithNext="true">Depending on local policies, one or more of the i nput validation checks described below need to be implemented:</t>		<t keepWithNext="true">Depending on local policies, one or more of the i nput validation checks described below need to be implemented:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>If signature-based protection is used, the sender field MUST match the subject of the CMP protection certificate. (failInfo bit: badMessageCheck)< /li>		<li>If signature-based protection is used, the sender field <bcp14>MUS T</bcp14> match the subject of the CMP protection certificate. (failInfo bit: ba dMessageCheck)</li>
	<li>		<li>
	<t>If the messageTime is present and</t>		<t>If the messageTime is present and</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>the receiving system has a reliable system time, the messageTi		<li>the receiving system has a reliable system time, the messageTi
	me MUST be close to the current time of the receiving system, where the threshol		me <bcp14>MUST</bcp14> be close to the current time of the receiving system, whe
	d will vary by use case. (failInfo bit: badTime)</li>		re the threshold will vary by use case. (failInfo bit: badTime)</li>
	<li>the receiving system does not have a reliable system time, the		<li>the receiving system does not have a reliable system time, the
	messageTime MAY be used for time synchronization.</li>		messageTime <bcp14>MAY</bcp14> be used for time synchronization.</li>
	</ul>		</ul>
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="Error" numbered="true" toc="default">		<section anchor="Error" numbered="true" toc="default">
	<name>Error Handling</name>		<name>Error Handling</name>
	<t>This section describes how a PKI entity handles error conditions on m essages it receives. Each error condition should be logged appropriately to allo w root-cause analysis of failure cases.</t>		<t>This section describes how a PKI entity handles error conditions on m essages it receives. Each error condition should be logged appropriately to allo w root-cause analysis of failure cases.</t>
	<section anchor="Error_upstream" numbered="true" toc="default">		<section anchor="Error_upstream" numbered="true" toc="default">
	<name>Reporting Error Conditions Upstream</name>		<name>Reporting Error Conditions Upstream</name>
	<t>An EE SHALL NOT send error messages. PKI management entitie		<t>An EE <bcp14>SHALL NOT</bcp14> send error messages. PKI man
	s SHALL NOT send error messages in the upstream direction, either.</t>		agement entities <bcp14>SHALL NOT</bcp14> send error messages in the upstream di
	<t>In case an EE rejects a newly issued certificate contained i		rection either.</t>
	n an ip, cp, or kup message and implicit confirmation has not been granted, the		<t>In case an EE rejects a newly issued certificate contained i
	EE MUST report this using a certConf message with "rejection" status and await t		n an ip, cp, or kup message and implicit confirmation has not been granted, the
	he pkiConf response as described in <xref target="EE_newPKI" format="default"/>.		EE <bcp14>MUST</bcp14> report this using a certConf message with "rejection" sta
	</t>		tus and await the pkiConf response as described in <xref target="EE_newPKI" form
	<t>On all other error conditions regarding response messages, t		at="default"/>.</t>
	he EE or PKI management entity MUST regard the current PKI management operation		<t>On all other error conditions regarding response messages, t
	as terminated with failure. The error conditions include</t>		he EE or PKI management entity <bcp14>MUST</bcp14> regard the current PKI manage
			ment operation as terminated with failure. The error conditions include:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>invalid response message header, body type, protection, or extra Certs according to the checks described in <xref target="Validation" format="def ault"/>,</li>		<li>invalid response message header, body type, protection, or extra Certs, according to the checks described in <xref target="Validation" format="de fault"/>,</li>
	<li>any issue detected with response message contents,</li>		<li>any issue detected with response message contents,</li>
	<li>receipt of an error message from upstream,</li>		<li>receipt of an error message from upstream,</li>
	<li>timeout occurred while waiting for a response,</li>		<li>timeout occurred while waiting for a response, and</li>
	<li>rejection of a newly issued certificate while implicit confirmat ion has been granted.</li>		<li>rejection of a newly issued certificate while implicit confirmat ion has been granted.</li>
	</ul>		</ul>
	<t>Upstream PKI management entities will not receive any CMP me ssage to learn that the PKI management operation has been terminated. In case t hey expect a further message from the EE, a connection interruption or timeout w ill occur. The value set for such timeouts will vary by use case. Then they als o MUST regard the current PKI management operation as terminated with failure an d MUST NOT attempt to send an error message downstream.</t>		<t>Upstream PKI management entities will not receive any CMP me ssage to learn that the PKI management operation has been terminated. In case t hey expect a further message from the EE, a connection interruption or timeout w ill occur. The value set for such timeouts will vary by use case. Then they <bc p14>MUST</bcp14> also regard the current PKI management operation as terminated with failure and <bcp14>MUST NOT</bcp14> attempt to send an error message downst ream.</t>
	</section>		</section>
	<section anchor="Error_downstream" numbered="true" toc="default">		<section anchor="Error_downstream" numbered="true" toc="default">
	<name>Reporting Error Conditions Downstream</name>		<name>Reporting Error Conditions Downstream</name>
	<t>In case the PKI management entity detects an error condition		<t>In case the PKI management entity detects an error condition
	, e.g., rejecting the request due to policy decision, in the body of an ir, cr,		, e.g., rejecting the request due to policy decision, in the body of an ir, cr,
	p10cr, kur, or rr message received from downstream, it MUST report the error in		p10cr, kur, or rr message received from downstream, it <bcp14>MUST</bcp14> repor
	the specific response message, i.e., an ip, cp, kup, or rp with "rejection" stat		t the error in the specific response message, i.e., an ip, cp, kup, or rp with "
	us, as described in <xref target="EE_newPKI" format="default"/> and <xref target		rejection" status, as described in Sections <xref target="EE_newPKI" format="cou
	="EE_Revoke" format="default"/>. This can also happen in case of polling.</t>		nter"/> and <xref target="EE_Revoke" format="counter"/>. This can also happen in
	<t>In case the PKI management entity detects any other error co		case of polling.</t>
	ndition on requests, including pollReq, certConf, genm, and nested messages, rec		<t>In case the PKI management entity detects any other error co
	eived from downstream and on responses received from upstream, such as invalid m		ndition on requests (including pollReq, certConf, genm, and nested messages) rec
	essage header, body type, protection, or extraCerts according to the checks desc		eived from downstream and on responses received from upstream (such as invalid m
	ribed in <xref target="Validation" format="default"/> it MUST report them downst		essage header, body type, protection, or extraCerts, according to the checks des
	ream in the form of an error message as described in <xref target="Error_reporti		cribed in <xref target="Validation" format="default"/>), it <bcp14>MUST</bcp14>
	ng" format="default"/>.</t>		report them downstream in the form of an error message as described in <xref tar
			get="Error_reporting" format="default"/>.</t>
	</section>		</section>
	<section anchor="Error_nested" numbered="true" toc="default">		<section anchor="Error_nested" numbered="true" toc="default">
	<name>Handling Error Conditions on Nested Messages Used for Batching</ name>		<name>Handling Error Conditions on Nested Messages Used for Batching</ name>
	<t>Batching of messages using nested messages as described in < xref target="RA_AddBatch" format="default"/> requires special error handling.</t >		<t>Batching of messages using nested messages as described in < xref target="RA_AddBatch" format="default"/> requires special error handling.</t >
	<t>If the error condition is on an upstream nested message cont aining batched requests, it MUST NOT attempt to respond to the individual reques ts included in it, but to the nested message itself.</t>		<t>If the error condition is on an upstream nested message cont aining batched requests, it <bcp14>MUST NOT</bcp14> attempt to respond to the in dividual requests included in it but to the nested message itself.</t>
	<t>In case a PKI management entity receives an error message in response to a nested message, it must propagate the error by responding with an error message to each of the request messages contained in the nested message.< /t>		<t>In case a PKI management entity receives an error message in response to a nested message, it must propagate the error by responding with an error message to each of the request messages contained in the nested message.< /t>
	<t>In case a PKI management entity detects an error condition o n the downstream nested message received in response to a nested message sent be fore and the body of the received nested message still parses, it MAY ignore thi s error condition and handle the included responses as described in <xref target ="RA_AddBatch" format="default"/>. Otherwise, it MUST propagate the error by res ponding with an error message to each of the requests contained in the nested me ssage it sent originally.</t>		<t>In case a PKI management entity detects an error condition o n the downstream nested message received in response to a nested message sent be fore and the body of the received nested message still parses, it <bcp14>MAY</bc p14> ignore this error condition and handle the included responses as described in <xref target="RA_AddBatch" format="default"/>. Otherwise, it <bcp14>MUST</bcp 14> propagate the error by responding with an error message to each of the reque sts contained in the nested message it sent originally.</t>
	</section>		</section>
	<section anchor="Error_reporting" numbered="true" toc="default">		<section anchor="Error_reporting" numbered="true" toc="default">
	<name>PKIStatusInfo and Error Messages</name>		<name>PKIStatusInfo and Error Messages</name>
	<t>When sending any kind of negative response, including error		<t>When sending any kind of negative response, including error
	messages, a PKI entity MUST indicate the error condition in the PKIStatusInfo st		messages, a PKI entity <bcp14>MUST</bcp14> indicate the error condition in the P
	ructure of the respective message as described below. It then MUST regard the c		KIStatusInfo structure of the respective message as described below. Then it <b
	urrent PKI management operation as terminated with failure.</t>		cp14>MUST</bcp14> regard the current PKI management operation as terminated with
	<t keepWithNext="true">The PKIStatusInfo structure is used to r		failure.</t>
	eport errors. It may be part of various message types, in particular: ip, cp, k		<t keepWithNext="true">The PKIStatusInfo structure is used to r
	up, certConf, and error. The PKIStatusInfo structure consists of the following f		eport errors. It may be part of various message types, in particular, ip, cp, k
	ields:</t>		up, certConf, and error. The PKIStatusInfo structure consists of the following f
	<ul spacing="normal">		ields:</t>
	<li>status: Here the PKIStatus value "rejection" MUST be used in cas
	e an error was detected. When a PKI management entity indicates delayed deliver		<dl spacing="normal">
	y of a CMP response message to the EE with an error message as described in <xre		<dt>status:</dt>
	f target="EE_Polling" format="default"/>, the status "waiting" MUST be used ther		<dd>Here, the PKIStatus value "rejection" <bcp14>MUST</bcp14> be used
	e.</li>		in case an error was detected. When a PKI management entity indicates delayed
	<li>statusString: Here any human-readable valid value for logging or		delivery of a CMP response message to the EE with an error message as described
	to display via a user interface should be added.</li>		in <xref target="EE_Polling" format="default"/>, the status "waiting" <bcp14>MUS
	<li>		T</bcp14> be used there.</dd>
	<t>failInfo: Here the PKIFailureInfo bits MAY be used in the way e		<dt>statusString:</dt>
	xplained in <xref target="RFC4210" format="default">Appendix F of RFC&nbsp;4210<		<dd>Here, any human-readable valid value for logging or to display vi
	/xref>. PKIFailureInfo bits regarding the validation described in <xref target=		a a user interface should be added.</dd>
	"Validation" format="default"/> are referenced there. The PKIFailureInfo bits re
	ferenced in Sections <xref target="RA_response" format="counter"/> and <xref tar		<dt>failInfo:</dt>
	get="Transfer_types" format="counter"/> are described here:</t>		<dd>
	<ul spacing="normal">		<t>Here, the PKIFailureInfo bits <bcp14>MAY</bcp14> be used in the
	<li>badCertId: A kur, certConf, or rr message references an unkn		way explained in <xref target="RFC4210" format="default" sectionFormat="of" sect
	own certificate</li>		ion="F"/>. PKIFailureInfo bits regarding the validation described in <xref targ
	<li>badPOP: An ir/cr/kur/p10cr contains an invalid proof-of-poss		et="Validation" format="default"/> are referenced there. The PKIFailureInfo bits
	ession</li>		referenced in Sections <xref target="RA_response" format="counter"/> and <xref
	<li>certRevoked: Revocation requested for a certificate already		target="Transfer_types" format="counter"/> are described here:</t>
	revoked</li>
	<li>badCertTemplate: The contents of a certificate request are n		<dl spacing="normal">
	ot accepted, e.g., a field is missing or has a non-acceptable value or the given		<dt>badCertId:</dt><dd>A kur, certConf, or rr message references
	public key is already in use in some other certificate (depending on policy).</		an unknown certificate.</dd>
	li>		<dt>badPOP:</dt><dd>An ir/cr/kur/p10cr contains an invalid proof
	<li>transactionIdInUse: This is sent by a PKI management entity		-of-possession.</dd>
	in case the received request contains a transactionID that is currently in use f		<dt>certRevoked:</dt><dd>Revocation is requested for a certifica
	or another transaction. An EE receiving such error message should resend the re		te that is already revoked.</dd>
	quest in a new transaction using a different transactionID.</li>		<dt>badCertTemplate:</dt><dd>The contents of a certificate reque
	<li>notAuthorized: The sender of a request messag		st are not accepted, e.g., a field is missing or has an unacceptable value or th
	e is not authorized for requesting the operation.</li>		e given public key is already in use in some other certificate (depending on pol
	<li>systemUnavail: This is sent by a PKI management entity in ca		icy).</dd>
	se a back-end system is not available.</li>		<dt>transactionIdInUse:</dt><dd> This is sent by a PKI managemen
	<li>systemFailure: This is sent by a PKI management entity in ca		t entity in case the received request contains a transactionID that is currently
	se a back-end system is currently not functioning correctly.</li>		in use for another transaction. An EE receiving such an error message should r
	</ul>		esend the request in a new transaction using a different transactionID.</dd>
	</li>		<dt>notAuthorized:</dt><dd> The sender of a reque
	</ul>		st message is not authorized for requesting the operation.</dd>
			<dt>systemUnavail:</dt><dd>This is sent by a PKI management enti
			ty in case a back-end system is not available.</dd>
			<dt>systemFailure:</dt><dd>This is sent by a PKI management enti
			ty in case a back-end system is currently not functioning correctly.</dd>
			</dl>
			</dd>
			</dl>
	<t>An EE receiving a systemUnavail or systemFailure failInfo sh ould resend the request in a new transaction after some time.</t>		<t>An EE receiving a systemUnavail or systemFailure failInfo sh ould resend the request in a new transaction after some time.</t>
	<t keepWithNext="true">Detailed Message Description:</t>		<t keepWithNext="true">Detailed Message Description:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	Error Message -- error		Error Message -- error
	Field Value		Field Value
	header		header
	-- As described in Section 3.1		-- As described in Section 3.1
	body		body
	-- The message indicating the error that occurred		-- The message indicating the error that occurred
	error REQUIRED		error REQUIRED
	pKIStatusInfo REQUIRED		pKIStatusInfo REQUIRED
	status REQUIRED		status REQUIRED
	-- MUST have the value "rejection"		-- MUST have the value "rejection"
	statusString OPTIONAL		statusString OPTIONAL
	-- This field should contain any human-readable text for		-- This field should contain any human-readable text for
	-- debugging, logging or to display in a GUI		-- debugging, for logging, or to display in a GUI
	failInfo OPTIONAL		failInfo OPTIONAL
	-- MAY be present and contain the relevant PKIFailureInfo bits		-- MAY be present and contain the relevant PKIFailureInfo bits
	protection RECOMMENDED		protection RECOMMENDED
	-- As described in Section 3.2		-- As described in Section 3.2
	extraCerts RECOMMENDED		extraCerts RECOMMENDED
	-- As described in Section 3.3		-- As described in Section 3.3
	]]></artwork>		]]></sourcecode>
	<t>Protecting the error message may not be technically fe		<t>Protecting the error message may not be technically fe
	asible if it is not clear which credential the recipient will be able to use whe		asible if it is not clear which credential the recipient will be able to use whe
	n validating this protection, e.g., in case the request message was fundamentall		n validating this protection, e.g., in case the request message was fundamentall
	y broken. In these exceptional cases the protection of the error message MAY be		y broken. In these exceptional cases, the protection of the error message <bcp1
	omitted.</t>		4>MAY</bcp14> be omitted.</t>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="EE_UseCases" numbered="true" toc="default">		<section anchor="EE_UseCases" numbered="true" toc="default">
	<name>PKI Management Operations</name>		<name>PKI Management Operations</name>
	<t>This chapter focuses on the communication of an EE with the PKI managem ent entity it directly talks to. Depending on the network and PKI solution, thi s can be an RA or directly a CA. Handling of a message by a PKI management entit y is described in <xref target="RA_UseCases" format="default"/>.</t>		<t>This section focuses on the communication of an EE with the PKI managem ent entity it directly talks to. Depending on the network and PKI solution, thi s can be an RA or directly a CA. Handling of a message by a PKI management entit y is described in <xref target="RA_UseCases" format="default"/>.</t>
	<t keepWithNext="true">The PKI management operations specified in this sec tion cover the following:</t>		<t keepWithNext="true">The PKI management operations specified in this sec tion cover the following:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Requesting a certificate with variations like initial enrollment, ce		<li>requesting a certificate with variations like initial enrollment, ce
	rtificate updates, central key generation, and MAC-based protection</li>		rtificate updates, central key generation, and MAC-based protection</li>
	<li>Revoking a certificate</li>		<li>revoking a certificate</li>
	<li>Support messages</li>		<li>support messages</li>
	<li>Polling for delayed response messages</li>		<li>polling for delayed response messages</li>
	</ul>		</ul>
	<t>These operations mainly specify the message body of the CMP messages an		<t>These operations mainly specify the message body of the CMP messages an
	d utilize the specification of the message header, protection and extraCerts as		d utilize the specification of the message header, protection, and extraCerts, a
	specified in <xref target="GenericParts" format="default"/>. The messages are na		s specified in <xref target="GenericParts" format="default"/>. The messages are
	med by the respective field names in PKIBody like ir, ip, cr, cp, etc., see <xre		named by the respective field names in PKIBody, like ir, ip, cr, cp, etc.; see <
	f target="RFC4210" format="default">RFC&nbsp;4210 Section 5.1.2</xref>.</t>		xref target="RFC4210" format="default" sectionFormat="of" section="5.1.2"/>.</t>
	<t>The following diagram shows the EE state machine covering all PKI manag		<t>The following diagram shows the EE state machine covering all PKI manag
	ement operations described in this section, including negative responses, error		ement operations described in this section, including negative responses, error
	messages described in <xref target="Error_reporting" format="default"/>, as well		messages described in <xref target="Error_reporting" format="default"/>, ip/cp/k
	as ip/cp/kup/error messages with status "waiting", pollReq, and pollRep message		up/error messages with status "waiting", and pollReq and pollRep messages as des
	s as described in <xref target="EE_Polling" format="default"/>.</t>		cribed in <xref target="EE_Polling" format="default"/>.</t>
	<t>On receiving messages from upstream, the EE MUST perform the general		<t>On receiving messages from upstream, the EE <bcp14>MUST</bcp14> perform
	validation checks described in <xref target="Validation" format="default"/>. Th		the general validation checks described in <xref target="Validation" format="de
	e behavior in case an error occurs is described in <xref target="Error" format="		fault"/>. In case an error occurs, the behavior is described in <xref target="Er
	default"/>.</t>		ror" format="default"/>.</t>
			<t keepWithNext="true">End Entity State Machine:</t>
	<artwork anchor="EE_State_Machine" align="left" name="" type="" alt=""><![ CDATA[		<artwork anchor="EE_State_Machine" align="left" name="" type="" alt=""><![ CDATA[
	End Entity State Machine:
	start		start
	|		|
	| send ir/cr/kur/p10cr/rr/genm		| send ir/cr/kur/p10cr/rr/genm
	v		v
	waiting for response		waiting for response
	v		v
	+--------------------------+--------------------------+		+--------------------------+--------------------------+
	| | |		| | |
	| receives ip/cp/kup with | received ip/cp/kup/error | received		| receives ip/cp/kup with | received ip/cp/kup/error | received
	| status "accepted" or | with status "waiting" | rp/genp or		| status "accepted" or | with status "waiting" | rp/genp or
	skipping to change at line 680 ¶		skipping to change at line 646 ¶
	| | send certConf | |		| | send certConf | |
	| v | |		| v | |
	| waiting for pkiConf*) | |		| waiting for pkiConf*) | |
	| | | |		| | | |
	| | received | |		| | received | |
	| v pkiConf v |		| v pkiConf v |
	+---------------->+------->+<-------+<----------------+		+---------------->+------->+<-------+<----------------+
	|		|
	v		v
	end		end
			]]></artwork>
	*) In case of a delayed delivery of pkiConf responses the same		<dl newline="false" spacing="normal">
	polling mechanism is initiated as for rp or genp messages, by		<dt>*)</dt>
	sending an error message with status "waiting".		<dd>In case of a delayed delivery of pkiConf responses, the same
	]]></artwork>		polling mechanism is initiated as for rp or genp messages by
	<t>Note: All CMP messages belonging to the same PKI management operation M		sending an error message with status "waiting".</dd>
	UST have the same transactionID because the message receiver identifies the elem		</dl>
	ents of the operation in this way.</t>		<t>Note: All CMP messages belonging to the same PKI management operation <
	<t>This section is aligned with <xref target="RFC4210" format="default">CM		bcp14>MUST</bcp14> have the same transactionID because the message receiver iden
	P</xref>, <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates		tifies the elements of the operation in this way.</t>
	</xref>, and <xref target="I-D.ietf-lamps-cmp-algorithms" format="default">CMP A		<t>This section is aligned with <xref target="RFC4210" format="default">CM
	lgorithms</xref>.</t>		P</xref>, <xref target="RFC9480" format="default">CMP Updates</xref>, and <xref
	<t>Guidelines as well as an algorithm use profile for this document are av		target="RFC9481" format="default">CMP Algorithms</xref>.</t>
	ailable in <xref target="I-D.ietf-lamps-cmp-algorithms" format="default">CMP Alg		<t>Guidelines as well as an algorithm use profile for this document are av
	orithms</xref>.</t>		ailable in <xref target="RFC9481" format="default">CMP Algorithms</xref>.</t>
	<section anchor="EE_request" numbered="true" toc="default">		<section anchor="EE_request" numbered="true" toc="default">
	<name>Enrolling End Entities</name>		<name>Enrolling End Entities</name>
	<t>There are various approaches for requesting a certificate from a PKI. </t>		<t>There are various approaches for requesting a certificate from a PKI. </t>
	<t keepWithNext="true">These approaches differ in the way the EE authent icates itself to the PKI, in the form of the request being used, and how the key pair to be certified is generated. The authentication mechanisms may be as foll ows:</t>		<t keepWithNext="true">These approaches differ in the way the EE authent icates itself to the PKI, in the form of the request being used, and how the key pair to be certified is generated. The authentication mechanisms may be as foll ows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Using a certificate from an external PKI, e.g., a manufacturer-iss		<li>using a certificate from an external PKI, e.g., a manufacturer-iss
	ued device certificate, and the corresponding private key</li>		ued device certificate, and the corresponding private key</li>
	<li>Using a private key and certificate issued from the same PK		<li>using a private key and certificate issued from the same PKI that i
	I that is addressed for requesting a certificate</li>		s addressed for requesting a certificate</li>
	<li>Using the certificate to be updated and the corresponding private		<li>using the certificate to be updated and the corresponding private
	key</li>		key</li>
	<li>Using shared secret information known to the EE and the PKI manage		<li>using shared secret information known to the EE and the PKI manage
	ment entity</li>		ment entity</li>
	</ul>		</ul>
	<t>An EE requests a certificate indirectly or directly from a CA. When		<t>An EE requests a certificate indirectly or directly from a CA. When
	the PKI management entity handles the request as described in <xref target="RA_r		the PKI management entity handles the request as described in <xref target="RA_r
	esponse_enrollment" format="default"/> and responds with a message containing th		esponse_enrollment" format="default"/> and responds with a message containing th
	e requested certificate, the EE MUST reply with a confirmation message unless im		e requested certificate, the EE <bcp14>MUST</bcp14> reply with a confirmation me
	plicitConfirm was granted. The PKI management entity then MUST handle it as desc		ssage unless implicitConfirm was granted. The PKI management entity <bcp14>MUST<
	ribed in <xref target="RA_response_confirmation" format="default"/> and respond		/bcp14> then handle it as described in <xref target="RA_response_confirmation"
	with a confirmation, closing the PKI management operation.</t>		format="default"/> and respond with a confirmation, closing the PKI management o
	<t>The message sequences described in this section allow the EE to reque		peration.</t>
	st certification of a locally or centrally generated public-private key pair. Ty		<t>The message sequences described in this section allow the EE to reque
	pically, the EE provides a signature-based proof-of-possession of the private k		st certification of a locally or centrally generated public-private key pair.
	ey associated with the public key contained in the certificate request as define		The public key and the subject name identifying the EE <bcp14>MUS
	d by <xref target="RFC4211" format="default">RFC&nbsp;4211 Section 4.1</xref> ca		T</bcp14> be present in the certTemplate of the certificate request message.</t>
	se 3. To this end it is assumed that the private key can technically be used for		<t>Note: If the EE does not know for which subject name to reques
	signing. This is the case for the most common algorithms RSA, ECDSA, and EdDSA		t the certificate, it can use the subject name from the CMP protection certifica
	regardless of potentially intended restrictions of the key usage.</t>		te in case of signature-based protection or the identifier of the shared secret
	<t>Note: <xref target="RFC4211" format="default">RFC&nbsp;4211 Section 4		in case of MAC-based protection.</t>
	</xref> allows for providing proof-of-possession using any method that a key can		<t>Typically, the EE provides a signature-based proof-of-possess
	be used for. In conformance with <xref target="NIST.SP.800-57p1r5" format="defa		ion of the private key associated with the public key contained in the certifica
	ult">NIST&nbsp;SP&nbsp;800-57 Part&nbsp;1 Section 8.1.5.1.1.2</xref> the newly g		te request, as defined by <xref target="RFC4211" format="default" sectionFormat=
	enerated private key may be used for self-signature, if technically possible, ev		"comma" section="4.1"/>, clause 3. To this end, it is assumed that the private k
	en if the keyUsage extension requested in the certificate request prohibits gene		ey can technically be used for signing. This is the case for the most common al
	ration of digital signatures.</t>		gorithms RSA, ECDSA, and EdDSA, regardless of potentially intended restrictions
			of the key usage.</t>
			<t>Note: <xref target="RFC4211" format="default" sectionFormat="of" sect
			ion="4"/> allows for providing proof-of-possession using any method that a key c
			an be used for. In conformance with Section 8.1.5.1.1.2 of <xref target="NIST.SP
			.800-57p1r5" format="default"/>, the newly generated private key may be used for
			self-signature, if technically possible, even if the keyUsage extension request
			ed in the certificate request prohibits generation of digital signatures.</t>
	<t>The requesting EE provides the binding of the proof-of-possession to its identity by signature-based or MAC-based protection of the CMP request messa ge containing that POP. An upstream PKI management entity should verify whether this EE is authorized to obtain a certificate with the requested subject and oth er fields and extensions.</t>		<t>The requesting EE provides the binding of the proof-of-possession to its identity by signature-based or MAC-based protection of the CMP request messa ge containing that POP. An upstream PKI management entity should verify whether this EE is authorized to obtain a certificate with the requested subject and oth er fields and extensions.</t>
	<t>The EE MAY indicate the certificate profile to use in the cert		<t>The proof-of-possession is provided by signing the certReq con
	Profile extension of the generalInfo field in the PKIHeader of the certificate r		taining the certTemplate with the subject name and public key. To bind this pro
	equest message as described in <xref target="Header" format="default"/>.</t>		of-of-possession to the proof-of-identity of the requesting EE, the subject name
	<t>In case the EE receives a CA certificate in the caPubs field for inst		in the certTemplate needs to identify the same entity as the subject name in th
	allation as a new trust anchor, it MUST properly authenticate the message and au		e CMP protection certificate or match the identifier used with MAC-based protect
	thorize the sender as trusted source of the new trust anchor. This authorizatio		ion.</t>
	n is typically indicated using shared secret information for protecting an initi		<t>Note: This binding may be lost if a PKI management entity repr
	alization response (ir) message. Authorization can also be signature-based using		otects this request message.</t>
	a certificate issued by another PKI that is explicitly authorized for this purp		<t>The EE <bcp14>MAY</bcp14> indicate the certificate profile to
	ose. A certificate received in caPubs MUST NOT be accepted as a trust anchor if		use in the certProfile extension of the generalInfo field in the PKIHeader of th
	it is the root CA certificate of the certificate used for protecting the messag		e certificate request message as described in <xref target="Header" format="defa
	e.</t>		ult"/>.</t>
			<t>In case the EE receives a CA certificate in the caPubs field f
			or installation as a new trust anchor, it <bcp14>MUST</bcp14> properly authentic
			ate the message and authorize the sender as a trusted source of the new trust an
			chor.
			This authorization is typically indicated using shared secret inf
			ormation for protecting an Initialization Response (ip) message. Authorization c
			an also be signature-based, using a certificate issued by another PKI that is ex
			plicitly authorized for this purpose. A certificate received in caPubs <bcp14>M
			UST NOT</bcp14> be accepted as a trust anchor if it is the root CA certificate o
			f the certificate used for protecting the message.</t>
	<section anchor="EE_newPKI" numbered="true" toc="default">		<section anchor="EE_newPKI" numbered="true" toc="default">
	<name>Enrolling an End Entity to a New PKI</name>		<name>Enrolling an End Entity to a New PKI</name>
	<t>This PKI management operation should be used by an EE to request a certificate from a new PKI using an existing certificate from an external PKI, e .g., a manufacturer-issued IDevID certificate <xref target="IEEE.802.1AR_2018" f ormat="default"/>, to authenticate itself to the new PKI.</t>		<t>This PKI management operation should be used by an EE to request a certificate from a new PKI using an existing certificate from an external PKI, e .g., a manufacturer-issued IDevID certificate <xref target="IEEE.802.1AR_2018" f ormat="default"/>, to authenticate itself to the new PKI.</t>
	<t>Note: In <xref target="RFC8995" format="default">Bootstrappi		<t>Note: In <xref target="RFC8995" format="default">Bootstrappi
	ng Remote Secure Key Infrastructure (BRSKI)</xref> environments, <xref target="I		ng Remote Secure Key Infrastructure (BRSKI)</xref> environments, <xref target="I
	-D.ietf-anima-brski-ae" format="default">BRSKI-AE: Alternative Enrollment Protoc		-D.ietf-anima-brski-ae" format="default">"BRSKI-AE: Alternative Enrollment Proto
	ols in BRSKI</xref> describes a generalization regarding enrollment protocols al		cols in BRSKI"</xref> describes a generalization regarding enrollment protocols
	ternative to <xref target="RFC7030" format="default">EST</xref>. As replacement		alternative to <xref target="RFC7030" format="default">EST</xref>. As replaceme
	of EST simpleenroll, BRSKI-AE uses this PKI management operation for bootstrapp		nt of EST simpleenroll, BRSKI-AE uses this PKI management operation for bootstra
	ing LDevID certificates.</t>		pping LDevID certificates.</t>
	<t keepWithNext="true">Specific prerequisites augmenting the prerequis		<t keepWithNext="true">Specific prerequisites augmenting the prerequis
	ites in <xref target="Prereq" format="default"/>:</t>		ites in <xref target="Prereq" format="default"/> are as follows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The certificate of the EE MUST have been enrolled by an e		<li>The certificate of the EE <bcp14>MUST</bcp14> have been e
	xternal PKI, e.g., a manufacturer-issued device certificate.</li>		nrolled by an external PKI, e.g., a manufacturer-issued device certificate.</li>
	<li>The PKI management entity MUST have the trust anchor of the exte		<li>The PKI management entity <bcp14>MUST</bcp14> have the trust anc
	rnal PKI.</li>		hor of the external PKI.</li>
	<li>When using the generalInfo field certProfile, the EE MUST know t		<li>When using the generalInfo field certProfile, the EE <bcp14>MUST
	he identifier needed to indicate the requested certificate profile.</li>		</bcp14> know the identifier needed to indicate the requested certificate profil
			e.</li>
	</ul>		</ul>
	<t keepWithNext="true">Message Flow:</t>		<t keepWithNext="true">Message Flow:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<artwork align="left" name="" type="" alt=""><![CDATA[
	Step# EE PKI management entity		Step# EE PKI management entity
	1 format ir		1 format ir
	2 -> ir ->		2 -> ir ->
	3 handle or		3 handle or
	forward ir		forward ir
	4 format or receive ip		4 format or receive ip
	5 possibly grant		5 possibly grant
	skipping to change at line 737 ¶		skipping to change at line 711 ¶
	----------------- if implicitConfirm not granted -----------------		----------------- if implicitConfirm not granted -----------------
	8 format certConf		8 format certConf
	9 -> certConf ->		9 -> certConf ->
	10 handle or		10 handle or
	forward certConf		forward certConf
	11 format or receive pkiConf		11 format or receive pkiConf
	12 <- pkiConf <-		12 <- pkiConf <-
	13 handle pkiConf		13 handle pkiConf
	]]></artwork>		]]></artwork>
	<t>For this PKI management operation, the EE MUST include a sequence o		<t>For this PKI management operation, the EE <bcp14>MUST</bcp14> inclu
	f one CertReqMsg in the ir. If more certificates are required, further requests		de a sequence of one CertReqMsg in the ir. If more certificates are required, f
	MUST be sent using separate PKI management operations.</t>		urther requests <bcp14>MUST</bcp14> be sent using separate PKI management operat
	<t>The EE MUST include the generalInfo field implicitConfirm in		ions.</t>
	the header of the ir message as described in <xref target="Header" format="defa		<t>The EE <bcp14>MUST</bcp14> include the generalInfo field implicitCon
	ult"/>, unless it requires certificate confirmation. This leaves the choice to		firm in the header of the ir message as described in <xref target="Header" forma
	the PKI management entities whether the EE must send a certConf message on recei		t="default"/>, unless it requires certificate confirmation.
	ving a new certificate. Depending on the PKI policy and requirements for managi		This leaves the PKI management entities the choice of whether or not th
	ng EE certificates, it can be important for PKI management entities to learn if		e EE must send a certConf message upon receiving a new certificate. Depending o
	the EE accepted the new certificate. In such cases, when responding with an ip		n the PKI policy and requirements for managing EE certificates, it can be import
	message, the PKI management entity MUST NOT include the implicitConfirm extensio		ant for PKI management entities to learn if the EE accepted the new certificate.
	n. In case the EE included the generalInfo field implicitConfirm in the request		In such cases, when responding with an ip message, the PKI management entity <
	message and the PKI management entity does not need any explicit confirmation f		bcp14>MUST NOT</bcp14> include the implicitConfirm extension. In case the EE in
	rom the EE, the PKI management entity MUST include the generalInfo field implici		cluded the generalInfo field implicitConfirm in the request message and the PKI
	tConfirm in the response message. This prevents explicit certificate confirmati		management entity does not need any explicit confirmation from the EE, the PKI m
	on and saves the overhead of a further message round-trip. Otherwise, the PKI m		anagement entity <bcp14>MUST</bcp14> include the generalInfo field implicitConfi
	anagement entity SHOULD include confirmWaitTime as described in <xref target="He		rm in the response message. This prevents explicit certificate confirmation and
	ader" format="default"/>.</t>		saves the overhead of a further message round trip. Otherwise, the PKI managem
	<t>If the EE did not request implicit confirmation or implicit confirm		ent entity <bcp14>SHOULD</bcp14> include confirmWaitTime as described in <xref t
	ation was not granted by the PKI management entity, certificate confirmation MUS		arget="Header" format="default"/>.</t>
	T be performed as follows. If the EE successfully received the certificate, it		<t>If the EE did not request implicit confirmation or implicit confirm
	MUST send a certConf message in due time. On receiving a valid certConf message,		ation was not granted by the PKI management entity, certificate confirmation <bc
	the PKI management entity MUST respond with a pkiConf message. If the PKI manag		p14>MUST</bcp14> be performed as follows. If the EE successfully received the c
	ement entity does not receive the expected certConf message in time it MUST hand		ertificate, it <bcp14>MUST</bcp14> send a certConf message in due time. On recei
	le this like a rejection by the EE. In case of rejection, depending on its poli		ving a valid certConf message, the PKI management entity <bcp14>MUST</bcp14> res
	cy the PKI management entity MAY revoke the newly issued certificate, notify a m		pond with a pkiConf message. If the PKI management entity does not receive the e
	onitoring system, or log the event internally.</t>		xpected certConf message in time, it <bcp14>MUST</bcp14> handle this like a reje
	<t>Note: Depending on PKI policy, a new certificate may be publ		ction by the EE. In case of rejection, depending on its policy, the PKI managem
	ished by a PKI management entity, and explicit confirmation may be required. In		ent entity <bcp14>MAY</bcp14> revoke the newly issued certificate, notify a moni
	this case it is advisable not to do the publication until a positive certificate		toring system, or log the event internally.</t>
	confirmation has been received. This way the need to revoke the certificate on		<t>Note: Depending on PKI policy, a new certificate may be publ
	negative confirmation can be avoided.</t>		ished by a PKI management entity, and explicit confirmation may be required. In
	<t>If the certificate request was rejected by the CA, the PKI manageme		this case, it is advisable not to do the publication until a positive certificat
	nt entity MUST return an ip message containing the status code "rejection" as de		e confirmation has been received. This way, the need to revoke the certificate
	scribed in <xref target="Error" format="default"/> and the certifiedKeyPair fiel		on negative confirmation can be avoided.</t>
	d SHALL be omitted. The EE MUST NOT react to such an ip message with a certConf		<t>If the certificate request was rejected by the CA, the PKI manageme
	message and the PKI management operation MUST be terminated.</t>		nt entity <bcp14>MUST</bcp14> return an ip message containing the status code "r
			ejection" as described in <xref target="Error" format="default"/>, and the certi
			fiedKeyPair field <bcp14>SHALL</bcp14> be omitted. The EE <bcp14>MUST NOT</bcp1
			4> react to such an ip message with a certConf message, and the PKI management o
			peration <bcp14>MUST</bcp14> be terminated.</t>
	<t keepWithNext="true">Detailed Message Description:</t>		<t keepWithNext="true">Detailed Message Description:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	Initialization Request -- ir		Initialization Request -- ir
	Field Value		Field Value
	header		header
	-- As described in Section 3.1		-- As described in Section 3.1
	body		body
	-- The request of the EE for a new certificate		-- The request of the EE for a new certificate
	ir REQUIRED		ir REQUIRED
	-- MUST contain a sequence of one CertReqMsg		-- MUST contain a sequence of one CertReqMsg
	-- If more certificates are required, further PKI management		-- If more certificates are required, further PKI management
	-- operations needs to be initiated		-- operations needs to be initiated
	certReq REQUIRED		certReq REQUIRED
	certReqId REQUIRED		certReqId REQUIRED
	-- MUST be 0		-- MUST be 0
	certTemplate REQUIRED		certTemplate REQUIRED
	version OPTIONAL		version OPTIONAL
	-- MUST be 2 if supplied		-- MUST be 2 if supplied
	subject REQUIRED		subject REQUIRED
	-- The EE subject name MUST be carried in the subject field		-- The EE's identity MUST be carried in the subject field
	-- and/or the subjectAltName extension.		-- and/or the subjectAltName extension.
	-- If subject name is present only in the subjectAltName		-- If subject name is present only in the subjectAltName
	-- extension, then the subject field MUST be a NULL-DN		-- extension, then the subject field MUST be NULL-DN
	publicKey OPTIONAL		publicKey OPTIONAL
	-- MUST be present if local key generation is used		-- MUST be present if local key generation is used
	-- MAY be absent if central key generation is requested		-- MAY be absent if central key generation is requested
	algorithm OPTIONAL		algorithm OPTIONAL
	-- MUST be present if local key generation is used and MUST		-- MUST be present if local key generation is used and MUST
	-- include the subject public key algorithm identifier		-- include the subject public key algorithm identifier
	-- MAY be present if central key generation is requested and		-- MAY be present if central key generation is requested and,
	-- if present, informs the KGA of algorithm and parameter		-- if present, informs the KGA of algorithm and parameter
	-- preferences regarding the to-be-generated key pair		-- preferences regarding the to-be-generated key pair
	subjectPublicKey REQUIRED		subjectPublicKey REQUIRED
	-- MUST contain the public key to be certified in case of local		-- MUST contain the public key to be certified in case of local
	-- key generation		-- key generation
	-- MUST be a zero-length BIT STRING if central key generation		-- MUST be a zero-length BIT STRING if central key generation
	-- is requested		-- is requested
	extensions OPTIONAL		extensions OPTIONAL
	-- MAY include end-entity-specific X.509 extensions of the		-- MAY include end-entity-specific X.509 extensions of the
	-- requested certificate like subject alternative name, key		-- requested certificate, like subject alternative name, key
	-- usage, and extended key usage		-- usage, and extended key usage
	-- The subjectAltName extension MUST be present if the EE subject		-- The subjectAltName extension MUST be present if the EE subject
	-- name includes a subject alternative name.		-- name includes a subject alternative name.
	popo OPTIONAL		popo OPTIONAL
	-- MUST be present if local key generation is used		-- MUST be present if local key generation is used
	-- MUST be absent if central key generation is requested		-- MUST be absent if central key generation is requested
	signature OPTIONAL		signature OPTIONAL
	-- MUST be used by an EE if the key can be used for signing and		-- MUST be used by an EE if the key can be used for signing, and
	-- if used it MUST have the type POPOSigningKey		-- if used, it MUST have the type POPOSigningKey
	poposkInput PROHIBITED		poposkInput PROHIBITED
	-- MUST NOT be used; it is not needed because subject and		-- MUST NOT be used; it is not needed because subject and
	-- publicKey are both present in the certTemplate		-- publicKey are both present in the certTemplate
	algorithmIdentifier REQUIRED		algorithmIdentifier REQUIRED
	-- The signature algorithm MUST be consistent with the publicKey		-- The signature algorithm MUST be consistent with the publicKey
	-- algorithm field of the certTemplate		-- algorithm field of the certTemplate
	signature REQUIRED		signature REQUIRED
	-- MUST contain the signature value computed over the DER-encoded		-- MUST contain the signature value computed over the DER-encoded
	-- certTemplate		-- certReq
	raVerified OPTIONAL		raVerified OPTIONAL
	-- MAY be used by an RA after verifying the proof-of-possession		-- MAY be used by an RA after verifying the proof-of-possession
	-- provided by the EE		-- provided by the EE
	protection REQUIRED		protection REQUIRED
	-- As described in Section 3.2		-- As described in Section 3.2
	extraCerts REQUIRED		extraCerts REQUIRED
	-- As described in Section 3.3		-- As described in Section 3.3
	skipping to change at line 825 ¶		skipping to change at line 800 ¶
	Field Value		Field Value
	header		header
	-- As described in Section 3.1		-- As described in Section 3.1
	body		body
	-- The response of the CA to the request as appropriate		-- The response of the CA to the request as appropriate
	ip REQUIRED		ip REQUIRED
	caPubs OPTIONAL		caPubs OPTIONAL
	-- MAY be used if the certifiedKeyPair field is present		-- MAY be used if the certifiedKeyPair field is present
	-- If used it MUST contain only a trust anchor, e.g., root		-- If used, it MUST contain only a trust anchor, e.g., root
	-- certificate, of the certificate contained in certOrEncCert		-- certificate, of the certificate contained in certOrEncCert
	response REQUIRED		response REQUIRED
	-- MUST contain a sequence of one CertResponse		-- MUST contain a sequence of one CertResponse
	certReqId REQUIRED		certReqId REQUIRED
	-- MUST be 0		-- MUST be 0
	status REQUIRED		status REQUIRED
	-- PKIStatusInfo structure MUST be present		-- PKIStatusInfo structure MUST be present
	status REQUIRED		status REQUIRED
	-- positive values allowed: "accepted", "grantedWithMods"		-- positive values allowed: "accepted", "grantedWithMods"
	-- negative values allowed: "rejection"		-- negative values allowed: "rejection"
	-- "waiting" only allowed with polling use case as described in		-- "waiting" only allowed with a polling use case as described
	-- Section 4.4		-- in Section 4.4
	statusString OPTIONAL		statusString OPTIONAL
	-- MAY be any human-readable text for debugging, logging or to		-- MAY be any human-readable text for debugging, for logging, or
	-- display in a GUI		-- to display in a GUI
	failInfo OPTIONAL		failInfo OPTIONAL
	-- MAY be present if status is "rejection"		-- MAY be present if status is "rejection"
	-- MUST be absent if status is "accepted" or "grantedWithMods"		-- MUST be absent if status is "accepted" or "grantedWithMods"
	certifiedKeyPair OPTIONAL		certifiedKeyPair OPTIONAL
	-- MUST be present if status is "accepted" or "grantedWithMods"		-- MUST be present if status is "accepted" or "grantedWithMods"
	-- MUST be absent if status is "rejection"		-- MUST be absent if status is "rejection"
	certOrEncCert REQUIRED		certOrEncCert REQUIRED
	-- MUST be present if status is "accepted" or "grantedWithMods"		-- MUST be present if status is "accepted" or "grantedWithMods"
	certificate REQUIRED		certificate REQUIRED
	-- MUST be present when certifiedKeyPair is present		-- MUST be present when certifiedKeyPair is present
	-- MUST contain the newly enrolled X.509 certificate		-- MUST contain the newly enrolled X.509 certificate
	privateKey OPTIONAL		privateKey OPTIONAL
	-- MUST be absent in case of local key generation or "rejection"		-- MUST be absent in case of local key generation or "rejection"
	-- MUST contain the encrypted private key in an EnvelopedData		-- MUST contain the encrypted private key in an EnvelopedData
	-- structure as specified in Section 4.1.6 in case the private		-- structure as specified in Section 4.1.6 in case the
	-- key was generated centrally		-- private key was generated centrally
	protection REQUIRED		protection REQUIRED
	-- As described in Section 3.2		-- As described in Section 3.2
	extraCerts REQUIRED		extraCerts REQUIRED
	-- As described in Section 3.3		-- As described in Section 3.3
	-- MUST contain the chain of the certificate present in		-- MUST contain the chain of the certificate present in
	-- certOrEncCert		-- certOrEncCert
	-- Duplicate certificates MAY be omitted		-- Duplicate certificates MAY be omitted
	Certificate Confirmation -- certConf		Certificate Confirmation -- certConf
	Field Value		Field Value
	header		header
	-- As described in Section 3.1		-- As described in Section 3.1
	body		body
	-- The message of the EE sends as confirmation to the PKI		-- The message of the EE sends a confirmation to the PKI
	-- management entity to accept or reject the issued		-- management entity to accept or reject the issued
	-- certificates		-- certificates
	certConf REQUIRED		certConf REQUIRED
	-- MUST contain a sequence of one CertStatus		-- MUST contain a sequence of one CertStatus
	CertStatus REQUIRED		CertStatus REQUIRED
	certHash REQUIRED		certHash REQUIRED
	-- MUST be the hash value of the certificate.
	-- The hash algorithm to use MUST be the hash algorithm indicated		-- The hash algorithm to use MUST be the hash algorithm indicated
	-- in the below hashAlg field. If the hashAlg field is not		-- in the below hashAlg field. If the hashAlg field is not
	-- set, it MUST be the hash algorithm defined by the algorithm		-- set, it MUST be the hash algorithm defined by the algorithm
	-- identifier of the certificate signature or the dedicated		-- identifier of the certificate signature or the dedicated
	-- hash algorithm defined in RFCBBBB for the used certificate		-- hash algorithm defined in [RFC9481] for the used certificate
	-- signature algorithm.		-- signature algorithm.
	certReqId REQUIRED		certReqId REQUIRED
	-- MUST be 0		-- MUST be 0
	statusInfo OPTIONAL		statusInfo OPTIONAL
	-- PKIStatusInfo structure should be present		-- PKIStatusInfo structure should be present
	-- Omission indicates acceptance of the indicated certificate		-- Omission indicates acceptance of the indicated certificate
	status REQUIRED		status REQUIRED
	-- positive values allowed: "accepted"		-- positive values allowed: "accepted"
	-- negative values allowed: "rejection"		-- negative values allowed: "rejection"
	statusString OPTIONAL		statusString OPTIONAL
	-- MAY be any human-readable text for debugging, logging, or to		-- MAY be any human-readable text for debugging, for logging, or
	-- display in a GUI		-- to display in a GUI
	failInfo OPTIONAL		failInfo OPTIONAL
	-- MAY be present if status is "rejection"		-- MAY be present if status is "rejection"
	-- MUST be absent if status is "accepted"		-- MUST be absent if status is "accepted"
	hashAlg OPTIONAL		hashAlg OPTIONAL
	-- The hash algorithm to use for calculating the above certHash		-- The hash algorithm to use for calculating the above certHash
	-- If used, the pvno field in the header MUST be cmp2021 (3). For		-- If used, the pvno field in the header MUST be cmp2021 (3).
	-- backward compatibility it is NOT RECOMMENDED to use this		-- For backward compatibility, use of this field is
	-- field, if the hash algorithm to use can be identified by		-- NOT RECOMMENDED if the hash algorithm to use can be
	-- other means, see above.		-- identified by other means; see above.
	protection REQUIRED		protection REQUIRED
	-- As described in Section 3.2		-- As described in Section 3.2
	-- MUST use the same credentials as in the first request message		-- MUST use the same credentials as in the first request message
	-- of this PKI management operation		-- of this 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 PKI		-- MAY be omitted if the message size is critical and the PKI
	-- management entity caches the CMP protection certificate from		-- management entity caches the CMP protection certificate from
	skipping to change at line 942 ¶		skipping to change at line 916 ¶
	protection REQUIRED		protection REQUIRED
	-- 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 this PKI management operation		-- message of this 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 CMP protection certificate from the first		-- cached the CMP protection certificate from the first
	-- response message of this PKI management operation		-- response message of this PKI management operation
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="EE_trustedPKI" numbered="true" toc="default">		<section anchor="EE_trustedPKI" numbered="true" toc="default">
	<name>Enrolling an End Entity to a Known PKI</name>		<name>Enrolling an End Entity to a Known PKI</name>
	<t>This PKI management operation should be used by an EE to request an additional certificate of the same PKI it already has certificates from. The E E uses one of these existing certificates to authenticate itself by signing its request messages using the respective private key.</t>		<t>This PKI management operation should be used by an EE to request an additional certificate of the same PKI it already has certificates from. The E E uses one of these existing certificates to authenticate itself by signing its request messages using the respective private key.</t>
	<t keepWithNext="true">Specific prerequisites augmenting the prerequis		<t keepWithNext="true">Specific prerequisites augmenting the prerequis
	ites in <xref target="Prereq" format="default"/>:</t>		ites in <xref target="Prereq" format="default"/> are as follows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The certificate used by the EE MUST have been enrolled by		<li>The certificate used by the EE <bcp14>MUST</bcp14> have been enro
	the PKI it requests another certificate from.</li>		lled by the PKI it requests another certificate from.</li>
	<li>When using the generalInfo field certProfile, the EE MUST know t		<li>When using the generalInfo field certProfile, the EE <bcp14>MUST
	he identifier needed to indicate the requested certificate profile.</li>		</bcp14> know the identifier needed to indicate the requested certificate profil
			e.</li>
	</ul>		</ul>
	<t keepWithNext="true">The message sequence for this PKI management op eration is identical to that given in <xref target="EE_newPKI" format="default"/ >, with the following changes:</t>		<t keepWithNext="true">The message sequence for this PKI management op eration is identical to that given in <xref target="EE_newPKI" format="default"/ >, with the following changes:</t>
	<ol spacing="normal" type="%d">		<ol spacing="normal" type="1">
	<li>		<li>
	<t>The body of the first request and response SHOULD be		<t>The body of the first request and response <bcp14>SHOULD</bcp14>
	cr and cp. Otherwise ir and ip MUST be used.</t>		be cr and cp. Otherwise, ir and ip <bcp14>MUST</bcp14> be used.</t>
	<t>Note: Since the difference between ir/ip and cr/cp i		<t>Note: Since the difference between ir/ip and cr/cp is syntactica
	s syntactically not essential, an ir/ip may be used in this PKI management opera		lly not essential, an ir/ip may be used in this PKI management operation.</t>
	tion.</t>		</li>
	</li>		<li>The caPubs field in the certificate response message <bcp14>MUST
	<li>The caPubs field in the certificate response message MUST be abs		</bcp14> be absent.</li>
	ent.</li>
	</ol>		</ol>
	</section>		</section>
	<section anchor="EE_Update" numbered="true" toc="default">		<section anchor="EE_Update" numbered="true" toc="default">
	<name>Updating a Valid Certificate</name>		<name>Updating a Valid Certificate</name>
	<t>This PKI management operation should be used by an EE to request an update for one of its certificates that is still valid. The EE uses the certif icate it wishes to update as the CMP protection certificate. Both for authentica ting itself and for proving ownership of the certificate to be updated, it signs the request messages with the corresponding private key.</t>		<t>This PKI management operation should be used by an EE to request an update for one of its certificates that is still valid. The EE uses the certif icate it wishes to update as the CMP protection certificate. Both for authentica ting itself and for proving ownership of the certificate to be updated, it signs the request messages with the corresponding private key.</t>
	<t keepWithNext="true">Specific prerequisites augmenting the prerequis ites in <xref target="Prereq" format="default"/>:</t>		<t keepWithNext="true">Specific prerequisites augmenting the prerequis ites in <xref target="Prereq" format="default"/> are as follows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The certificate the EE wishes to update MUST NOT be expir ed or revoked and MUST have been issued by the addressed CA.</li>		<li>The certificate the EE wishes to update <bcp14>MUST NOT</ bcp14> be expired or revoked and <bcp14>MUST</bcp14> have been issued by the add ressed CA.</li>
	<li>A new public-private key pair should be used.</li>		<li>A new public-private key pair should be used.</li>
	<li>When using the generalInfo field certProfile, the EE MUST know t he identifier needed to indicate the requested certificate profile.</li>		<li>When using the generalInfo field certProfile, the EE <bcp14>MUST </bcp14> know the identifier needed to indicate the requested certificate profil e.</li>
	</ul>		</ul>
	<t keepWithNext="true">The message sequence for this PKI management op eration is identical to that given in <xref target="EE_newPKI" format="default"/ >, with the following changes:</t>		<t keepWithNext="true">The message sequence for this PKI management op eration is identical to that given in <xref target="EE_newPKI" format="default"/ >, with the following changes:</t>
	<ol spacing="normal" type="%d">		<ol spacing="normal" type="1">
	<li>The body of the first request and response MUST be kur an		<li>The body of the first request and response <bcp14>MUST</b
	d kup, respectively.</li>		cp14> be kur and kup, respectively.</li>
	<li>Protection of the kur MUST be performed using the certificate to		<li>Protection of the kur <bcp14>MUST</bcp14> be performed using the
	be updated.</li>		certificate to be updated.</li>
	<li>The subject field and/or the subjectAltName extension of the cer		<li>The subject field and/or the subjectAltName extension of the cer
	tTemplate MUST contain the EE subject name of the existing certificate to be upd		tTemplate <bcp14>MUST</bcp14> contain the EE subject name of the existing certif
	ated, without modifications.</li>		icate to be updated, without modifications.</li>
	<li>The certTemplate SHOULD contain the subject and/or subjectAltNam		<li>The certTemplate <bcp14>SHOULD</bcp14> contain the subject and/o
	e extension and publicKey of the EE only.</li>		r subjectAltName extension and publicKey of the EE only.</li>
	<li>The oldCertId control MAY be used to make clear which certificat		<li>The oldCertId control <bcp14>MAY</bcp14> be used to make clear w
	e is to be updated.</li>		hich certificate is to be updated.</li>
	<li>The caPubs field in the kup message MUST be absent.</li>		<li>The caPubs field in the kup message <bcp14>MUST</bcp14> be absen
			t.</li>
	</ol>		</ol>
	<t keepWithNext="true">As part of the certReq structure of the kur the		<t keepWithNext="true">As part of the certReq structure of the kur, th
	oldCertId control is added after the certTemplate field.</t>		e oldCertId control is added after the certTemplate field.</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	controls		controls
	type RECOMMENDED		type RECOMMENDED
	-- MUST be the value id-regCtrl-oldCertID, if present		-- MUST be the value id-regCtrl-oldCertID, if present
	value		value
	issuer REQUIRED		issuer REQUIRED
	serialNumber REQUIRED		serialNumber REQUIRED
	-- MUST contain the issuer and serialNumber of the certificate		-- MUST contain the issuer and serialNumber of the certificate
	-- to be updated		-- to be updated
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="EE_P10" numbered="true" toc="default">		<section anchor="EE_P10" numbered="true" toc="default">
	<name>Enrolling an End Entity Using a PKCS#10 Request</name>		<name>Enrolling an End Entity Using a PKCS #10 Request</name>
	<t>This PKI management operation can be used by an EE to reques		<t>This PKI management operation can be used by an EE to reques
	t a certificate using <xref target="RFC2986" format="default">PKCS#10</xref> for		t a certificate using the <xref target="RFC2986" format="default">PKCS #10</xref
	mat to interoperate with CAs not supporting <xref target="RFC4211" format="defau		> format to interoperate with CAs not supporting <xref target="RFC4211" format="
	lt">CRMF</xref>. This offers a variation of the PKI management operations specif		default">CRMF</xref>. This offers a variation of the PKI management operations s
	ied in Sections <xref target="EE_newPKI" format="counter"/> to <xref target="EE_		pecified in Sections <xref target="EE_newPKI" format="counter"/> to <xref target
	Update" format="counter"/>.</t>		="EE_Update" format="counter"/>.</t>
	<t>In this PKI management operation, the public key and all further ce		<t>In this PKI management operation, the public key and all further ce
	rtificate template data MUST be contained in the subjectPKInfo and other certifi		rtificate template data <bcp14>MUST</bcp14> be contained in the subjectPKInfo an
	cationRequestInfo fields of the PKCS#10 structure.</t>		d other certificationRequestInfo fields of the PKCS #10 structure.</t>
	<t>The prerequisites are the same as given in <xref target="EE_trusted PKI" format="default"/>.</t>		<t>The prerequisites are the same as given in <xref target="EE_trusted PKI" format="default"/>.</t>
	<t keepWithNext="true">The message sequence for this PKI management op eration is identical to that given in Sections <xref target="EE_newPKI" format=" counter"/> to <xref target="EE_Update" format="counter"/>, with the following ch anges:</t>		<t keepWithNext="true">The message sequence for this PKI management op eration is identical to that given in Sections <xref target="EE_newPKI" format=" counter"/> to <xref target="EE_Update" format="counter"/>, with the following ch anges:</t>
	<ol spacing="normal" type="%d">		<ol spacing="normal" type="1">
	<li>The body of the first request and response MUST be p1		<li>The body of the first request and response <bcp14>MUS
	0cr and cp, respectively.</li>		T</bcp14> be p10cr and cp, respectively.</li>
	<li>The certReqId in the cp message MUST be -1.</li>		<li>The certReqId in the cp message <bcp14>MUST</bcp14> be -1.</li>
	</ol>		</ol>
	<t keepWithNext="true">Detailed Message Description:</t>		<t keepWithNext="true">Detailed Message Description:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	Certification Request -- p10cr		Certification Request -- p10cr
	Field Value		Field Value
	header		header
	-- As described in Section 3.1		-- As described in Section 3.1
	body		body
	-- The request of the EE for a new certificate using a PKCS#10		-- The request of the EE for a new certificate using a PKCS #10
	-- certificate request		-- certificate request
	p10cr REQUIRED		p10cr REQUIRED
	certificationRequestInfo REQUIRED		certificationRequestInfo REQUIRED
	version REQUIRED		version REQUIRED
	-- MUST be 0 to indicate PKCS#10 V1.7		-- MUST be 0 to indicate PKCS #10 v1.7
	subject REQUIRED		subject REQUIRED
	-- The EE subject name MUST be carried in the subject field		-- The EE subject name MUST be carried in the subject field
	-- and/or the subjectAltName extension.		-- and/or the subjectAltName extension.
	-- If subject name is present only in the subjectAltName		-- If subject name is present only in the subjectAltName
	-- extension, then the subject field MUST be a NULL-DN		-- extension, then the subject field MUST be NULL-DN
	subjectPKInfo REQUIRED		subjectPKInfo REQUIRED
	algorithm REQUIRED		algorithm REQUIRED
	-- MUST include the subject public key algorithm identifier		-- MUST include the subject public key algorithm identifier
	subjectPublicKey REQUIRED		subjectPublicKey REQUIRED
	-- MUST include the public key to be certified		-- MUST include the public key to be certified
	attributes OPTIONAL		attributes OPTIONAL
	-- MAY include end-entity-specific X.509 extensions of the		-- MAY include end-entity-specific X.509 extensions of the
	-- requested certificate like subject alternative name,		-- requested certificate like subject alternative name,
	-- key usage, and extended key usage		-- key usage, and extended key usage
	-- The subjectAltName extension MUST be present if the EE		-- The subjectAltName extension MUST be present if the EE
	skipping to change at line 1044 ¶		skipping to change at line 1019 ¶
	-- The signature algorithm MUST be consistent with the		-- The signature algorithm MUST be consistent with the
	-- subjectPKInfo field.		-- subjectPKInfo field.
	signature REQUIRED		signature REQUIRED
	-- MUST contain the self-signature for proof-of-possession		-- MUST contain the self-signature for proof-of-possession
	protection REQUIRED		protection REQUIRED
	-- As described in Section 3.2		-- As described in Section 3.2
	extraCerts REQUIRED		extraCerts REQUIRED
	-- As described for the underlying PKI management operation		-- As described for the underlying PKI management operation
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="EE_MAC" numbered="true" toc="default">		<section anchor="EE_MAC" numbered="true" toc="default">
	<name>Using MAC-Based Protection for Enrollment</name>		<name>Using MAC-Based Protection for Enrollment</name>
	<t>This is a variant of the PKI management operations described		<t>This is a variant of the PKI management operations described
	in Sections <xref target="EE_newPKI" format="counter"/>, <xref target="EE_trust		in Sections <xref target="EE_newPKI" format="counter"/>, <xref target="EE_trust
	edPKI" format="counter"/> and <xref target="EE_P10" format="counter"/>. It shou		edPKI" format="counter"/>, and <xref target="EE_P10" format="counter"/>. It sho
	ld be used by an EE to request a certificate of a new PKI in case it does not ha		uld be used by an EE to request a certificate of a new PKI in case it does not h
	ve a certificate to prove its identity to the target PKI, but has some secret in		ave a certificate to prove its identity to the target PKI but has some secret in
	formation shared with the PKI management entity. Therefore, the request and res		formation shared with the PKI management entity. Therefore, the request and res
	ponse messages are MAC-protected using this shared secret information. The dist		ponse messages are MAC-protected using this shared secret information. The dist
	ribution of this shared secret is out of scope for this document. The PKI manage		ribution of this shared secret is out of scope for this document. The PKI manage
	ment entity checking the MAC-based protection MUST replace this protection accor		ment entity checking the MAC-based protection <bcp14>MUST</bcp14> replace this p
	ding to <xref target="RA_Replace" format="default"/> as the next hop may not kno		rotection according to <xref target="RA_Replace" format="default"/>, as the next
	w the shared secret information.</t>		hop may not know the shared secret information.</t>
	<t>Note: The entropy of the shared secret information is crucia		<t>Note: The entropy of the shared secret information is crucia
	l for the level of protection when using MAC-based protection. Further guidance		l for the level of protection when using MAC-based protection. Further guidance
	is available in the security considerations of CMP updated by <xref target="I-D		is available in the security considerations updated by <xref target="RFC9480" f
	.ietf-lamps-cmp-updates" format="default"/>.</t>		ormat="default">CMP Updates</xref>.</t>
	<t keepWithNext="true">Specific prerequisites augmenting the prerequis		<t keepWithNext="true">Specific prerequisites augmenting the prerequis
	ites in <xref target="Prereq" format="default"/>:</t>		ites in <xref target="Prereq" format="default"/> are as follows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>Rather than using private keys, certificates, and tr		<t>Rather than using private keys, certificates, and tr
	ust anchors, the EE and the PKI management entity MUST share secret information.		ust anchors, the EE and the PKI management entity <bcp14>MUST</bcp14> share secr
	</t>		et information.</t>
	<t>Note: The shared secret information MUST be establis		<t>Note: The shared secret information <bcp14>MUST</bcp
	hed out-of-band, e.g., by a service technician during initial local configuratio		14> be established out of band, e.g., by a service technician during initial loc
	n.</t>		al configuration.</t>
	</li>		</li>
	<li>When using the generalInfo field certProfile, the EE MUST know t he identifier needed to indicate the requested certificate profile.</li>		<li>When using the generalInfo field certProfile, the EE <bcp14>MUST </bcp14> know the identifier needed to indicate the requested certificate profil e.</li>
	</ul>		</ul>
	<t keepWithNext="true">The message sequence for this PKI management op		<t keepWithNext="true">The message sequence for this PKI management op
	eration is identical to that given in Sections <xref target="EE_newPKI" format="		eration is identical to that given in Sections <xref target="EE_newPKI" format="
	counter"/>, <xref target="EE_trustedPKI" format="counter"/> and <xref target="EE		counter"/>, <xref target="EE_trustedPKI" format="counter"/>, and <xref target="E
	_P10" format="counter"/>, with the following changes:</t>		E_P10" format="counter"/>, with the following changes:</t>
	<ol spacing="normal" type="%d">		<ol spacing="normal" type="1">
	<li>The protection of all messages MUST be MAC-based. Therefo		<li>The protection of all messages <bcp14>MUST</bcp14> be MAC
	re, extraCerts fields of all messages do not contain CMP protection certificates		-based. Therefore, extraCerts fields of all messages do not contain CMP protecti
	and associated chains.</li>		on certificates and associated chains.</li>
	<li>In case the sending entity does not know its own name by now, it		<li>The sender field <bcp14>MUST</bcp14> contain a name the PKI mana
	MUST put the NULL-DN into the sender field. The senderKID MUST contain a refere		gement entity can use to identify the shared secret information used for message
	nce the recipient can use to identify the shared secret information used for the		protection. This name <bcp14>MUST</bcp14> be placed in the commonName field of
	protection, e.g., the username of the EE.</li>		the directoryName choice. The senderKID <bcp14>MUST</bcp14> contain the same nam
			e as in the commonName field of the sender field. In case the sending entity doe
			s not yet know for which name to request the certificate, it can use this common
			Name in the subject field of the certTemplate.</li>
	</ol>		</ol>
	<t>See <xref target="Transfer_types" format="default"/> of <xref targe t="I-D.ietf-lamps-cmp-algorithms" format="default"> CMP Algorithms</xref> for de tails on message authentication code algorithms (MSG_MAC_ALG) to use. Typically, parameters are part of the protectionAlg field, e.g., used for key derivation, like a salt and an iteration count. Such parameters should remain constant for message protection throughout this PKI management operation to reduce the comput ational overhead.</t>		<t>See <xref target="RFC9481" format="default" sectionFormat="of" sect ion="6">CMP Algorithms</xref> for details on message authentication code algorit hms (MSG_MAC_ALG) to use. Typically, parameters are part of the protectionAlg fi eld, e.g., used for key derivation, like a salt and an iteration count. Such pa rameters should remain constant for message protection throughout this PKI manag ement operation to reduce the computational overhead.</t>
	</section>		</section>
	<section anchor="EE_centralKeyGeneration" numbered="true" toc="default">		<section anchor="EE_centralKeyGeneration" numbered="true" toc="default">
	<name>Adding Central Key Pair Generation to Enrollment</name>		<name>Adding Central Key Pair Generation to Enrollment</name>
	<t>This is a variant of the PKI management operations described in <xr ef target="EE_newPKI" format="default"/> to <xref target="EE_P10" format="defaul t"/> and the variant described in <xref target="EE_MAC" format="default"/>. It n eeds to be used in case an EE is not able to generate its new public-private key pair itself or central generation of the EE key material is preferred. It is a matter of the local implementation which PKI management entity will act as Key Generation Authority (KGA) and performs the key generation. This PKI management entity MUST use a certificate containing the additional extended key usage exte nsion id-kp-cmKGA in order to be accepted by the EE as a legitimate key generati on authority.</t>		<t>This is a variant of the PKI management operations described in Sec tions <xref target="EE_newPKI" format="counter"/> to <xref target="EE_P10" forma t="counter"/> and the variant described in <xref target="EE_MAC" format="default "/>. It needs to be used in case an EE is not able to generate its new public-pr ivate key pair itself or central generation of the EE key material is preferred. Which PKI management entity will act as Key Generation Authority (KGA) and perf orm the key generation is a matter of the local implementation. This PKI manage ment entity <bcp14>MUST</bcp14> use a certificate containing the additional exte nded key usage extension id-kp-cmKGA in order to be accepted by the EE as a legi timate key generation authority.</t>
	<t>Note: As described in <xref target="RA_on-behalf_request" fo rmat="default"/>, the KGA can use the PKI management operation described in <xre f target="EE_trustedPKI" format="default"/> to request the certificate for this key pair on behalf of the EE.</t>		<t>Note: As described in <xref target="RA_on-behalf_request" fo rmat="default"/>, the KGA can use the PKI management operation described in <xre f target="EE_trustedPKI" format="default"/> to request the certificate for this key pair on behalf of the EE.</t>
	<t>When an EE requests central key generation for a certificate update using a kur message, the KGA cannot use a kur message to request the cer tificate on behalf of the EE as the old EE credential is not available to the KG A for protecting this message. Therefore, if the EE uses the PKI management ope ration described in <xref target="EE_Update" format="default"/>, the KGA MUST ac t as described in <xref target="EE_trustedPKI" format="default"/> to request the certificate for the newly generated key pair on behalf of the EE from the CA.</ t>		<t>When an EE requests central key generation for a certificate update using a kur message, the KGA cannot use a kur message to request the cer tificate on behalf of the EE, as the old EE credential is not available to the K GA for protecting this message. Therefore, if the EE uses the PKI management op eration described in <xref target="EE_Update" format="default"/>, the KGA <bcp14 >MUST</bcp14> act as described in <xref target="EE_trustedPKI" format="default"/ > to request the certificate for the newly generated key pair on behalf of the E E from the CA.</t>
	<t>Generally speaking, it is strongly preferable to generate public-pr ivate key pairs locally at the EE. This is advisable to make sure that the enti ty identified in the newly issued certificate is the only entity that knows the private key.</t>		<t>Generally speaking, it is strongly preferable to generate public-pr ivate key pairs locally at the EE. This is advisable to make sure that the enti ty identified in the newly issued certificate is the only entity that knows the private key.</t>
	<t keepWithNext="true">Reasons for central key generation may include the following:</t>		<t keepWithNext="true">Reasons for central key generation may include the following:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>Lack of sufficient initial entropy.</t>		<t>lack of sufficient initial entropy</t>
	<t>Note: Good random numbers are needed not only for ke		<t>Note: Good random numbers are not only needed for ke
	y generation but also for session keys and nonces in any security protocol. Ther		y generation but also for session keys and nonces in any security protocol. Ther
	efore, a decent security architecture should anyways support good random number		efore, a decent security architecture should anyways support good random number
	generation on the EE side or provide enough initial entropy for the RNG seed to		generation on the EE side or provide enough initial entropy for the random numbe
	guarantee good pseudo-random number generation. Yet maybe this is not the case		r generator seed to guarantee good pseudorandom number generation. Yet maybe th
	at the time of requesting an initial certificate during manufacturing.</t>		is is not the case at the time of requesting an initial certificate during manuf
			acturing.</t>
	</li>		</li>
	<li>		<li>
	<t>Lack of computational resources, in particular for R SA key generation.</t>		<t>lack of computational resources, in particular, for RSA key generation</t>
	<t>Note: Since key generation could be performed in adv ance to the certificate enrollment communication, it is often not time critical. </t>		<t>Note: Since key generation could be performed in adv ance to the certificate enrollment communication, it is often not time critical. </t>
	</li>		</li>
	</ul>		</ul>
	<t>Note: As mentioned in <xref target="Architecture" format="default"/ >, central key generation may be required in a push model, where the certificate response message is transferred by the PKI management entity to the EE without a previous request message.</t>		<t>Note: As mentioned in <xref target="Architecture" format="default"/ >, central key generation may be required in a push model, where the certificate response message is transferred by the PKI management entity to the EE without a previous request message.</t>
	<t>The EE requesting central key generation MUST omit the publicKey fi		<t>The EE requesting central key generation <bcp14>MUST</bcp14> omit t
	eld from the certTemplate or, in case it has a preference on the key type to be		he publicKey field from the certTemplate or, in case it has a preference on the
	generated, provide this preference in the algorithm sub-field and fill the subje		key type to be generated, provide this preference in the algorithm sub-field and
	ctPublicKey sub-field with a zero-length BIT STRING. Both variants indicate to		fill the subjectPublicKey sub-field with a zero-length BIT STRING. Both varian
	the PKI management entity that a new key pair shall be generated centrally on be		ts indicate to the PKI management entity that a new key pair shall be generated
	half of the EE.</t>		centrally on behalf of the EE.</t>
	<t>Note: As the protection of centrally generated keys in the r		<t>Note: As the protection of centrally generated keys in the response
	esponse message has been extended to EncryptedKey by <xref target="I-D.ietf-lamp		message has been extended to EncryptedKey by <xref target="RFC9480" format="defa
	s-cmp-updates" format="default">CMP Updates Section 2.7</xref>, EnvelopedData is		ult" sectionFormat="of" section="2.7">CMP Updates</xref>, EnvelopedData is the p
	the preferred alternative to EncryptedValue. In <xref target="RFC4211" format=		referred alternative to EncryptedValue.
	"default">CRMF Section 2.1.9</xref> the use of EncryptedValue has been deprecate		In <xref target="RFC4211" format="default" sectionFormat="comma" sectio
	d in favor of the EnvelopedData structure. Therefore, this profile requires usi		n="2.1">CRMF</xref>, point 9, the use of EncryptedValue has been deprecated in f
	ng EnvelopedData as specified in <xref target="RFC5652" format="default">CMS Sec		avor of the EnvelopedData structure. Therefore, this profile requires using Env
	tion 6</xref>. When EnvelopedData is to be used in a PKI management operation,		elopedData, as specified in <xref target="RFC5652" format="default" sectionForma
	CMP v3 MUST be indicated in the message header already for the initial request m		t="of" section="6">CMS</xref>. When EnvelopedData is to be used in a PKI manage
	essage, see <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updat		ment operation, CMP v3 <bcp14>MUST</bcp14> be indicated in the message header al
	es Section 2.20</xref>.</t>		ready for the initial request message; see <xref target="RFC9480" format="defaul
			t" sectionFormat="of" section="2.20">CMP Updates</xref>.</t>
	<figure anchor="CMP_envelop">		<figure anchor="CMP_envelop">
	<name>Encrypted Private Key Container</name>		<name>Encrypted Private Key Container</name>
	<artwork align="center" name="" type="" alt=""><![CDATA[		<artwork align="center" name="" type="" alt=""><![CDATA[
	+----------------------------------+		+----------------------------------+
	| EnvelopedData |		| EnvelopedData |
	| [RFC5652] Section 6 |		| [RFC5652], Section 6 |
	| +------------------------------+ |		| +------------------------------+ |
	| | SignedData | |		| | SignedData | |
	| | [RFC5652] Section 5 | |		| | [RFC5652], Section 5 | |
	| | +--------------------------+ | |		| | +--------------------------+ | |
	| | | AsymmetricKeyPackage | | |		| | | AsymmetricKeyPackage | | |
	| | | [RFC5958] | | |		| | | [RFC5958] | | |
	| | | +----------------------+ | | |		| | | +----------------------+ | | |
	| | | | private key | | | |		| | | | private key | | | |
	| | | +----------------------+ | | |		| | | +----------------------+ | | |
	| | +--------------------------+ | |		| | +--------------------------+ | |
	| +------------------------------+ |		| +------------------------------+ |
	+----------------------------------+		+----------------------------------+
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>The PKI management entity delivers the private key in the privateKe y field in the certifiedKeyPair structure of the response message also containin g the newly issued certificate.</t>		<t>The PKI management entity delivers the private key in the privateKe y field in the certifiedKeyPair structure of the response message also containin g the newly issued certificate.</t>
	<t>The private key MUST be provided as an AsymmetricKeyPackage structu		<t>The private key <bcp14>MUST</bcp14> be provided as an AsymmetricKey
	re as defined in <xref target="RFC5958" format="default">RFC&nbsp;5958</xref>.</		Package structure as defined in <xref target="RFC5958" format="default"/>.</t>
	t>		<t>This AsymmetricKeyPackage structure <bcp14>MUST</bcp14> be wrapped
	<t>This AsymmetricKeyPackage structure MUST be wrapped in a SignedData		in a SignedData structure, as specified in <xref target="RFC5652" format="defaul
	structure, as specified in <xref target="RFC5652" format="default">CMS Section		t" sectionFormat="of" section="5">CMS</xref> and <xref target="RFC8933" format="
	5</xref> and <xref target="RFC8933" format="default"/>, signed by the KGA genera		default"/>, and signed by the KGA generating the key pair. The signature <bcp14>
	ting the key pair. The signature MUST be performed using a private key related t		MUST</bcp14> be performed using a private key related to a certificate asserting
	o a certificate asserting the extended key usage id-kp-cmKGA as described in <xr		the extended key usage id-kp-cmKGA, as described in <xref target="RFC9480" form
	ef target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 2.2<		at="default" sectionFormat="of" section="2.2">CMP Updates</xref>, to demonstrate
	/xref> to demonstrate authorization to generate key pairs on behalf of an EE. F		authorization to generate key pairs on behalf of an EE. For response messages
	or response messages using signature-based protection, the EE MUST validate the		using signature-based protection, the EE <bcp14>MUST</bcp14> validate the signer
	signer certificate contained in the SignedData structure and SHOULD authorize th		certificate contained in the SignedData structure and <bcp14>SHOULD</bcp14> aut
	e KGA considering any given id-kp-cmKGA extended key usage in the signer certifi		horize the KGA considering any given id-kp-cmKGA extended key usage in the signe
	cate. For response messages using MAC-based protection the EE MAY omit the vali		r certificate. For response messages using MAC-based protection, the EE <bcp14>
	dation as it may not be possible or meaningful to the EE. In this case the EE a		MAY</bcp14> omit the validation as it may not be possible or meaningful to the E
	uthorizes the KGA using the shard secret information.</t>		E. In this case, the EE authorizes the KGA using the shard secret information.<
	<t>The SignedData structure MUST be wrapped in an EnvelopedData struct		/t>
	ure, as specified in <xref target="RFC5652" format="default">CMS Section 6</xref		<t>The SignedData structure <bcp14>MUST</bcp14> be wrapped in an Envel
	>, encrypting it using a newly generated symmetric content-encryption key.</t>		opedData structure, as specified in <xref target="RFC5652" format="default" sect
	<t>This content-encryption key MUST be securely provided as part of th		ionFormat="of" section="6">CMS</xref>, encrypting it using a newly generated sym
	e EnvelopedData structure to the EE using one of three key management techniques		metric content-encryption key.</t>
	. The choice of the key management technique to be used by the PKI management en		<t>This content-encryption key <bcp14>MUST</bcp14> be securely provide
	tity depends on the authentication mechanism the EE chose to protect the request		d as part of the EnvelopedData structure to the EE using one of three key manage
	message. See <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Upd		ment techniques. The choice of the key management technique to be used by the PK
	ates Section 2.7</xref> for details on which key management technique to use.</t		I management entity depends on the authentication mechanism the EE chose to prot
	>		ect the request message. See <xref target="RFC9480" format="default" sectionForm
			at="of" section="2.7">CMP Updates</xref> for details on which key management tec
			hnique to use.</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>Signature-based protection of the request message:</t>		<t>Signature-based protection of the request message:</t>
	<t>In this case the choice depends on the type of the p ublic key in the CMP protection certificate used by the EE in its request.</t>		<t>In this case, the choice depends on the type of publ ic key in the CMP protection certificate used by the EE in its request.</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The content-encryption key SHALL be protected using the key		<li>The content-encryption key <bcp14>SHALL</bcp14> be protected
	transport key management technique, see <xref target="EE_KGTrans" format="defaul		using the key transport key management technique (see <xref target="EE_KGTrans"
	t"/>, if the key type supports this.</li>		format="default"/>) if the key type supports this.</li>
	<li>The content-encryption key SHALL be protected using the key		<li>The content-encryption key <bcp14>SHALL</bcp14> be protected
	agreement key management technique, see <xref target="EE_KGAgree" format="defaul		using the key agreement key management technique (see <xref target="EE_KGAgree"
	t"/>, if the key type supports this.</li>		format="default"/>) if the key type supports this.</li>
	</ul>		</ul>
	</li>		</li>
	<li>		<li>
	<t>MAC-based protected of the request message:</t>		<t>MAC-based protection of the request message:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The content-encryption key SHALL be protected using the pass word-based key management technique, see <xref target="EE_KGPB" format="default" />, if and only if the EE used MAC-based protection for the request message.</li >		<li>The content-encryption key <bcp14>SHALL</bcp14> be protected using the password-based key management technique (see <xref target="EE_KGPB" f ormat="default"/>) if and only if the EE used MAC-based protection for the reque st message.</li>
	</ul>		</ul>
	</li>		</li>
	</ul>		</ul>
	<t keepWithNext="true">Specific prerequisites augmenting those of the respective certificate enrollment PKI management operations:</t>		<t keepWithNext="true">Specific prerequisites augmenting those of the respective certificate enrollment PKI management operations are as follows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>If signature-based protection is used, the EE MUST be abl		<li>If signature-based protection is used, the EE <bcp14>MUST
	e to authenticate and authorize the KGA, using suitable information, which inclu		</bcp14> be able to authenticate and authorize the KGA using suitable informatio
	des a trust anchor.</li>		n, which includes a trust anchor.</li>
	<li>If MAC-based protection is used, the KGA MUST also kn		<li>If MAC-based protection is used, the KGA <bcp14>MUST<
	ow the shared secret information to protect the encrypted transport of the newly		/bcp14> also know the shared secret information to protect the encrypted transpo
	generated key pair. Consequently, the EE can also authorize the KGA.</li>		rt of the newly generated key pair. Consequently, the EE can also authorize the
	<li>The PKI management entity MUST have a certificate containing the		KGA.</li>
	additional extended key usage extension id-kp-cmKGA for signing the SignedData		<li>The PKI management entity <bcp14>MUST</bcp14> have a certificate
	structure containing the private key package.</li>		containing the additional extended key usage extension id-kp-cmKGA for signing
			the SignedData structure containing the private key package.</li>
	<li>		<li>
	<t>For encrypting the SignedData structure a fresh cont ent-encryption key to be used by the symmetric encryption algorithm MUST be gene rated with sufficient entropy.</t>		<t>For encrypting the SignedData structure, a fresh con tent-encryption key to be used by the symmetric encryption algorithm <bcp14>MUST </bcp14> be generated with sufficient entropy.</t>
	<t>Note: The security strength of the protection of the generated private key should be similar or higher than the security strength of the generated private key.</t>		<t>Note: The security strength of the protection of the generated private key should be similar or higher than the security strength of the generated private key.</t>
	</li>		</li>
	</ul>		</ul>
	<t keepWithNext="true">Detailed Description of privateKey Field:</t>		<t keepWithNext="true">Detailed Description of the privateKey Field:</
	<artwork align="left" name="" type="" alt=""><![CDATA[		t>
			<sourcecode type="pseudocode"><![CDATA[
	privateKey REQUIRED		privateKey REQUIRED
	-- MUST be an EnvelopedData structure as specified in CMS		-- MUST be an EnvelopedData structure, as specified in
	-- Section 6 [RFC5652]		-- Section 6 of CMS [RFC5652]
	version REQUIRED		version REQUIRED
	-- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and		-- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and
	-- KeyTransRecipientInfo		-- KeyTransRecipientInfo
	-- MUST be 0 for recipientInfo type PasswordRecipientInfo		-- MUST be 0 for recipientInfo type PasswordRecipientInfo
	recipientInfos REQUIRED		recipientInfos REQUIRED
	-- MUST contain a sequence of one RecipientInfo, which MUST be		-- MUST contain a sequence of one RecipientInfo, which MUST be
	-- kari of type KeyAgreeRecipientInfo (see section 4.1.6.1),		-- ktri of type KeyTransRecipientInfo (see Section 4.1.6.1),
	-- ktri of type KeyTransRecipientInfo (see section 4.1.6.2), or		-- kari of type KeyAgreeRecipientInfo (see Section 4.1.6.2), or
	-- pwri of type PasswordRecipientInfo (see section 4.1.6.3)		-- pwri of type PasswordRecipientInfo (see Section 4.1.6.3)
	encryptedContentInfo		encryptedContentInfo
	REQUIRED		REQUIRED
	contentType REQUIRED		contentType REQUIRED
	-- MUST be id-signedData		-- MUST be id-signedData
	contentEncryptionAlgorithm		contentEncryptionAlgorithm
	REQUIRED		REQUIRED
	-- MUST be the algorithm identifier of the algorithm used for		-- MUST be the algorithm identifier of the algorithm used for
	-- content encryption		-- content encryption
	-- The algorithm type MUST be a PROT_SYM_ALG as specified in		-- The algorithm type MUST be PROT_SYM_ALG as specified in
	-- RFCBBBB Section 5		-- [RFC9481], Section 5
	encryptedContent REQUIRED		encryptedContent REQUIRED
	-- MUST be the SignedData structure as specified in CMS		-- MUST be the SignedData structure, as specified in Section 5
	-- Section 5 [RFC5652] and [RFC8933] in encrypted form		-- of CMS [RFC5652] and [RFC8933], in encrypted form
	version REQUIRED		version REQUIRED
	-- MUST be 3		-- MUST be 3
	digestAlgorithms		digestAlgorithms
	REQUIRED		REQUIRED
	-- MUST contain a sequence of one AlgorithmIdentifier element		-- MUST contain a sequence of one AlgorithmIdentifier element
	-- MUST be the algorithm identifier of the digest algorithm		-- MUST be the algorithm identifier of the digest algorithm
	-- used for generating the signature and match the signature		-- used for generating the signature and match the signature
	-- algorithm specified in signatureAlgorithm, see [RFC8933]		-- algorithm specified in signatureAlgorithm; see [RFC8933]
	encapContentInfo		encapContentInfo
	REQUIRED		REQUIRED
	-- MUST contain the content that is to be signed		-- MUST contain the content that is to be signed
	eContentType REQUIRED		eContentType REQUIRED
	-- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958]		-- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958]
	eContent REQUIRED		eContent REQUIRED
	-- MUST be of type AsymmetricKeyPackage and		-- MUST be of type AsymmetricKeyPackage and
	-- MUST contain a sequence of one OneAsymmetricKey element		-- MUST contain a sequence of one OneAsymmetricKey element
	version REQUIRED		version REQUIRED
	-- MUST be 1 (indicating v2)		-- MUST be 1 (indicating v2)
	skipping to change at line 1214 ¶		skipping to change at line 1190 ¶
	digestAlgorithm		digestAlgorithm
	REQUIRED		REQUIRED
	-- MUST be the same as in the digestAlgorithms field of		-- MUST be the same as in the digestAlgorithms field of
	-- encryptedContent		-- encryptedContent
	signedAttrs REQUIRED		signedAttrs REQUIRED
	-- MUST contain an id-contentType attribute containing the value		-- MUST contain an id-contentType attribute containing the value
	-- id-ct-KP-aKeyPackage		-- id-ct-KP-aKeyPackage
	-- MUST contain an id-messageDigest attribute containing the		-- MUST contain an id-messageDigest attribute containing the
	-- message digest of eContent		-- message digest of eContent
	-- MAY contain an id-signingTime attribute containing the time		-- MAY contain an id-signingTime attribute containing the time
	-- of signature. It SHOULD be omitted if the transactionTime		-- of a signature. It SHOULD be omitted if the transactionTime
	-- field is not present in the PKIHeader.		-- field is not present in the PKIHeader.
	-- For details on the signed attributes see CMS Section 5.3 and		-- For details on the signed attributes, see Sections 5.3 and
	-- Section 11 [RFC5652] and [RFC8933]		-- 11 of CMS [RFC5652] and [RFC8933]
	signatureAlgorithm		signatureAlgorithm
	REQUIRED		REQUIRED
	-- MUST be the algorithm identifier of the signature algorithm		-- MUST be the algorithm identifier of the signature algorithm
	-- used for calculation of the signature bits		-- used for calculation of the signature bits
	-- The signature algorithm type MUST be a MSG_SIG_ALG as		-- The signature algorithm type MUST be MSG_SIG_ALG, as
	-- specified in RFCBBBB Section 3 and MUST be consistent		-- specified in [RFC9481], Section 3, and MUST be consistent
	-- with the subjectPublicKeyInfo field of the KGA certificate		-- with the subjectPublicKeyInfo field of the KGA certificate
	signature REQUIRED		signature REQUIRED
	-- MUST be the digital signature of the encapContentInfo		-- MUST be the digital signature of the encapContentInfo
	]]></artwork>		]]></sourcecode>
	<t>As stated in Section 1.5, all fields of the ASN.1 syntax tha		<t>As stated in <xref target="Scope"/>, all fields of the ASN.1
	t are defined in RFC 5652 [RFC5652] but are not explicitly specified here SHOULD		syntax that are defined in <xref target="RFC5652"/> but are not explicitly spec
	NOT be used.</t>		ified here <bcp14>SHOULD NOT</bcp14> be used.</t>
	<section anchor="EE_KGTrans" numbered="true" toc="default">		<section anchor="EE_KGTrans" numbered="true" toc="default">
	<name>Using Key Transport Key Management Technique</name>		<name>Using the Key Transport Key Management Technique</name>
	<t>This variant can be applied in combination with the PKI managemen		<t>This variant can be applied in combination with the PKI managemen
	t operations specified in <xref target="EE_newPKI" format="default"/> to <xref t		t operations specified in Sections <xref target="EE_newPKI" format="counter"/> t
	arget="EE_Update" format="default"/> using signature-based protection of CMP mes		o <xref target="EE_Update" format="counter"/> using signature-based protection o
	sages. The EE certificate used for the signature-based protection of the reques		f CMP messages. The EE certificate used for the signature-based protection of t
	t message MUST contain a public key supporting key transport and allow for the k		he request message <bcp14>MUST</bcp14> contain a public key supporting key trans
	ey usage "keyEncipherment". The related key pair MUST be used for encipherment		port and allow for the key usage "keyEncipherment". The related key pair <bcp14
	of the content-encryption key. For this key management technique, the KeyTransR		>MUST</bcp14> be used for encipherment of the content-encryption key. For this
	ecipientInfo structure MUST be used in the contentInfo field.</t>		key management technique, the KeyTransRecipientInfo structure <bcp14>MUST</bcp14
	<t>The KeyTransRecipientInfo structure included into the EnvelopedDa		> be used in the contentInfo field.</t>
	ta structure is specified in <xref target="RFC5652" format="default">CMS Section		<t>The KeyTransRecipientInfo structure included into the EnvelopedDa
	6.2.1</xref>.</t>		ta structure is specified in <xref target="RFC5652" format="default" sectionForm
	<t keepWithNext="true">Detailed Description of KeyTransRecipientInfo		at="of" section="6.2.1">CMS</xref>.</t>
	Structure:</t>		<t keepWithNext="true">Detailed Description of the KeyTransRecipient
	<artwork align="left" name="" type="" alt=""><![CDATA[		Info Structure:</t>
			<sourcecode type="pseudocode"><![CDATA[
	ktri REQUIRED		ktri REQUIRED
	-- MUST be a KeyTransRecipientInfo as specified in CMS		-- MUST be KeyTransRecipientInfo as specified in Section 6.2.1
	-- Section 6.2.1 [RFC5652]		-- of CMS [RFC5652]
	version REQUIRED		version REQUIRED
	-- MUST be 2		-- MUST be 2
	rid REQUIRED		rid REQUIRED
	-- MUST contain the subjectKeyIdentifier of the CMP protection		-- MUST contain the subjectKeyIdentifier of the CMP protection
	-- certificate, if available, in the rKeyId choice and the		-- certificate, if available, in the rKeyId choice, and the
	-- subjectKeyIdentifier MUST equal the senderKID in the		-- subjectKeyIdentifier MUST equal the senderKID in the
	-- PKIHeader.		-- PKIHeader.
	-- If the CMP protection certificate does not contain a		-- If the CMP protection certificate does not contain a
	-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST		-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
	-- be used.		-- be used.
	keyEncryptionAlgorithm		keyEncryptionAlgorithm
	REQUIRED		REQUIRED
	-- MUST be the algorithm identifier of the key transport		-- MUST be the algorithm identifier of the key transport
	-- algorithm. The algorithm type MUST be a KM_KT_ALG as		-- algorithm. The algorithm type MUST be KM_KT_ALG as
	-- specified in RFCBBBB Section 4.2		-- specified in [RFC9481], Section 4.2
	encryptedKey REQUIRED		encryptedKey REQUIRED
	-- MUST be the encrypted content-encryption key		-- MUST be the encrypted content-encryption key
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="EE_KGAgree" numbered="true" toc="default">		<section anchor="EE_KGAgree" numbered="true" toc="default">
	<name>Using Key Agreement Key Management Technique</name>		<name>Using the Key Agreement Key Management Technique</name>
	<t>This variant can be applied in combination with the PKI managemen		<t>This variant can be applied in combination with the PKI managemen
	t operations specified in <xref target="EE_newPKI" format="default"/> to <xref t		t operations specified in Sections <xref target="EE_newPKI" format="counter"/> t
	arget="EE_Update" format="default"/> using signature-based protection of CMP mes		o <xref target="EE_Update" format="counter"/>, using signature-based protection
	sages. The EE certificate used for the signature-based protection of the reques		of CMP messages. The EE certificate used for the signature-based protection of
	t message MUST contain a public key supporting key agreement and allow for the k		the request message <bcp14>MUST</bcp14> contain a public key supporting key agre
	ey usage "keyAgreement". The related key pair MUST be used for establishment of		ement and allow for the key usage "keyAgreement". The related key pair <bcp14>MU
	the content-encryption key. For this key management technique the KeyAgreeRecip		ST</bcp14> be used for establishment of the content-encryption key. For this ke
	ientInfo structure MUST be used in the contentInfo field.</t>		y management technique, the KeyAgreeRecipientInfo structure <bcp14>MUST</bcp14>
	<t>The KeyAgreeRecipientInfo structure included into the EnvelopedDa		be used in the contentInfo field.</t>
	ta structure is specified in <xref target="RFC5652" format="default">CMS Section		<t>The KeyAgreeRecipientInfo structure included into the EnvelopedDa
	6.2.2</xref>.</t>		ta structure is specified in <xref target="RFC5652" format="default" sectionForm
	<t keepWithNext="true">Detailed Description of KeyAgreeRecipientInfo		at="of" section="6.2.2">CMS</xref>.</t>
	Structure:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<t keepWithNext="true">Detailed Description of the KeyAgreeRecipientInfo Structu
			re:</t>
			<sourcecode type="pseudocode"><![CDATA[
	kari REQUIRED		kari REQUIRED
	-- MUST be a KeyAgreeRecipientInfo as specified in CMS Section		-- MUST be KeyAgreeRecipientInfo as specified in Section
	-- 6.2.2 [RFC5652]		-- 6.2.2 of CMS [RFC5652]
	version REQUIRED		version REQUIRED
	-- MUST be 3		-- MUST be 3
	originator REQUIRED		originator REQUIRED
	-- MUST contain the subjectKeyIdentifier of the CMP protection		-- MUST contain the subjectKeyIdentifier of the CMP protection
	-- certificate, if available, in the subjectKeyIdentifier		-- certificate, if available, in the subjectKeyIdentifier
	-- choice and the subjectKeyIdentifier MUST equal the senderKID		-- choice, and the subjectKeyIdentifier MUST equal the
	-- in the PKIHeader.		-- senderKID in the PKIHeader.
	-- If the CMP protection certificate does not contain a		-- If the CMP protection certificate does not contain a
	-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST		-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
	-- be used.		-- be used.
	ukm RECOMMENDED		ukm RECOMMENDED
	-- MUST be used when 1-pass ECMQV is used, see [RFC5753]		-- MUST be used when 1-Pass Elliptic Curve Menezes-Qu-Vanstone
			-- (ECMQV) is used; see [RFC5753]
	-- SHOULD be present to ensure uniqueness of the key		-- SHOULD be present to ensure uniqueness of the key
	-- encryption key		-- encryption key
	keyEncryptionAlgorithm		keyEncryptionAlgorithm
	REQUIRED		REQUIRED
	-- MUST be the algorithm identifier of the key agreement		-- MUST be the algorithm identifier of the key agreement
	-- algorithm		-- algorithm
	-- The algorithm type MUST be a KM_KA_ALG as specified in		-- The algorithm type MUST be KM_KA_ALG as specified in
	-- RFCBBBB Section 4.1		-- [RFC9481], Section 4.1
	-- The parameters field of the key agreement algorithm MUST		-- The parameters field of the key agreement algorithm MUST
	-- contain the key wrap algorithm. The algorithm type		-- contain the key wrap algorithm. The algorithm type
	-- MUST be a KM_KW_ALG as specified in RFCBBBB Section 4.3		-- MUST be KM_KW_ALG as specified in [RFC9481], Section 4.3
	recipientEncryptedKeys		recipientEncryptedKeys
	REQUIRED		REQUIRED
	-- MUST contain a sequence of one RecipientEncryptedKey		-- MUST contain a sequence of one RecipientEncryptedKey
	rid REQUIRED		rid REQUIRED
	-- MUST contain the subjectKeyIdentifier of the CMP protection		-- MUST contain the subjectKeyIdentifier of the CMP protection
	-- certificate, if available, in the rKeyId choice and the		-- certificate, if available, in the rKeyId choice, and the
	-- subjectKeyIdentifier MUST equal the senderKID in the		-- subjectKeyIdentifier MUST equal the senderKID in the
	-- PKIHeader.		-- PKIHeader.
	-- If the CMP protection certificate does not contain a		-- If the CMP protection certificate does not contain a
	-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST		-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
	-- be used		-- be used
	encryptedKey		encryptedKey
	REQUIRED		REQUIRED
	-- MUST be the encrypted content-encryption key		-- MUST be the encrypted content-encryption key
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="EE_KGPB" numbered="true" toc="default">		<section anchor="EE_KGPB" numbered="true" toc="default">
	<name>Using Password-Based Key Management Technique</name>		<name>Using the Password-Based Key Management Technique</name>
	<t>This variant can be applied in combination with the PKI managemen		<t>This variant can be applied in combination with the PKI managemen
	t operation specified in <xref target="EE_MAC" format="default"/> using MAC-base		t operation specified in <xref target="EE_MAC" format="default"/>, using MAC-bas
	d protection of CMP messages. The shared secret information used for the MAC-ba		ed protection of CMP messages. The shared secret information used for the MAC-b
	sed protection MUST also be used for the encryption of the content-encryption ke		ased protection <bcp14>MUST</bcp14> also be used for the encryption of the conte
	y but with a different salt value applied in the key derivation algorithm. For		nt-encryption key but with a different salt value applied in the key derivation
	this key management technique, the PasswordRecipientInfo structure MUST be used		algorithm. For this key management technique, the PasswordRecipientInfo structu
	in the contentInfo field.</t>		re <bcp14>MUST</bcp14> be used in the contentInfo field.</t>
	<t>Note: The entropy of the shared secret information is		<t>Note: The entropy of the shared secret information is
	crucial for the level of protection when using a password-based key management t		crucial for the level of protection when using a password-based key management t
	echnique. For centrally generated key pairs, the entropy of the shared secret i		echnique. For centrally generated key pairs, the entropy of the shared secret i
	nformation SHALL NOT be less than the security strength of the centrally generat		nformation <bcp14>SHALL NOT</bcp14> be less than the security strength of the ce
	ed key pair. Further guidance is available in <xref target="Security" format="d		ntrally generated key pair. Further guidance is available in <xref target="Secu
	efault"/>.</t>		rity" format="default"/>.</t>
	<t>The PasswordRecipientInfo structure included into the EnvelopedDa		<t>The PasswordRecipientInfo structure included into the EnvelopedDa
	ta structure is specified in <xref target="RFC5652" format="default">CMS Section		ta structure is specified in <xref target="RFC5652" format="default" sectionForm
	6.2.4</xref>.</t>		at="of" section="6.2.4">CMS</xref>.</t>
	<t keepWithNext="true">Detailed Description of PasswordRecipientInfo		<t keepWithNext="true">Detailed Description of the PasswordRecipient
	Structure:</t>		Info Structure:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	pwri REQUIRED		pwri REQUIRED
	-- MUST be a PasswordRecipientInfo as specified in CMS		-- MUST be PasswordRecipientInfo as specified in
	-- Section 6.2.4 [RFC5652]		-- Section 6.2.4 of CMS [RFC5652]
	version REQUIRED		version REQUIRED
	-- MUST be 0		-- MUST be 0
	keyDerivationAlgorithm		keyDerivationAlgorithm
	REQUIRED		REQUIRED
	-- MUST be the algorithm identifier of the key derivation		-- MUST be the algorithm identifier of the key derivation
	-- algorithm		-- algorithm
	-- The algorithm type MUST be a KM_KD_ALG as specified in		-- The algorithm type MUST be KM_KD_ALG as specified in
	-- RFCBBBB Section 4.4		-- [RFC9481], Section 4.4
	keyEncryptionAlgorithm		keyEncryptionAlgorithm
	REQUIRED		REQUIRED
	-- MUST be the algorithm identifier of the key wrap algorithm		-- MUST be the algorithm identifier of the key wrap algorithm
	-- The algorithm type MUST be a KM_KW_ALG as specified in		-- The algorithm type MUST be KM_KW_ALG as specified in
	-- RFCBBBB Section 4.3		-- [RFC9481], Section 4.3
	encryptedKey REQUIRED		encryptedKey REQUIRED
	-- MUST be the encrypted content-encryption key		-- MUST be the encrypted content-encryption key
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="EE_Revoke" numbered="true" toc="default">		<section anchor="EE_Revoke" numbered="true" toc="default">
	<name>Revoking a Certificate</name>		<name>Revoking a Certificate</name>
	<t>This PKI management operation should be used by an entity to request		<t>This PKI management operation should be used by an entity to request
	revocation of a certificate. Here the revocation request is used by an EE to rev		revocation of a certificate. Here, the revocation request is used by an EE to re
	oke one of its own certificates.</t>		voke one of its own certificates.</t>
	<t>The revocation request message MUST be signed using the certificate t		<t>The revocation request message <bcp14>MUST</bcp14> be signed using th
	hat is to be revoked to prove the authorization to revoke. The revocation reques		e certificate that is to be revoked to prove the authorization to revoke. The re
	t message is signature-protected using this certificate. This requires, that the		vocation request message is signature-protected using this certificate. This req
	EE still possesses the private key. If this is not the case the revocation has		uires that the EE still possesses the private key. If this is not the case, the
	to be initiated by other means, e.g., revocation by the RA as specified in <xref		revocation has to be initiated by other means, e.g., revocation by the RA, as sp
	target="RA_on-behalf_revoke" format="default"/>.</t>		ecified in <xref target="RA_on-behalf_revoke" format="default"/>.</t>
	<t>An EE requests revoking a certificate of its own at the CA that issue		<t>An EE requests revoking a certificate of its own at the CA that issue
	d this certificate. The PKI management entity handles the request as described i		d this certificate. The PKI management entity handles the request as described i
	n <xref target="RA_response_revocation" format="default"/> and responds with a m		n <xref target="RA_response_revocation" format="default"/>, and responds with a
	essage that contains the status of the revocation from the CA.</t>		message that contains the status of the revocation from the CA.</t>
	<t keepWithNext="true">Specific prerequisites augmenting the prerequisit		<t keepWithNext="true">The specific prerequisite augmenting the prerequi
	es in <xref target="Prereq" format="default"/>:</t>		sites in <xref target="Prereq" format="default"/> is as follows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The certificate the EE wishes to revoke is not yet expired or revoked.</li>		<li>The certificate the EE wishes to revoke is not yet expired or revoked.</li>
	</ul>		</ul>
	<t keepWithNext="true">Message Flow:</t>		<t keepWithNext="true">Message Flow:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<artwork align="left" name="" type="" alt=""><![CDATA[
	Step# EE PKI management entity		Step# EE PKI management entity
	1 format rr		1 format rr
	2 -> rr ->		2 -> rr ->
	3 handle or forward rr		3 handle or forward rr
	4 format or receive rp		4 format or receive rp
	5 <- rp <-		5 <- rp <-
	6 handle rp		6 handle rp
	]]></artwork>		]]></artwork>
	<t>For this PKI management operation, the EE MUST include a sequence of one RevDetails structure in the rr message body. In the case no generic error oc curred, the response to the rr MUST be an rp message containing a single status field.</t>		<t>For this PKI management operation, the EE <bcp14>MUST</bcp14> include a sequence of one RevDetails structure in the rr message body. In the case no g eneric error occurred, the response to the rr <bcp14>MUST</bcp14> be an rp messa ge containing a single status field.</t>
	<t keepWithNext="true">Detailed Message Description:</t>		<t keepWithNext="true">Detailed Message Description:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	Revocation Request -- rr		Revocation Request -- rr
	Field Value		Field Value
	header		header
	-- As described in Section 3.1		-- As described in Section 3.1
	body		body
	-- The request of the EE to revoke its certificate		-- The request of the EE to revoke its certificate
	rr REQUIRED		rr REQUIRED
	skipping to change at line 1379 ¶		skipping to change at line 1357 ¶
	certDetails REQUIRED		certDetails REQUIRED
	-- MUST be present and is of type CertTemplate		-- MUST be present and is of type CertTemplate
	serialNumber REQUIRED		serialNumber REQUIRED
	-- MUST contain the certificate serialNumber attribute of the		-- MUST contain the certificate serialNumber attribute of the
	-- certificate to be revoked		-- certificate to be revoked
	issuer REQUIRED		issuer REQUIRED
	-- MUST contain the issuer attribute of the certificate to be		-- MUST contain the issuer attribute of the certificate to be
	-- revoked		-- revoked
	crlEntryDetails REQUIRED		crlEntryDetails REQUIRED
	-- MUST contain a sequence of one reasonCode of type CRLReason		-- MUST contain a sequence of one reasonCode of type CRLReason
	-- (see [RFC5280] section 5.3.1)		-- (see [RFC5280], Section 5.3.1)
	-- If the reason for this revocation is not known or shall not		-- If the reason for this revocation is not known or shall not
	-- be published the reasonCode MUST be 0 (unspecified)		-- be published, the reasonCode MUST be 0 (unspecified)
	protection REQUIRED		protection REQUIRED
	-- As described in Section 3.2 and using the private key related		-- As described in Section 3.2 and using the private key related
	-- to the certificate to be revoked		-- to the certificate to be revoked
	extraCerts REQUIRED		extraCerts REQUIRED
	-- As described in Section 3.3		-- As described in Section 3.3
	Revocation Response -- rp		Revocation Response -- rp
	Field Value		Field Value
	header		header
	-- As described in Section 3.1		-- As described in Section 3.1
	body		body
	-- The responds of the PKI management entity to the request as		-- The response of the PKI management entity to the request as
	-- appropriate		-- appropriate
	rp REQUIRED		rp REQUIRED
	status REQUIRED		status REQUIRED
	-- MUST contain a sequence of one element of type PKIStatusInfo		-- MUST contain a sequence of one element of type PKIStatusInfo
	status REQUIRED		status REQUIRED
	-- positive value allowed: "accepted"		-- positive value allowed: "accepted"
	-- negative value allowed: "rejection"		-- negative value allowed: "rejection"
	statusString OPTIONAL		statusString OPTIONAL
	-- MAY be any human-readable text for debugging, logging or to		-- MAY be any human-readable text for debugging, for logging, or
	-- display in a GUI		-- to display in a GUI
	failInfo OPTIONAL		failInfo OPTIONAL
	-- MAY be present if status is "rejection"		-- MAY be present if the status is "rejection"
	-- MUST be absent if the status is "accepted"		-- MUST be absent if the status is "accepted"
	protection REQUIRED		protection REQUIRED
	-- As described in section 3.2		-- As described in Section 3.2
	extraCerts REQUIRED		extraCerts REQUIRED
	-- As described in section 3.3		-- As described in Section 3.3
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="EE_GeneralMessage" numbered="true" toc="default">		<section anchor="EE_GeneralMessage" numbered="true" toc="default">
	<name>Support Messages</name>		<name>Support Messages</name>
	<t>The following support messages offer on demand in-band delivery of co		<t>The following support messages offer on-demand, in-band delivery of c
	ntent relevant to the EE provided by a PKI management entity. CMP general messa		ontent relevant to the EE provided by a PKI management entity. CMP general mess
	ges and general response are used for this purpose. Depending on the environmen		ages and general response are used for this purpose. Depending on the environme
	t, these requests may be answered by an RA or CA (see also <xref target="RA_resp		nt, these requests may be answered by an RA or CA (see also <xref target="RA_res
	onse_support" format="default"/>).</t>		ponse_support" format="default"/>).</t>
	<t>The general messages and general response messages contain InfoTypeAn		<t>The general messages and general response messages contain InfoTypeAn
	dValue structures. In addition to those infoType values defined in <xref target=		dValue structures. In addition to those infoType values defined in <xref target=
	"RFC4210" format="default">RFC&nbsp;4210</xref> and <xref target="I-D.ietf-lamps		"RFC4210" format="default"/> and <xref target="RFC9480" format="default">CMP Upd
	-cmp-updates" format="default">CMP Updates</xref> further OIDs MAY be used to de		ates</xref>, further OIDs <bcp14>MAY</bcp14> be used to define new PKI managemen
	fine new PKI management operations or new general-purpose support messages as ne		t operations or new general-purpose support messages as needed in specific envir
	eded in specific environments.</t>		onments.</t>
	<t keepWithNext="true">The following contents are specified in this docu ment:</t>		<t keepWithNext="true">The following contents are specified in this docu ment:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Get CA certificates</li>		<li>Get CA certificates.</li>
	<li>Get root CA certificate update</li>		<li>Get root CA certificate update.</li>
	<li>Get certificate request template</li>		<li>Get certificate request template.</li>
	<li>Get new CRLs</li>		<li>Get new Certificate Revocation Lists (CRLs).</li>
	</ul>		</ul>
	<t>The following message flow and contents are common to all general mes sage (genm) and general response (genp) messages.</t>		<t>The following message flow and contents are common to all general mes sage (genm) and general response (genp) messages.</t>
	<t keepWithNext="true">Message Flow:</t>		<t keepWithNext="true">Message Flow:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<artwork align="left" name="" type="" alt=""><![CDATA[
	Step# EE PKI management entity		Step# EE PKI management entity
	1 format genm		1 format genm
	2 -> genm ->		2 -> genm ->
	3 handle or forward genm		3 handle or forward genm
	4 format or receive genp		4 format or receive genp
	5 <- genp <-		5 <- genp <-
	6 handle genp		6 handle genp
	]]></artwork>		]]></artwork>
	<t keepWithNext="true">Detailed Message Description:</t>		<t keepWithNext="true">Detailed Message Description:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	General Message -- genm		General Message -- genm
	Field Value		Field Value
	header		header
	-- As described in Section 3.1		-- As described in Section 3.1
	body		body
	-- A request by the EE for information		-- A request by the EE for information
	genm REQUIRED		genm REQUIRED
	skipping to change at line 1491 ¶		skipping to change at line 1469 ¶
	-- MUST be the OID identifying the specific PKI management		-- MUST be the OID identifying the specific PKI management
	-- operation described below		-- operation described below
	infoValue OPTIONAL		infoValue OPTIONAL
	-- MUST be as specified for the specific PKI management operation		-- MUST be as specified for the specific PKI management operation
	protection REQUIRED		protection REQUIRED
	-- As described in Section 3.2		-- As described in Section 3.2
	extraCerts REQUIRED		extraCerts REQUIRED
	-- As described in Section 3.3		-- As described in Section 3.3
	]]></artwork>		]]></sourcecode>
	<section anchor="EE_CACerts" numbered="true" toc="default">		<section anchor="EE_CACerts" numbered="true" toc="default">
	<name>Get CA Certificates</name>		<name>Get CA Certificates</name>
	<t>This PKI management operation can be used by an EE to request CA ce rtificates from the PKI management entity.</t>		<t>This PKI management operation can be used by an EE to request CA ce rtificates from the PKI management entity.</t>
	<t>An EE requests CA certificates, e.g., for chain construction, from an PKI management entity by sending a general message with OID id-it-caCerts as specified in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Upda tes Section 2.14</xref>. The PKI management entity responds with a general respo nse with the same OID that either contains a SEQUENCE of certificates populated with the available intermediate and issuing CA certificates or with no content i n case no CA certificate is available.</t>		<t>An EE requests CA certificates, e.g., for chain construction, from a PKI management entity by sending a general message with OID id-it-caCerts, as specified in <xref target="RFC9480" format="default" sectionFormat="of" section= "2.14">CMP Updates</xref>. The PKI management entity responds with a general res ponse with the same OID that either contains a SEQUENCE of certificates populate d with the available intermediate and issuing CA certificates or no content in c ase no CA certificate is available.</t>
	<t>No specific prerequisites apply in addition to those specifi ed in <xref target="Prereq" format="default"/>.</t>		<t>No specific prerequisites apply in addition to those specifi ed in <xref target="Prereq" format="default"/>.</t>
	<t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t>		<t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t>
	<ol spacing="normal" type="%d">		<ol spacing="normal" type="1">
	<li>the infoType OID to use is id-it-caCerts</li>		<li>the infoType OID to use is id-it-caCerts</li>
	<li>the infoValue of the request MUST be absent</li>		<li>the infoValue of the request <bcp14>MUST</bcp14> be absent</li>
	<li>if present, the infoValue of the response MUST contain a sequenc		<li>if present, the infoValue of the response <bcp14>MUST</bcp14> co
	e of certificates</li>		ntain a sequence of certificates</li>
	</ol>		</ol>
	<t keepWithNext="true">Detailed Description of infoValue Field of genp		<t keepWithNext="true">Detailed Description of the infoValue Field of
	:</t>		genp:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	infoValue OPTIONAL		infoValue OPTIONAL
	-- MUST be absent if no CA certificate is available		-- MUST be absent if no CA certificate is available
	-- MUST be present if CA certificates are available		-- MUST be present if CA certificates are available
	-- if present, MUST be a sequence of CMPCertificate		-- if present, MUST be a sequence of CMPCertificate
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="EE_RootCAUpdate" numbered="true" toc="default">		<section anchor="EE_RootCAUpdate" numbered="true" toc="default">
	<name>Get Root CA Certificate Update</name>		<name>Get Root CA Certificate Update</name>
	<t>This PKI management operation can be used by an EE to request an up		<t>This PKI management operation can be used by an EE to request an up
	dated root CA Certificate as described in <xref target="RFC4210" format="default		dated root CA certificate as described in <xref target="RFC4210" format="default
	">Section 4.4 of RFC&nbsp;4210</xref>.</t>		" sectionFormat="of" section="4.4"/>.</t>
	<t>An EE requests an update of a root CA certificate from the P		<t>An EE requests an update of a root CA certificate from the PKI manag
	KI management entity by sending a general message with OID id-it-rootCaCert. If		ement entity by sending a general message with OID id-it-rootCaCert. If needed f
	needed for unique identification, the EE MUST include the old root CA certificat		or unique identification, the EE <bcp14>MUST</bcp14> include the old root CA cer
	e in the message body, as specified in <xref target="I-D.ietf-lamps-cmp-updates"		tificate in the message body as specified in <xref target="RFC9480" format="defa
	format="default">CMP Updates Section 2.15</xref>. The PKI management entity re		ult" sectionFormat="of" section="2.15">CMP Updates</xref>. The PKI management e
	sponds with a general response with OID id-it-rootCaKeyUpdate that either contai		ntity responds with a general response with OID id-it-rootCaKeyUpdate that eithe
	ns the update of the root CA certificate consisting of up to three certificates,		r contains the update of the root CA certificate consisting of up to three certi
	or with no content in case no update is available.</t>		ficates or no content in case no update is available.</t>
	<t>Note: This mechanism may also be used to update trusted non-		<t>Note: This mechanism may also be used to update trusted non-
	root certificates, i.e., directly trusted intermediate CA or issuing CA certific		root certificates, e.g., directly trusted intermediate or issuing CA certificate
	ates.</t>		s.</t>
	<t>The newWithNew certificate is the new root CA certificate and is RE		<t>The newWithNew certificate is the new root CA certificate and is <b
	QUIRED to be present if available. The newWithOld certificate is REQUIRED to be		cp14>REQUIRED</bcp14> to be present if available. The newWithOld certificate is
	present in the response message because it is needed for the receiving entity t		<bcp14>REQUIRED</bcp14> to be present in the response message because it is nee
	rusting the old root CA certificate to gain trust in the new root CA certificate		ded for the receiving entity trusting the old root CA certificate to gain trust
	. The oldWithNew certificate is OPTIONAL because it is only needed in rare scen		in the new root CA certificate. The oldWithNew certificate is <bcp14>OPTIONAL</
	arios where other entities may not already trust the old root CA.</t>		bcp14> because it is only needed in rare scenarios where other entities may not
			already trust the old root CA.</t>
	<t>No specific prerequisites apply in addition to those specifi ed in <xref target="Prereq" format="default"/>.</t>		<t>No specific prerequisites apply in addition to those specifi ed in <xref target="Prereq" format="default"/>.</t>
	<t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t>		<t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t>
	<ol spacing="normal" type="%d">		<ol spacing="normal" type="1">
	<li>the infoType OID to use is id-it-rootCaCert in the reques		<li>the infoType OID to use is id-it-rootCaCert in the request and id
	t and id-it-rootCaKeyUpdate in the response</li>		-it-rootCaKeyUpdate in the response</li>
	<li>the infoValue of the request SHOULD contain the root CA certific		<li>the infoValue of the request <bcp14>SHOULD</bcp14> contain the r
	ate the update is requested for</li>		oot CA certificate the update is requested for</li>
	<li>if present, the infoValue of the response MUST be a RootCaKeyUpd		<li>if present, the infoValue of the response <bcp14>MUST</bcp14> be
	ateContent structure</li>		a RootCaKeyUpdateContent structure</li>
	</ol>		</ol>
	<t keepWithNext="true">Detailed Description of infoValue Field of genm		<t keepWithNext="true">Detailed Description of the infoValue Field of
	:</t>		genm:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	infoValue RECOMMENDED		infoValue RECOMMENDED
	-- MUST contain the root CA certificate to be updated if needed		-- MUST contain the root CA certificate to be updated if needed
	-- for unique identification		-- for unique identification
	]]></artwork>		]]></sourcecode>
	<t keepWithNext="true">Detailed Description of infoValue Field of genp		<t keepWithNext="true">Detailed Description of the infoValue Field of
	:</t>		genp:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	infoValue OPTIONAL		infoValue OPTIONAL
	-- MUST be absent if no update of the root CA certificate is		-- MUST be absent if no update of the root CA certificate is
	-- available		-- available
	-- MUST be present if an update of the root CA certificate		-- MUST be present if an update of the root CA certificate
	-- is available and MUST be of type RootCaKeyUpdateContent		-- is available and MUST be of type RootCaKeyUpdateContent
	newWithNew REQUIRED		newWithNew REQUIRED
	-- MUST be present if infoValue is present		-- MUST be present if infoValue is present
	-- MUST contain the new root CA certificate		-- MUST contain the new root CA certificate
	newWithOld REQUIRED		newWithOld REQUIRED
	-- MUST be present if infoValue is present		-- MUST be present if infoValue is present
	-- MUST contain a certificate containing the new public		-- MUST contain a certificate containing the new public
	-- root CA key signed with the old private root CA key		-- root CA key signed with the old private root CA key
	oldWithNew OPTIONAL		oldWithNew OPTIONAL
	-- MAY be present if infoValue is present		-- MAY be present if infoValue is present
	-- MUST contain a certificate containing the old public		-- MUST contain a certificate containing the old public
	-- root CA key signed with the new private root CA key		-- root CA key signed with the new private root CA key
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="EE_Temp" numbered="true" toc="default">		<section anchor="EE_Temp" numbered="true" toc="default">
	<name>Get Certificate Request Template</name>		<name>Get Certificate Request Template</name>
	<t>This PKI management operation can be used by an EE to request a tem plate with parameters for future certificate requests.</t>		<t>This PKI management operation can be used by an EE to request a tem plate with parameters for future certificate requests.</t>
	<t>An EE requests certificate request parameters from the PKI m		<t>An EE requests certificate request parameters from the PKI m
	anagement entity by sending a general message with OID id-it-certReqTemplate as		anagement entity by sending a general message with OID id-it-certReqTemplate as
	specified in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Upda		specified in <xref target="RFC9480" format="default" sectionFormat="of" section=
	tes Section 2.16</xref>. The EE MAY indicate the certificate profile to use in		"2.16">CMP Updates</xref>. The EE <bcp14>MAY</bcp14> indicate the certificate p
	the id-it-certProfile extension of the generalInfo field in the PKIHeader of the		rofile to use in the id-it-certProfile extension of the generalInfo field in the
	general message as described in <xref target="Header" format="default"/>. The		PKIHeader of the general message as described in <xref target="Header" format="
	PKI management entity responds with a general response with the same OID that ei		default"/>. The PKI management entity responds with a general response with the
	ther contains requirements on the certificate request template, or with no conte		same OID that either contains requirements on the certificate request template
	nt in case no specific requirements are imposed by the PKI. The CertReqTemplateV		or no content in case no specific requirements are imposed by the PKI. The CertR
	alue contains requirements on certificate fields and extensions in a certTemplat		eqTemplateValue contains requirements on certificate fields and extensions in a
	e. Optionally it contains a keySpec field containing requirements on algorithms		certTemplate. Optionally, it contains a keySpec field containing requirements on
	acceptable for key pair generation.</t>		algorithms acceptable for key pair generation.</t>
	<t>The EE SHOULD follow the requirements from the received CertTemplat		<t>The EE <bcp14>SHOULD</bcp14> follow the requirements from the recei
	e, by including in the certificate requests all the fields requested, taking ove		ved CertTemplate by including in the certificate requests all the fields request
	r all the field values provided and filling in any remaining fields values. The		ed, taking over all the field values provided and filling in any remaining field
	EE SHOULD NOT add further fields, name components, and extensions or their (sub-		s values. The EE <bcp14>SHOULD NOT</bcp14> add further fields, name components,
	)components. If deviating from the recommendations of the template, the certifi		and extensions or their (sub)components. If deviating from the recommendations
	cate request might be rejected.</t>		of the template, the certificate request might be rejected.</t>
	<t>Note: We deliberately do not use "MUST" or "MUST NOT" here in order		<t>Note: We deliberately do not use "<bcp14>MUST</bcp14>" or "<bcp14>M
	to allow more flexibility in case the rules given here are not sufficient for s		UST NOT</bcp14>" here in order to allow more flexibility in case the rules given
	pecific scenarios. The EE can populate the certificate request as wanted and ign		here are not sufficient for specific scenarios. The EE can populate the certifi
	ore any of the requirements contained in the CertReqTemplateValue. On the other		cate request as wanted and ignore any of the requirements contained in the CertR
	hand, a PKI management entity is free to ignore or replace any parts of the cont		eqTemplateValue. On the other hand, a PKI management entity is free to ignore or
	ent of the certificate request provided by the EE. The CertReqTemplate PKI manag		replace any parts of the content of the certificate request provided by the EE.
	ement operation offers means to ease a joint understanding which fields and/or w		The CertReqTemplate PKI management operation offers means to ease a joint under
	hich field values should be used. An example is provided in <xref target="Param_		standing of which fields and/or which field values should be used. An example is
	Example" format="default"/>.</t>		provided in <xref target="Param_Example" format="default"/>.</t>
	<t>In case a field of type Name, e.g., subject, is present in the Cert		<t>In case a field of type Name, e.g., subject, is present in the Cert
	Template but has the value NULL-DN (i.e., has an empty list of RDN components),		Template but has the value NULL-DN (i.e., has an empty list of relative distingu
	the field SHOULD be included in the certificate request and filled with content		ished name (RDN) components), the field <bcp14>SHOULD</bcp14> be included in the
	provided by the EE. Similarly, in case an X.509v3 extension is present but its e		certificate request and filled with content provided by the EE. Similarly, in c
	xtnValue is empty, this means that the extension SHOULD be included and filled w		ase an X.509v3 extension is present but its extnValue is empty, this means that
	ith content provided by the EE. In case a Name component, for instance a common		the extension <bcp14>SHOULD</bcp14> be included and filled with content provided
	name or serial number, is given but has an empty string value, the EE SHOULD fil		by the EE. In case a Name component, for instance, a common name or serial numb
	l in a value. Similarly, in case an extension has sub-components (e.g., an IP ad		er, is given but has an empty string value, the EE <bcp14>SHOULD</bcp14> fill in
	dress in a SubjectAltName field) with empty value, the EE SHOULD fill in a value		a value. Similarly, in case an extension has subcomponents (e.g., an IP address
	.</t>		in a SubjectAltName field) with empty values, the EE <bcp14>SHOULD</bcp14> fill
	<t>The EE MUST ignore (i.e., not include and fill in) empty fields, ex		in a value.</t>
	tensions, and sub-components that it does not understand or does not know suitab		<t>The EE <bcp14>MUST</bcp14> ignore (i.e., not include) empty fields,
	le values to be filled in.</t>		extensions, and subcomponents that it does not understand or does not know suit
	<t>The publicKey field of type SubjectPublicKeyInfo in the CertTemplat		able values to fill in.</t>
	e of the CertReqTemplateValue MUST be omitted. In case the PKI management entity		<t>The publicKey field of type SubjectPublicKeyInfo in the CertTemplat
	wishes to make stipulation on algorithms the EE may use for key generation, thi		e of the CertReqTemplateValue <bcp14>MUST</bcp14> be omitted. In case the PKI ma
	s MUST be specified using the keySpec field as specified in <xref target="I-D.ie		nagement entity wishes to make a stipulation on algorithms the EE may use for ke
	tf-lamps-cmp-updates" format="default">CMP Updates Section 2.16</xref>.</t>		y generation, this <bcp14>MUST</bcp14> be specified using the keySpec field as s
	<t>The keySpec field, if present, specifies the public key types optio		pecified in <xref target="RFC9480" format="default" sectionFormat="of" section="
	nally with parameters, and/or RSA key lengths for which a certificate may be req		2.16">CMP Updates</xref>.</t>
	uested.</t>		<t>The keySpec field, if present, specifies the public key types optio
	<t>The value of a keySpec element with the OID id-regCtrl-algId, as sp		nally with parameters and/or RSA key lengths for which a certificate may be requ
	ecified in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Update		ested.</t>
	s Section 2.16</xref>, MUST be of type AlgorithmIdentifier and give an algorithm		<t>The value of a keySpec element with the OID id-regCtrl-algId, as sp
	other than RSA. For EC keys the curve information MUST be specified as describ		ecified in <xref target="RFC9480" format="default" sectionFormat="of" section="2
	ed in the respective standard documents.</t>		.16">CMP Updates</xref>, <bcp14>MUST</bcp14> be of type AlgorithmIdentifier and
	<t>The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, a		give an algorithm other than RSA. For Elliptic Curve (EC) keys, the curve infor
	s specified in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Up		mation <bcp14>MUST</bcp14> be specified as described in the respective standard
	dates Section 2.16</xref>, MUST be a positive integer value and give an RSA key		documents.</t>
	length.</t>		<t>The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, a
	<t>In the CertTemplate of the CertReqTemplateValue the serialNumber, s		s specified in <xref target="RFC9480" format="default" sectionFormat="of" sectio
	igningAlg, issuerUID, and subjectUID fields MUST be omitted.</t>		n="2.16">CMP Updates</xref>, <bcp14>MUST</bcp14> be a positive integer value and
	<t keepWithNext="true">Specific prerequisites augmenting the prerequis		give an RSA key length.</t>
	ites in <xref target="Prereq" format="default"/>:</t>		<t>In the CertTemplate of the CertReqTemplateValue, the serialNumber,
			signingAlg, issuerUID, and subjectUID fields <bcp14>MUST</bcp14> be omitted.</t>
			<t keepWithNext="true">The specific prerequisites augmenting the prere
			quisites in <xref target="Prereq" format="default"/> is as follows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile.</li>		<li>When using the generalInfo field certProfile, the EE <bcp14>MUST< /bcp14> know the identifier needed to indicate the requested certificate profile .</li>
	</ul>		</ul>
	<t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t>		<t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t>
	<ol spacing="normal" type="%d">		<ol spacing="normal" type="1">
	<li>the infoType OID to use is id-it-certReqTemplate</li>		<li>the infoType OID to use is id-it-certReqTemplate</li>
	<li>the id-it-certProfile generalInfo field in the header of the req		<li>the id-it-certProfile generalInfo field in the header of the req
	uest MAY contain the name of the requested certificate request template</li>		uest <bcp14>MAY</bcp14> contain the name of the requested certificate request te
	<li>the infoValue of the request MUST be absent</li>		mplate</li>
	<li>if present, the infoValue of the response MUST be a CertReqTempl		<li>the infoValue of the request <bcp14>MUST</bcp14> be absent</li>
	ateValue containing a CertTemplate structure and an optional keySpec field</li>		<li>if present, the infoValue of the response <bcp14>MUST</bcp14> be
			a CertReqTemplateValue containing a CertTemplate structure and an optional keyS
			pec field</li>
	</ol>		</ol>
	<t keepWithNext="true">Detailed Description of infoValue Field of genp		<t keepWithNext="true">Detailed Description of the infoValue Field of
	:</t>		genp:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	InfoValue OPTIONAL		InfoValue OPTIONAL
	-- MUST be absent if no requirements are available		-- MUST be absent if no requirements are available
	-- MUST be present if the PKI management entity has any		-- MUST be present if the PKI management entity has any
	-- requirements on the contents of the certificate template		-- requirements on the contents of the certificate template
	certTemplate REQUIRED		certTemplate REQUIRED
	-- MUST be present if infoValue is present		-- MUST be present if infoValue is present
	-- MUST contain the required CertTemplate structure elements		-- MUST contain the required CertTemplate structure elements
	-- The SubjectPublicKeyInfo field MUST be absent		-- The SubjectPublicKeyInfo field MUST be absent
	keySpec OPTIONAL		keySpec OPTIONAL
	-- MUST be absent if no requirements on the public key are		-- MUST be absent if no requirements on the public key are
	-- available		-- available
	-- MUST be present if the PKI management entity has any		-- MUST be present if the PKI management entity has any
	-- requirements on the keys generated		-- requirements on the keys generated
	-- MUST contain a sequence of one AttributeTypeAndValue per		-- MUST contain a sequence of one AttributeTypeAndValue per
	-- supported algorithm with attribute id-regCtrl-algId or		-- supported algorithm with attribute id-regCtrl-algId or
	-- id-regCtrl-rsaKeyLen		-- id-regCtrl-rsaKeyLen
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="EE_CRLs" numbered="true" toc="default">		<section anchor="EE_CRLs" numbered="true" toc="default">
	<name>CRL Update Retrieval</name>		<name>CRL Update Retrieval</name>
	<t>This PKI management operation can be used by an EE to request a new		<t>This PKI management operation can be used by an EE to request a new
	CRL. If a CA offers methods to access a CRL, it may include CRL distribution p		CRL. If a CA offers methods to access a CRL, it may include CRL distribution p
	oints or authority information access extensions as specified in <xref target="R		oints or authority information access extensions into the issued certificates as
	FC5280" format="default">RFC&nbsp;5280</xref> into the issued certificates. In		specified in <xref target="RFC5280" format="default"/>. In addition, CMP offer
	addition, CMP offers CRL provisioning functionality as part of the PKI managemen		s CRL provisioning functionality as part of the PKI management operation.</t>
	t operation.</t>		<t>An EE requests a CRL update from the PKI management entity by sendi
	<t>An EE requests a CRL update from the PKI management entity by sendi		ng a general message with OID id-it-crlStatusList. The EE <bcp14>MUST</bcp14> i
	ng a general message with OID id-it-crlStatusList. The EE MUST include the CRL		nclude the CRL source identifying the requested CRL and, if available, the thisU
	source identifying the requested CRL and, if available, the thisUpdate time of t		pdate time of the most current CRL instance it already has, as specified in <xre
	he most current CRL instance it already has, as specified in <xref target="I-D.i		f target="RFC9480" format="default" sectionFormat="of" section="2.17">CMP Update
	etf-lamps-cmp-updates" format="default">CMP Updates Section 2.17</xref>. The PK		s</xref>. The PKI management entity <bcp14>MUST</bcp14> respond with a general
	I management entity MUST respond with a general response with OID id-it-crls.</t		response with OID id-it-crls.</t>
	>		<t>The EE <bcp14>MUST</bcp14> identify the requested CRL either
	<t>The EE MUST identify the requested CRL either by a CRL distr		by a CRL distribution point name or issuer name.</t>
	ibution point name or issuer name.</t>
	<t>Note: CRL distribution point names can be obtained from a cR LDistributionPoints extension of a certificate to be validated or from an issuin gDistributionPoint extension of the CRL to be updated. CRL issuer names can be o btained from the cRLDistributionPoints extension of a certificate, from the issu er field of the authority key identifier extension of a certificate or CRL, and from the issuer field of a certificate or CRL.</t>		<t>Note: CRL distribution point names can be obtained from a cR LDistributionPoints extension of a certificate to be validated or from an issuin gDistributionPoint extension of the CRL to be updated. CRL issuer names can be o btained from the cRLDistributionPoints extension of a certificate, from the issu er field of the authority key identifier extension of a certificate or CRL, and from the issuer field of a certificate or CRL.</t>
	<t>If a thisUpdate value was given, the PKI management entity M UST return the latest CRL available from the referenced source if this CRL is mo re recent than the given thisUpdate time. If no thisUpdate value was given, it MUST return the latest CRL available from the referenced source. In all other c ases the infoValue in the response message MUST be absent.</t>		<t>If a thisUpdate value was given, the PKI management entity < bcp14>MUST</bcp14> return the latest CRL available from the referenced source if this CRL is more recent than the given thisUpdate time. If no thisUpdate value was given, it <bcp14>MUST</bcp14> return the latest CRL available from the refe renced source. In all other cases, the infoValue in the response message <bcp14 >MUST</bcp14> be absent.</t>
	<t>The PKI management entity should treat a CRL distribution po int name as an internal pointer to identify a CRL that is directly available at the PKI management entity. It is not intended as a way to fetch an arbitrary CR L from an external location, as this location may be unavailable to that PKI man agement entity.</t>		<t>The PKI management entity should treat a CRL distribution po int name as an internal pointer to identify a CRL that is directly available at the PKI management entity. It is not intended as a way to fetch an arbitrary CR L from an external location, as this location may be unavailable to that PKI man agement entity.</t>
	<t>In addition to the prerequisites specified in <xref target="Prereq"		<t>In addition to the prerequisites specified in <xref target="Prereq"
	format="default"/>, the EE MUST know which CRL to request.</t>		format="default"/>, the EE <bcp14>MUST</bcp14> know which CRL to request.</t>
	<t>Note: If the EE does not want to request a specific CRL it MAY use		<t>Note: If the EE does not want to request a specific CRL, it <bcp14>
	instead a general message with OID id-it-currentCrl as specified in <xref target		MAY</bcp14> instead use a general message with OID id-it-currentCrl as specified
	="RFC4210" format="default">RFC&nbsp;4210 Section 5.3.19.6</xref>.</t>		in <xref target="RFC4210" format="default" sectionFormat="of" section="5.3.19.6
			"/>.</t>
	<t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t>		<t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t>
	<ol spacing="normal" type="%d">		<ol spacing="normal" type="1">
	<li>the infoType OID to use is id-it-crlStatusList in the req uest and id-it-crls in the response</li>		<li>the infoType OID to use is id-it-crlStatusList in the req uest and id-it-crls in the response</li>
	<li>the infoValue of the request MUST be present and contain		<li>the infoValue of the request <bcp14>MUST</bcp14> be prese
	a sequence of one CRLStatus structure</li>		nt and contain a sequence of one CRLStatus structure</li>
	<li>if present, the infoValue of the response MUST contain a		<li>if present, the infoValue of the response <bcp14>MUST</bc
	sequence of one CRL</li>		p14> contain a sequence of one CRL</li>
	</ol>		</ol>
	<t keepWithNext="true">Detailed Description of infoValue Field of genm		<t keepWithNext="true">Detailed Description of the infoValue Field of
	:</t>		genm:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	infoValue REQUIRED		infoValue REQUIRED
	-- MUST contain a sequence of one CRLStatus element		-- MUST contain a sequence of one CRLStatus element
	source REQUIRED		source REQUIRED
	-- MUST contain the dpn choice of type DistributionPointName if		-- MUST contain the dpn choice of type DistributionPointName if
	-- the CRL distribution point name is available		-- the CRL distribution point name is available
	-- Otherwise, MUST contain the issuer choice identifying the CA		-- Otherwise, MUST contain the issuer choice identifying the CA
	-- that issues the CRL. It MUST contain the issuer DN in the		-- that issues the CRL. It MUST contain the issuer DN in the
	-- directoryName field of a GeneralName element.		-- directoryName field of a GeneralName element.
	thisUpdate OPTIONAL		thisUpdate OPTIONAL
	-- MUST contain the thisUpdate field of the latest CRL the EE		-- MUST contain the thisUpdate field of the latest CRL the EE
	-- has got from the issuer specified in the given dpn or		-- has gotten from the issuer specified in the given dpn or
	-- issuer field		-- issuer field
	-- MUST be omitted if the EE does not have any instance of the		-- MUST be omitted if the EE does not have any instance of the
	-- requested CRL		-- requested CRL
	]]></artwork>		]]></sourcecode>
	<t keepWithNext="true">Detailed Description of infoValue Field of genp		<t keepWithNext="true">Detailed Description of the infoValue Field of
	:</t>		genp:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	infoValue OPTIONAL		infoValue OPTIONAL
	-- MUST be absent if no CRL to be returned is available		-- MUST be absent if no CRL to be returned is available
	-- MUST contain a sequence of one CRL update from the referenced		-- MUST contain a sequence of one CRL update from the referenced
	-- source, if a thisUpdate value was not given or a more recent		-- source if a thisUpdate value was not given or a more recent
	-- CRL is available		-- CRL is available
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	<section anchor="EE_Polling" numbered="true" toc="default">		<section anchor="EE_Polling" numbered="true" toc="default">
	<name>Handling Delayed Delivery</name>		<name>Handling Delayed Delivery</name>
	<t>This is a variant of all PKI management operations described in this d ocument. It is initiated in case a PKI management entity cannot respond to a re quest message in a timely manner, typically due to offline or asynchronous upstr eam communication, or due to delays in handling the request. The polling mechani sm has been specified in <xref target="RFC4210" format="default">RFC&nbsp;4210 S ection 5.3.22</xref> and updated by <xref target="I-D.ietf-lamps-cmp-updates" fo rmat="default"/>.</t>		<t>This is a variant of all PKI management operations described in this d ocument. It is initiated in case a PKI management entity cannot respond to a re quest message in a timely manner, typically due to offline or asynchronous upstr eam communication or due to delays in handling the request. The polling mechanis m has been specified in <xref target="RFC4210" format="default" sectionFormat="o f" section="5.3.22"/> and updated by <xref target="RFC9480" format="default"/>.< /t>
	<t>Depending on the PKI architecture, the entity initiating delayed deliv ery is not necessarily the PKI management entity directly addressed by the EE.</ t>		<t>Depending on the PKI architecture, the entity initiating delayed deliv ery is not necessarily the PKI management entity directly addressed by the EE.</ t>
	<t>When initiating delayed delivery of a message received from an EE, the		<t>When initiating delayed delivery of a message received from an EE, the
	PKI management entity MUST respond with a message including the status "waiting		PKI management entity <bcp14>MUST</bcp14> respond with a message including the
	". In response to an ir/cr/kur/p10cr message it must place the status "waiting"		status "waiting". In response to an ir/cr/kur/p10cr message, it must place the s
	in an ip/cp/kup message, otherwise in an error message. On receiving this resp		tatus "waiting" in an ip/cp/kup message and for responses to other request messa
	onse, the EE MUST store in its transaction context the senderNonce of the preced		ge types in an error message. On receiving this response, the EE <bcp14>MUST</b
	ing request message because this value will be needed for checking the recipNonc		cp14> store in its transaction context the senderNonce of the preceding request
	e of the final response to be received after polling. It sends a poll request wi		message because this value will be needed for checking the recipNonce of the fin
	th certReqId 0 if referring to the CertResponse element contained in the ip/cp/k		al response to be received after polling. It sends a poll request with certReqId
	up message, else -1 to refer to the whole message. In case the final response i		0 if referring to the CertResponse element contained in the ip/cp/kup message,
	s not yet available, the PKI management entity that initiated the delayed delive		else -1 to refer to the whole message. In case the final response is not yet av
	ry MUST answer with a poll response, with the same certReqId. The included chec		ailable, the PKI management entity that initiated the delayed delivery <bcp14>MU
	kAfter time value indicates the minimum number of seconds that should elapse bef		ST</bcp14> answer with a poll response with the same certReqId. The included ch
	ore the EE sends a new pollReq message to the PKI management entity. Polling ea		eckAfter time value indicates the minimum number of seconds that should elapse b
	rlier than indicated by the checkAfter value may increase the number of messages		efore the EE sends a new pollReq message to the PKI management entity. Polling
	roundtrips. This is repeated until a final response is available or any party		earlier than indicated by the checkAfter value may increase the number of messag
	involved gives up on the current PKI management operation, i.e., a timeout occur		e round trips. This is repeated until a final response is available or any part
	s.</t>		y involved gives up on the current PKI management operation, i.e., a timeout occ
	<t>When the PKI management entity that initiated delayed delivery can		urs.</t>
	provide the final response for the original request message of the EE, it MUST s		<t>When the PKI management entity that initiated delayed delivery can
	end this response to the EE. Using this response, the EE can continue the curre		provide the final response for the original request message of the EE, it <bcp14
	nt PKI management operation as usual.</t>		>MUST</bcp14> send this response to the EE. Using this response, the EE can con
			tinue the current PKI management operation as usual.</t>
	<t>No specific prerequisites apply in addition to those of the respective PKI management operation.</t>		<t>No specific prerequisites apply in addition to those of the respective PKI management operation.</t>
	<t keepWithNext="true">Message Flow:</t>		<t keepWithNext="true">Message Flow:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<artwork align="left" name="" type="" alt=""><![CDATA[
	Step# EE PKI management entity		Step# EE PKI management entity
	1 format request		1 format request
	message		message
	2 -> request ->		2 -> request ->
	3 handle or forward		3 handle or forward
	request		request
	4 format ip/cp/kup/error		4 format ip/cp/kup/error
	with status "waiting"		with status "waiting"
	response in case no		response in case no
	immediate final response		immediate final response
	is available,		is available
	5 <- ip/cp/kup/error <-		5 <- ip/cp/kup/error <-
	6 handle		6 handle
	ip/cp/kup/error		ip/cp/kup/error
	with status		with status
	"waiting"		"waiting"
	-------------------------- start polling --------------------------		-------------------------- start polling --------------------------
	7 format pollReq		7 format pollReq
	8 -> pollReq ->		8 -> pollReq ->
	skipping to change at line 1686 ¶		skipping to change at line 1664 ¶
	12 handle pollRep		12 handle pollRep
	13 let checkAfter		13 let checkAfter
	time elapse and		time elapse and
	continue with		continue with
	step 7		step 7
	----------------- end polling, continue as usual ------------------		----------------- end polling, continue as usual ------------------
	14 format or receive		14 format or receive
	final response on		final response on
	original request		the original request
	15 <- response <-		15 <- response <-
	16 handle final		16 handle final
	response		response
	]]></artwork>		]]></artwork>
	<t keepWithNext="true">Detailed Message Description:</t>		<t keepWithNext="true">Detailed Message Description:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	Response with Status "waiting" -- ip/cp/kup/error		Response with Status "waiting" -- ip/cp/kup/error
	Field Value		Field Value
	header		header
	-- As described in Section 3.1		-- As described in Section 3.1
	body		body
	-- As described for the respective PKI management operation, with		-- As described for the respective PKI management operation, with
	-- the following adaptations:		-- the following adaptations:
	status REQUIRED -- in case of ip/cp/kup		status REQUIRED -- in case of ip/cp/kup
	pKIStatusInfo REQUIRED -- in case of error response		pKIStatusInfo REQUIRED -- in case of error response
	-- PKIStatusInfo structure MUST be present		-- PKIStatusInfo structure MUST be present
	status REQUIRED		status REQUIRED
	-- MUST be status "waiting"		-- MUST be status "waiting"
	statusString OPTIONAL		statusString OPTIONAL
	-- MAY be any human-readable text for debugging, logging or to		-- MAY be any human-readable text for debugging, for logging, or
	-- display in a GUI		-- to display in a GUI
	failInfo PROHIBITED		failInfo PROHIBITED
	protection REQUIRED		protection REQUIRED
	-- As described in Section 3.2		-- As described in Section 3.2
	extraCerts OPTIONAL		extraCerts OPTIONAL
	-- As described in Section 3.3		-- As described in Section 3.3
	Polling Request -- pollReq		Polling Request -- pollReq
	skipping to change at line 1761 ¶		skipping to change at line 1739 ¶
	body		body
	-- The message indicates the delay after which the EE SHOULD		-- The message indicates the delay after which the EE SHOULD
	-- send another pollReq message for this transaction		-- send another pollReq message for this transaction
	pollRep REQUIRED		pollRep REQUIRED
	certReqId REQUIRED		certReqId REQUIRED
	-- MUST be 0 if referring to a CertResponse element, else -1		-- MUST be 0 if referring to a CertResponse element, else -1
	checkAfter REQUIRED		checkAfter REQUIRED
	-- MUST be the time in seconds to elapse before a new pollReq		-- MUST be the time in seconds to elapse before a new pollReq
	-- should be sent		-- should be sent
	reason OPTIONAL		reason OPTIONAL
	-- MAY be any human-readable text for debugging, logging or to		-- MAY be any human-readable text for debugging, for logging, or
	-- display in a GUI		-- to display in a GUI
	protection REQUIRED		protection REQUIRED
	-- 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 CMP protection certificate from the first		-- cached the CMP protection certificate from the first
	-- response message of the PKI management operation		-- response message of 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
	-- request as described in the respective PKI management		-- request, as described in the respective PKI management
	-- operation		-- operation
	protection REQUIRED		protection REQUIRED
	-- MUST be as described for the response message of the		-- MUST be as described for the response message of the
	-- respective PKI management operation		-- respective PKI management operation
	extraCerts REQUIRED		extraCerts REQUIRED
	-- MUST be as described for the response message of the		-- MUST be as described for the response message of the
	-- respective PKI management operation		-- respective PKI management operation
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	<section anchor="RA_UseCases" numbered="true" toc="default">		<section anchor="RA_UseCases" numbered="true" toc="default">
	<name>PKI Management Entity Operations</name>		<name>PKI Management Entity Operations</name>
	<t>This section focuses on request processing by a PKI management entity. Depending on the network and PKI solution design, this can be an RA or CA, any of which may include protocol conversion or central key generation (i.e., acting as a KGA).</t>		<t>This section focuses on request processing by a PKI management entity. Depending on the network and PKI solution design, this can be an RA or CA, any of which may include protocol conversion or central key generation (i.e., acting as a KGA).</t>
	<t>A PKI management entity may directly respond to request messages from d ownstream and report errors. In case the PKI management entity is an RA it typic ally forwards the received request messages upstream after checking them and for wards respective response messages downstream. Besides responding to messages o r forwarding them, a PKI management entity may request or revoke certificates on behalf of EEs. A PKI management entity may also need to manage its own certific ates and thus act as an EE using the PKI management operations specified in <xre f target="EE_UseCases" format="default"/>.</t>		<t>A PKI management entity may directly respond to request messages from d ownstream and report errors. In case the PKI management entity is an RA, it typi cally forwards the received request messages upstream after checking them and fo rwards respective response messages downstream. Besides responding to messages or forwarding them, a PKI management entity may request or revoke certificates o n behalf of EEs. A PKI management entity may also need to manage its own certifi cates and thus act as an EE using the PKI management operations specified in <xr ef target="EE_UseCases" format="default"/>.</t>
	<section anchor="RA_response" numbered="true" toc="default">		<section anchor="RA_response" numbered="true" toc="default">
	<name>Responding to Requests</name>		<name>Responding to Requests</name>
	<t>The PKI management entity terminating the PKI management operation at		<t>The PKI management entity terminating the PKI management operation at
	CMP level MUST respond to all received requests by returning a related CMP resp		CMP level <bcp14>MUST</bcp14> respond to all received requests by returning a r
	onse message or an error. Any intermediate PKI management entity MAY respond dep		elated CMP response message or an error. Any intermediate PKI management entity
	ending on the PKI configuration and policy.</t>		<bcp14>MAY</bcp14> respond, depending on the PKI configuration and policy.</t>
	<t>In addition to the checks described in <xref target="Validation" form		<t>In addition to the checks described in <xref target="Validation" form
	at="default"/>, the responding PKI management entity MUST check that a request t		at="default"/>, the responding PKI management entity <bcp14>MUST</bcp14> check t
	hat initiates a new PKI management operation does not use a transactionID that i		hat a request that initiates a new PKI management operation does not use a trans
	s currently in use. The failInfo bit value to use is transactionIdInUse as desc		actionID that is currently in use. The failInfo bit value to use is transaction
	ribed in <xref target="Error_reporting" format="default"/>. If any of these ver		IdInUse as described in <xref target="Error_reporting" format="default"/>. If a
	ification steps or any of the essential checks described in <xref target="Valida		ny of these verification steps or any of the essential checks described in <xref
	tion" format="default"/> and in the following subsections fails, the PKI managem		target="Validation" format="default"/> and in the following subsections fails,
	ent entity MUST proceed as described in <xref target="Error" format="default"/>.		the PKI management entity <bcp14>MUST</bcp14> proceed as described in <xref targ
	</t>		et="Error" format="default"/>.</t>
	<t>The responding PKI management entity MUST copy the sender field of th		<t>The responding PKI management entity <bcp14>MUST</bcp14> copy the sen
	e request to the recipient field of the response, MUST copy the senderNonce of t		der field of the request to the recipient field of the response, <bcp14>MUST</bc
	he request to the recipNonce of the response, and MUST use the same transactionI		p14> copy the senderNonce of the request to the recipNonce of the response, and
	D for the response.</t>		<bcp14>MUST</bcp14> use the same transactionID for the response.</t>
	<section anchor="RA_response_enrollment" numbered="true" toc="def ault">		<section anchor="RA_response_enrollment" numbered="true" toc="def ault">
	<name>Responding to a Certificate Request</name>		<name>Responding to a Certificate Request</name>
	<t>An ir/cr/kur/p10cr message is used to request a certif		<t>An ir/cr/kur/p10cr message is used to request a certif
	icate as described in <xref target="EE_request" format="default"/>. The respondi		icate as described in <xref target="EE_request" format="default"/>. The respondi
	ng PKI management entity MUST proceed as follows unless it initiates delayed del		ng PKI management entity <bcp14>MUST</bcp14> proceed as follows unless it initia
	ivery as described in <xref target="RA_response_polling" format="default"/>.</t>		tes delayed delivery as described in <xref target="RA_response_polling" format="
	<t>The PKI management entity MUST check the message body		default"/>.</t>
	according to the applicable requirements from <xref target="EE_request" format="		<t>The PKI management entity <bcp14>MUST</bcp14> check th
	default"/>. Possible failInfo bit values used for error reporting in case a chec		e message body according to the applicable requirements from <xref target="EE_re
	k failed include badCertId and badCertTemplate. It MUST verify the presence and		quest" format="default"/>. Possible failInfo bit values used for error reporting
	value of the proof-of-possession (failInfo bit: badPOP), unless central key gene		in case a check failed include badCertId and badCertTemplate. It <bcp14>MUST</b
	ration is requested. In case the special POP value "raVerified" is given, it sho		cp14> verify the presence and value of the proof-of-possession (failInfo bit: ba
	uld check that the request message was signed using a certificate containing the		dPOP) unless central key generation is requested. If a signature-based proof-of-
	cmcRA extended key usage (failInfo bit: notAuthorized). The PKI management enti		possession is present, the PKI management entity <bcp14>MUST</bcp14> verify, bas
	ty should also perform any further checks on the certTemplate contents (failInfo		ed on local PKI policy, that the subject name in the certTemplate identifies the
	: badCertTemplate) according to any applicable PKI policy and certificate profil		same entity as the subject name in the CMP protection certificate or matches th
	e.</t>		e identifier used with MAC-based protection. In case this verification fails, t
	<t>If the requested certificate is available, the PKI man		he message <bcp14>MUST</bcp14> have been protected by an authorized PKI manageme
	agement entity MUST respond with a positive ip/cp/kup message as described in <x		nt entity (failInfo bit: notAuthorized). If the special POP value "raVerified"
	ref target="EE_request" format="default"/>.</t>		is given, the PKI management entity should check that the request message was si
	<t>Note: If central key generation is performed by the re		gned using a certificate containing the cmcRA extended key usage (failInfo bit:
	sponding PKI management entity, the responding PKI management entity MUST includ		notAuthorized). The PKI management entity should also perform any further checks
	e the private key in encrypted form in the response as specified in <xref target		on the certTemplate contents (failInfo: badCertTemplate) according to any appli
	="EE_centralKeyGeneration" format="default"/>.</t>		cable PKI policy and certificate profile.</t>
	<t keepWithNext="true">The prerequisites of the respective PKI manag		<t>If the requested certificate is available, the PKI man
	ement operation as specified in <xref target="EE_request" format="default"/> app		agement entity <bcp14>MUST</bcp14> respond with a positive ip/cp/kup message as
	ly.</t>		described in <xref target="EE_request" format="default"/>.</t>
	<t>If the EE requested omission of the certConf message,		<t>Note: If central key generation is performed by the re
	the PKI management entity MUST handle it as described in <xref target="EE_newPKI		sponding PKI management entity, the responding PKI management entity <bcp14>MUST
	" format="default"/>. Therefore, it MAY grant this by including the implicitCon		</bcp14> include the private key in encrypted form in the response as specified
	firm generalInfo field or include the confirmWaitTime field in the response head		in <xref target="EE_centralKeyGeneration" format="default"/>.</t>
	er.</t>		<t keepWithNext="true">The prerequisites of the respective PKI manag
			ement operation specified in <xref target="EE_request" format="default"/> apply.
			</t>
			<t>If the EE requested omission of the certConf message,
			the PKI management entity <bcp14>MUST</bcp14> handle it as described in <xref ta
			rget="EE_newPKI" format="default"/>. Therefore, it <bcp14>MAY</bcp14> grant thi
			s by including the implicitConfirm generalInfo field or including the confirmWai
			tTime field in the response header.</t>
	</section>		</section>
	<section anchor="RA_response_confirmation" numbered="true" toc="d efault">		<section anchor="RA_response_confirmation" numbered="true" toc="d efault">
	<name>Responding to a Confirmation Message</name>		<name>Responding to a Confirmation Message</name>
	<t>A PKI management entity MUST handle a certConf message		<t>A PKI management entity <bcp14>MUST</bcp14> handle a c
	if it has responded before with a positive ip/cp/kup message not granting impli		ertConf message if it has responded before with a positive ip/cp/kup message not
	cit confirmation. It should check the message body according to the requirement		granting implicit confirmation. It should check the message body according to
	s given in <xref target="EE_newPKI" format="default"/> (failInfo bit: badCertId)		the requirements given in <xref target="EE_newPKI" format="default"/> (failInfo
	and MUST react as described there.</t>		bit: badCertId) and <bcp14>MUST</bcp14> react as described there.</t>
	<t>The prerequisites of the respective PKI management ope		<t>The prerequisites of the respective PKI management ope
	ration as specified in <xref target="EE_request" format="default"/> apply.</t>		ration specified in <xref target="EE_request" format="default"/> apply.</t>
	</section>		</section>
	<section anchor="RA_response_revocation" numbered="true" toc="def ault">		<section anchor="RA_response_revocation" numbered="true" toc="def ault">
	<name>Responding to a Revocation Request</name>		<name>Responding to a Revocation Request</name>
	<t>An rr message is used to request revocation of a certi ficate. The responding PKI management entity should check the message body accor ding to the requirements in <xref target="EE_Revoke" format="default"/>. It MUST make sure that the referenced certificate exists (failInfo bit: badCertId), has been issued by the addressed CA, and is not already expired or revoked (failInf o bit: certRevoked). On success it MUST respond with a positive rp message as d escribed in <xref target="EE_Revoke" format="default"/>.</t>		<t>An rr message is used to request revocation of a certi ficate. The responding PKI management entity should check the message body accor ding to the requirements in <xref target="EE_Revoke" format="default"/>. It <bcp 14>MUST</bcp14> make sure that the referenced certificate exists (failInfo bit: badCertId), has been issued by the addressed CA, and is not already expired or r evoked (failInfo bit: certRevoked). On success, it <bcp14>MUST</bcp14> respond with a positive rp message, as described in <xref target="EE_Revoke" format="def ault"/>.</t>
	<t>No specific prerequisites apply in addition to those s pecified in <xref target="Prereq" format="default"/>.</t>		<t>No specific prerequisites apply in addition to those s pecified in <xref target="Prereq" format="default"/>.</t>
	</section>		</section>
	<section anchor="RA_response_support" numbered="true" toc="defaul t">		<section anchor="RA_response_support" numbered="true" toc="defaul t">
	<name>Responding to a Support Message</name>		<name>Responding to a Support Message</name>
	<t>A genm message is used to retrieve extra content. The responding PKI management entity should check the message body according to the applicable requirements in <xref target="EE_GeneralMessage" format="default"/> a nd perform any further checks depending on the PKI policy. On success it MUST r espond with a genp message as described there.</t>		<t>A genm message is used to retrieve extra content. The responding PKI management entity should check the message body according to the applicable requirements in <xref target="EE_GeneralMessage" format="default"/> a nd perform any further checks depending on the PKI policy. On success, it <bcp1 4>MUST</bcp14> respond with a genp message as described there.</t>
	<t>Note: The responding PKI management entity may generat e the response from scratch or reuse the contents of previous responses. Theref ore, it may be worth caching the body of the response message as long as the con tained information is valid and current, such that further requests for the same contents can be answered immediately.</t>		<t>Note: The responding PKI management entity may generat e the response from scratch or reuse the contents of previous responses. Theref ore, it may be worth caching the body of the response message as long as the con tained information is valid and current, such that further requests for the same contents can be answered immediately.</t>
	<t>No specific prerequisites apply in addition to those s pecified in <xref target="Prereq" format="default"/>.</t>		<t>No specific prerequisites apply in addition to those s pecified in <xref target="Prereq" format="default"/>.</t>
	</section>		</section>
	<section anchor="RA_response_polling" numbered="true" toc="default">		<section anchor="RA_response_polling" numbered="true" toc="default">
	<name>Initiating Delayed Delivery</name>		<name>Initiating Delayed Delivery</name>
	<t>This functional extension can be used by a PKI management entity in		<t>This functional extension can be used by a PKI management entity in
	case the response to a request takes longer than usual. In this case the PKI m		case the response to a request takes longer than usual. In this case, the PKI
	anagement entity should completely validate the request as usual and then start		management entity should completely validate the request as usual and then start
	processing the request itself or forward it further upstream as soon as possible		processing the request itself or forward it further upstream as soon as possibl
	. In the meantime, it MUST respond with an ip/cp/kup/error message including th		e. In the meantime, it <bcp14>MUST</bcp14> respond with an ip/cp/kup/error mess
	e status "waiting" and handle subsequent polling as described in <xref target="E		age including the status "waiting" and handle subsequent polling as described in
	E_Polling" format="default"/>.</t>		<xref target="EE_Polling" format="default"/>.</t>
	<t>Typically, as stated in <xref target="RA_Replace" format="default"/		<t>Typically, as stated in <xref target="RA_Replace" format="default"/
	>, an intermediate PKI management entity should not change the sender and recipi		>, an intermediate PKI management entity should not change the sender and recipi
	ent nonces even in case it modifies a request or a response message. In the spe		ent nonces even in case it modifies a request or a response message. In the spe
	cial case of delayed delivery initiated by an intermediate PKI management entity		cial case of delayed delivery initiated by an intermediate PKI management entity
	, there is an exception. Between the EE and this PKI management entity, pollReq		, there is an exception. Between the EE and this PKI management entity, pollReq
	and pollRep messages are exchanged handling the nonces as usual. Yet when the		and pollRep messages are exchanged handling the nonces as usual. Yet when the
	final response from upstream has arrived at the PKI management entity, this resp		final response from upstream has arrived at the PKI management entity, this resp
	onse contains the recipNonce copied (as usual) from the senderNonce in the origi		onse contains the recipNonce copied (as usual) from the senderNonce in the origi
	nal request message. The PKI management entity that initiated the delayed deliv		nal request message. The PKI management entity that initiated the delayed deliv
	ery MAY replace the recipNonce in the response message with the senderNonce of t		ery <bcp14>MAY</bcp14> replace the recipNonce in the response message with the s
	he last received pollReq because the downstream entities, including the EE, migh		enderNonce of the last received pollReq because the downstream entities, includi
	t expect it in this way. Yet the check specified in Section 3.5 allows to alter		ng the EE, might expect it in this way. Yet the check specified in <xref target
	natively use the senderNonce of the original request.</t>		="Validation"/> allows alternate use of the senderNonce of the original request.
			</t>
	<t>No specific prerequisites apply in addition to those of the respective PKI management operation.</t>		<t>No specific prerequisites apply in addition to those of the respective PKI management operation.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="RA_forwarde_messages" numbered="true" toc="default">		<section anchor="RA_forwarde_messages" numbered="true" toc="default">
	<name>Forwarding Messages</name>		<name>Forwarding Messages</name>
	<t>In case the PKI solution consists of intermediate PKI management enti		<t>In case the PKI solution consists of intermediate PKI management enti
	ties (i.e., LRA or RA), each CMP request message coming from an EE or any other		ties (i.e., LRA or RA), each CMP request message coming from an EE or any other
	downstream PKI management entity MUST either be forwarded to the next (upstream)		downstream PKI management entity <bcp14>MUST</bcp14> either be forwarded to the
	PKI management entity as described in this section or answered as described in		next (upstream) PKI management entity as described in this section, or answered
	<xref target="RA_response" format="default"/>. Any received response message or		as described in <xref target="RA_response" format="default"/>. Any received resp
	a locally generated error message MUST be forwarded to the next (downstream) PKI		onse message or a locally generated error message <bcp14>MUST</bcp14> be forward
	entity.</t>		ed to the next (downstream) PKI entity.</t>
	<t>In addition to the checks described in <xref target="Validation" form		<t>In addition to the checks described in <xref target="Validation" form
	at="default"/>, the forwarding PKI management entity MAY verify the proof-of-pos		at="default"/>, the forwarding PKI management entity <bcp14>MAY</bcp14> verify t
	session for ir/cr/kur/p10cr messages. If one of these verification procedures f		he proof-of-possession for ir/cr/kur/p10cr messages. If one of these verificati
	ails, the RA proceeds as described in <xref target="Error" format="default"/>.</		on procedures fails, the RA proceeds as described in <xref target="Error" format
	t>		="default"/>.</t>
	<t>A PKI management entity SHOULD NOT change the received message unless		<t>A PKI management entity <bcp14>SHOULD NOT</bcp14> change the received
	its role in the PKI system requires it. This is because changes to the message		message unless its role in the PKI system requires it. This is because changes
	header or body imply re-protection. Changes to the protection breaks end-to-end		to the message header or body imply reprotection. Changes to the protection bre
	authentication of the message source. Changes to the certificate template in a		aks end-to-end authentication of the message source. Changes to the certificate
	certificate request breaks proof-of-possession. More details are available in t		template in a certificate request breaks proof-of-possession. More details are
	he following sub-sections. Concrete PKI system specifications may define in mor		available in the following subsections. Concrete PKI system specifications may
	e detail when to do so.</t>		define when to do so in more detail.</t>
	<t>This is particularly relevant in the upstream communication of a requ est message.</t>		<t>This is particularly relevant in the upstream communication of a requ est message.</t>
	<t keepWithNext="true">Each forwarding PKI management entity has one or more functionalities. It may</t>		<t keepWithNext="true">Each forwarding PKI management entity has one or more functionalities. It may:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>verify the identities of EEs and make authorization decisions for certification request processing based on local PKI policy,</li>		<li>verify the identities of EEs and make authorization decisions for certification request processing based on local PKI policy,</li>
	<li>add or modify fields of certificate request messages,</li>		<li>add or modify fields of certificate request messages,</li>
	<li>replace a MAC-based protection by a signature-based protection tha t can be verified also further upstream, and vice versa,</li>		<li>replace a MAC-based protection with a signature-based protection t hat can also be verified further upstream and vice versa,</li>
	<li>double-check if the messages transferred back and forth are proper ly protected and well-formed,</li>		<li>double-check if the messages transferred back and forth are proper ly protected and well-formed,</li>
	<li>provide an authentic indication that it has performed all required checks,</li>		<li>provide an authentic indication that it has performed all required checks,</li>
	<li>initiate a delayed delivery due to delays transferring messages or handling requests, or</li>		<li>initiate a delayed delivery due to delays transferring messages or handling requests, or</li>
	<li>collect messages from multiple RAs and forward them jointly.</li>		<li>collect messages from multiple RAs and forward them jointly.</li>
	</ul>		</ul>
	<t>Note: PKI management entities forwarding messages may also sto re data from a message in a database for later usage or audit purposes. They may also support traversal of a network boundary.</t>		<t>Note: PKI management entities forwarding messages may also sto re data from a message in a database for later usage or audit purposes. They may also support traversal of a network boundary.</t>
	<t keepWithNext="true">The decision if a message should be forwarded</t>		<t keepWithNext="true">The decision if a message should be forwarded is: </t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>unchanged with the original protection,</li>		<li>unchanged with the original protection,</li>
	<li>unchanged with an additional protection, or</li>		<li>unchanged with an additional protection, or</li>
	<li>changed with an additional protection</li>		<li>changed with an additional protection</li>
	</ul>		</ul>
	<t>depends on the PKI solution design and the associated security policy		<t>depending on the PKI solution design and the associated security poli
	(<xref target="RFC3647" format="default">CP/CPS</xref>).</t>		cy, e.g., as defined in the <xref target="RFC3647" format="default">certificate
	<t keepWithNext="true">A PKI management entity SHOULD add or MAY replace		policy (CP) / certification practice statement (CPS) documents</xref>.</t>
	a protection of a message if it</t>		<t keepWithNext="true">A PKI management entity <bcp14>SHOULD</bcp14> add
			or <bcp14>MAY</bcp14> replace a protection of a message if it</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>needs to securely indicate that it has done checks or validations on the message to one of the next (upstream) PKI management entity or</li>		<li>needs to securely indicate that it has done checks or validations on the message to one of the next (upstream) PKI management entities or</li>
	<li>needs to protect the message using a key and certificate from a di fferent PKI.</li>		<li>needs to protect the message using a key and certificate from a di fferent PKI.</li>
	</ul>		</ul>
	<t>If remaining end-to-end message authentication is required, an		<t>If retaining end-to-end message authentication is required, an
	additional protection SHALL be added instead of replacing the original protecti		additional protection <bcp14>SHALL</bcp14> be added instead of replacing the or
	on.</t>		iginal protection.</t>
	<t keepWithNext="true">A PKI management entity MUST replace a protection		<t keepWithNext="true">A PKI management entity <bcp14>MUST</bcp14> repla
	of a message if it</t>		ce a protection of a message if it</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>performs changes to the header or the body of the message or</li>		<li>performs changes to the header or the body of the message or</li>
	<li>needs to convert from or to a MAC-based protection.</li>		<li>needs to convert from or to a MAC-based protection.</li>
	</ul>		</ul>
	<t>This is particularly relevant in the upstream communication of certif icate request messages.</t>		<t>This is particularly relevant in the upstream communication of certif icate request messages.</t>
	<t>Note that the message protection covers only the header and the body and not the extraCerts. The PKI management entity MAY change the extraCerts in any of the following message adaptations, e.g., to sort, add, or delete certific ates to support subsequent PKI entities. This may be particularly helpful to au gment upstream messages with additional certificates or to reduce the number of certificates in downstream messages when forwarding to constrained devices.</t>		<t>Note that the message protection covers only the header and the body and not the extraCerts. The PKI management entity <bcp14>MAY</bcp14> change the extraCerts in any of the following message adaptations, e.g., to sort, add, or delete certificates to support subsequent PKI entities. This may be particularl y helpful to augment upstream messages with additional certificates or to reduce the number of certificates in downstream messages when forwarding to constraine d devices.</t>
	<section anchor="RA_noChange" numbered="true" toc="default">		<section anchor="RA_noChange" numbered="true" toc="default">
	<name>Not Changing Protection</name>		<name>Not Changing Protection</name>
	<t>This variant means that a PKI management entity forwards a CMP mess		<t>This variant means that a PKI management entity forwards a CMP mess
	age without changing the header, body, or protection. In this case the PKI mana		age without changing the header, body, or protection. In this case, the PKI man
	gement entity acts more like a proxy, e.g., on a network boundary, implementing		agement entity acts more like a proxy, e.g., on a network boundary, implementing
	no specific RA-like security functionality that requires an authentic indication		no specific RA-like security functionality that requires an authentic indicatio
	to the PKI. Still the PKI management entity might implement checks that result		n to the PKI. Still, the PKI management entity might implement checks that resul
	in refusing to forward the request message and instead responding as specified i		t in refusing to forward the request message and instead responding as specified
	n <xref target="Error" format="default"/>.</t>		in <xref target="Error" format="default"/>.</t>
	<t>This variant of forwarding a message or the one described in <xref		<t>This variant of forwarding a message or the one described in <xref
	target="RA_AddSingel" format="default"/> MUST be used for kur messages and for c		target="RA_AddSingel" format="default"/> <bcp14>MUST</bcp14> be used for kur mes
	entral key generation. </t>		sages and for central key generation. </t>
	<t>No specific prerequisites apply in addition to those specifi ed in <xref target="Prereq" format="default"/>.</t>		<t>No specific prerequisites apply in addition to those specifi ed in <xref target="Prereq" format="default"/>.</t>
	</section>		</section>
	<section anchor="RA_Add" numbered="true" toc="default">		<section anchor="RA_Add" numbered="true" toc="default">
	<name>Adding Protection and Batching of Messages</name>		<name>Adding Protection and Batching of Messages</name>
	<t>This variant of forwarding a message means that a PKI management en tity adds another protection to PKI management messages before forwarding them.< /t>		<t>This variant of forwarding a message means that a PKI management en tity adds another protection to PKI management messages before forwarding them.< /t>
	<t>The nested message is a PKI management message containing a PKIMess		<t>The nested message is a PKI management message containing a PKIMess
	ages sequence as its body containing one or more CMP messages.</t>		ages sequence as its body, containing one or more CMP messages.</t>
	<t>As specified in the updated <xref target="RFC4210" format="default"		<t>As specified in the updated <xref target="RFC4210" format="default"
	>Section 5.1.3.4 of RFC&nbsp;4210</xref> (see also <xref target="I-D.ietf-lamps-		sectionFormat="of" section="5.1.3.4"/> (also see <xref target="RFC9480" format=
	cmp-updates" format="default">CMP Updates Section 2.6</xref>) there are various		"default" sectionFormat="of" section="2.6">CMP Updates</xref>), there are variou
	use cases for adding another protection by a PKI management entity. Specific pro		s use cases for adding another protection by a PKI management entity. Specific p
	cedures are described in more detail in the following sections.</t>		rocedures are described in more detail in the following sections.</t>
	<t keepWithNext="true">Detailed Message Description:</t>		<t keepWithNext="true">Detailed Message Description:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	Nested Message - nested		Nested Message - nested
	Field Value		Field Value
	header		header
	-- As described in Section 3.1		-- As described in Section 3.1
	body		body
	-- Container to provide additional protection to original		-- Container to provide additional protection to original
	-- messages and to bundle request messages or alternatively		-- messages and to bundle request messages or alternatively
	-- response messages		-- response messages
	PKIMessages REQUIRED		PKIMessages REQUIRED
	-- MUST be a sequence of one or more CMP messages		-- MUST be a sequence of one or more CMP messages
	protection REQUIRED		protection REQUIRED
	-- As described in Section 3.2 using the CMP protection key of		-- As described in Section 3.2, using the CMP protection key of
	-- the PKI management entity		-- the PKI management entity
	extraCerts REQUIRED		extraCerts REQUIRED
	-- As described in Section 3.3		-- As described in Section 3.3
	]]></artwork>		]]></sourcecode>
	<section anchor="RA_AddSingel" numbered="true" toc="default">		<section anchor="RA_AddSingel" numbered="true" toc="default">
	<name>Adding Protection to a Request Message</name>		<name>Adding Protection to a Request Message</name>
	<t>This variant means that a PKI management entity forwards a CMP me ssage while authentically indicating successful validation and approval of a req uest message without changing the original message authentication.</t>		<t>This variant means that a PKI management entity forwards a CMP me ssage while authentically indicating successful validation and approval of a req uest message without changing the original message authentication.</t>
	<t>By adding a protection using its own CMP protection ke		<t>By adding a protection using its own CMP protection ke
	y the PKI management entity provides a proof of verifying and approving the mess		y, the PKI management entity provides a proof of verifying and approving the mes
	age as described above. Thus, the PKI management entity acts as an actual Regist		sage, as described above. Thus, the PKI management entity acts as an actual regi
	ration Authority (RA), which implements important security functionality of the		stration authority (RA), which implements important security functionality of th
	PKI. Applying an additional protection is specifically relevant when forwarding		e PKI. Applying an additional protection is specifically relevant when forwardin
	a message that requests a certificate update or central key generation. This is		g a message that requests a certificate update or central key generation. This
	because the original protection of the EE needs to be preserved while adding an		is because the original protection of the EE needs to be preserved while adding
	indication of approval by the PKI management entity.</t>		an indication of approval by the PKI management entity.</t>
	<t>The PKI management entity wrapping the original request message i		<t>The PKI management entity wrapping the original request message i
	n a nested message structure MUST copy the values of the recipient, recipNonce,		n a nested message structure <bcp14>MUST</bcp14> copy the values of the senderNo
	and transactionID header fields of the original message to the respective header		nce and transactionID header fields of the original message to the respective he
	fields of the nested message and apply signature-based protection. The additio		ader fields of the nested message and apply signature-based protection. The add
	nal signature serves as proof of verification and authorization by this PKI mana		itional signature serves as proof of verification and authorization by this PKI
	gement entity.</t>		management entity.</t>
	<t>The PKI management entity receiving such a nested message that co		<t>The PKI management entity receiving such a nested message that co
	ntains a single request message MUST validate the additional protection signatur		ntains a single request message <bcp14>MUST</bcp14> validate the additional prot
	e on the nested message and check the authorization for the approval it implies.		ection signature on the nested message and check the authorization for the appro
	</t>		val it implies. Other fields in the header of the nested message can be ignored
			.</t>
	<t>The PKI management entity responding to the request co ntained in the nested message sends the response message as described in <xref t arget="RA_response" format="default"/>, without wrapping it in a nested message. </t>		<t>The PKI management entity responding to the request co ntained in the nested message sends the response message as described in <xref t arget="RA_response" format="default"/>, without wrapping it in a nested message. </t>
			<t>Note: When responding to the inner request message, it must be considered that the verification and approval activity described in thi s section has already been performed by the PKI management entity that protected the nested message.</t>
	<t>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 on e used in the included message.</t>		<t>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 on e used in the included message.</t>
	<t keepWithNext="true">Specific prerequisites augmenting the prerequ isites in <xref target="Prereq" format="default"/>:</t>		<t keepWithNext="true">The specific prerequisite augmenting the prer equisites in <xref target="Prereq" format="default"/> is as follows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The PKI management entity MUST be able to validate the respect ive request and have the authorization to perform approval of the request accord ing to the PKI policies.</li>		<li>The PKI management entity <bcp14>MUST</bcp14> be able to valid ate the respective request and have the authorization to perform approval of the request according to the PKI policies.</li>
	</ul>		</ul>
	<t keepWithNext="true">Message Flow:</t>		<t keepWithNext="true">Message Flow:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<artwork align="left" name="" type="" alt=""><![CDATA[
	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
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="RA_AddBatch" numbered="true" toc="default">		<section anchor="RA_AddBatch" numbered="true" toc="default">
	<name>Batching Messages</name>		<name>Batching Messages</name>
	<t>A PKI management entity MAY bundle any number of PKI management m		<t>A PKI management entity <bcp14>MAY</bcp14> bundle any number of P
	essages for batch processing or to transfer a bulk of PKI management messages us		KI management messages for batch processing or to transfer a bulk of PKI managem
	ing the nested message structure. In this use case, nested messages are used bo		ent messages using the nested message structure. In this use case, nested messa
	th on the upstream interface for transferring request messages towards the next		ges are used both on the upstream interface for transferring request messages to
	PKI management entity and on its downstream interface for response messages.</t>		wards the next PKI management entity and on its downstream interface for respons
	<t>This PKI management operation is typically used on the interface		e messages.</t>
	between an LRA and an RA to bundle several messages for offline or asynchronous		<t>This PKI management operation is typically used on the interface
	delivery. In this case the LRA needs to initiate delayed delivery as described		between an LRA and an RA to bundle several messages for offline or asynchronous
	in <xref target="RA_response_polling" format="default"/>. If the RA needs differ		delivery. In this case, the LRA needs to initiate delayed delivery, as describe
	ent routing information per nested PKI management message provided upstream, a s		d in <xref target="RA_response_polling" format="default"/>. If the RA needs diff
	uitable mechanism may need to be implemented to ensure that the downstream deliv		erent routing information per the nested PKI management message provided upstrea
	ery of the response is done to the right requester. Since this mechanism strong		m, a suitable mechanism may need to be implemented to ensure that the downstream
	ly depends on the requirements of the target architecture, it is out of scope of		delivery of the response is done to the right requester. Since this mechanism
	this document.</t>		strongly depends on the requirements of the target architecture, it is out of sc
	<t>A nested message containing requests is generated locally at the		ope of this document.</t>
	PKI management entity. For the upstream nested message, the PKI management enti		<t>A nested message containing requests is generated locally at the
	ty acts as a protocol end point and therefore a fresh transactionID and a fresh		PKI management entity. For the upstream nested message, the PKI management enti
	senderNonce MUST be used in the header of the nested message. An upstream nested		ty acts as a protocol endpoint; therefore, a fresh transactionID and a fresh sen
	message may contain request messages, e.g., ir, cr, p10cr, kur, pollReq, certCo		derNonce <bcp14>MUST</bcp14> be used in the header of the nested message. An ups
	nf, rr, or genm. While building the upstream nested message the PKI management		tream nested message may contain request messages, e.g., ir, cr, p10cr, kur, pol
	entity must store the sender, transactionID, and senderNonce fields of all bundl		lReq, certConf, rr, or genm. While building the upstream nested message, the PK
	ed messages together with the transactionID of the upstream nested message.</t>		I management entity must store the sender, transactionID, and senderNonce fields
	<t>Such an upstream nested message is sent to the next PKI managemen		of all bundled messages together with the transactionID of the upstream nested
	t entity. The upstream PKI management entity that unbundles it MUST handle each		message.</t>
	of the included request messages as usual. It MUST answer with a downstream nes		<t>Such an upstream nested message is sent to the next PKI managemen
	ted message. This downstream nested message MUST use the transactionID of the u		t entity. The upstream PKI management entity that unbundles it <bcp14>MUST</bcp1
	pstream nested message and return the senderNonce of the upstream nested message		4> handle each of the included request messages as usual. It <bcp14>MUST</bcp14
	as the recipNonce of the downstream nested message. The downstream nested mess		> answer with a downstream nested message. This downstream nested message <bcp1
	age MUST bundle all available individual response messages (e.g., ip, cp, kup, p		4>MUST</bcp14> use the transactionID of the upstream nested message and return t
	ollRep, pkiConf, rp, genp, error) for all original request messages of the upstr		he senderNonce of the upstream nested message as the recipNonce of the downstrea
	eam nested message. While unbundling the downstream nested message, the former		m nested message. The downstream nested message <bcp14>MUST</bcp14> bundle all
	PKI management entity must determine lost and unexpected responses based on the		available individual response messages (e.g., ip, cp, kup, pollRep, pkiConf, rp,
	previously stored transactionIDs. When it forwards the unbundled responses, any		genp, or error) for all original request messages of the upstream nested messag
	extra messages MUST be dropped, and any missing response message MUST be answer		e. While unbundling the downstream nested message, the former PKI management en
	ed with an error message (failInfo bit: systemUnavail) to inform the respective		tity must determine lost and unexpected responses based on the previously stored
	requester about the failed certificate management operation.</t>		transactionIDs. When it forwards the unbundled responses, any extra messages <
			bcp14>MUST</bcp14> be dropped, and any missing response message <bcp14>MUST</bcp
			14> be answered with an error message (failInfo bit: systemUnavail) to inform th
			e respective requester about the failed certificate management operation.</t>
	<t>Note: This form of nesting messages is characterized b y the fact that the transactionID in the header of the nested message is differe nt to those used in the included messages.</t>		<t>Note: This form of nesting messages is characterized b y the fact that the transactionID in the header of the nested message is differe nt to those used in the included messages.</t>
	<t>The protection of the nested messages MUST NOT be regarded as an indication of verification or approval of the bundled PKI request messages.</t>		<t>The protection of the nested messages <bcp14>MUST NOT</bcp14> be regarded as an indication of verification or approval of the bundled PKI request messages.</t>
	<t>No specific prerequisites apply in addition to those s pecified in <xref target="Prereq" format="default"/>.</t>		<t>No specific prerequisites apply in addition to those s pecified in <xref target="Prereq" format="default"/>.</t>
	<t keepWithNext="true">Message Flow:</t>		<t keepWithNext="true">Message Flow:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<artwork align="left" name="" type="" alt=""><![CDATA[
	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 nested		4 format or receive nested
	5 <- nested <-		5 <- nested <-
	6 handle nested		6 handle nested
	]]></artwork>		]]></artwork>
	</section>		</section>
	</section>		</section>
	<section anchor="RA_Replace" numbered="true" toc="default">		<section anchor="RA_Replace" numbered="true" toc="default">
	<name>Replacing Protection</name>		<name>Replacing Protection</name>
	<t>The following two alternatives can be used by any PKI management en		<t>The following two alternatives can be used by any PKI management en
	tity forwarding a CMP message with or without changes while providing its own pr		tity forwarding a CMP message with or without changes while providing its own pr
	otection and in this way asserting approval of the message.</t>		otection and, in this way, asserting approval of the message.</t>
	<t>If retaining end-to-end message authentication is required,		<t>If retaining end-to-end message authentication is required,
	an additional protection SHALL be added instead of replacing the original protec		an additional protection <bcp14>SHALL</bcp14> be added instead of replacing the
	tion.</t>		original protection.</t>
	<t>By replacing the existing protection using its own CMP prote		<t>By replacing the existing protection using its own CMP prote
	ction key the PKI management entity provides a proof of verifying and approving		ction key, the PKI management entity provides a proof of verifying and approving
	the message as described above. Thus, the PKI management entity acts as an actua		the message as described above. Thus, the PKI management entity acts as an actu
	l Registration Authority (RA), which implements important security functionality		al registration authority (RA), which implements important security functionalit
	of the PKI.</t>		y of the PKI such as verifying the proof of requester identity and authorization
	<t keepWithNext="true">Before replacing the existing protection by a n		.</t>
	ew protection, the PKI management entity</t>		<t>Note: By replacing the message protection, the binding of a
			signature-based proof-of-possession to the proof-of-identity given by the origin
			al message protection gets lost. To enable the CA to verify this binding, the o
			riginal message can be provided in the origPKIMessage generalInfo field.</t>
			<t keepWithNext="true">Before replacing the existing protection with a
			new protection, the PKI management entity:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>MUST validate the protection of the received message,</li>		<li><bcp14>MUST</bcp14> validate the protection of the received mess age,</li>
	<li>should check the content of the message,</li>		<li>should check the content of the message,</li>
	<li>may do any modifications that it wants to perform, and</li>		<li>may do any modifications that it wants to perform, and</li>
	<li>MUST check that the sender of the original message, as authentic		<li><bcp14>MUST</bcp14> check that the sender of the original messag
	ated by the message protection, is authorized for the given operation.</li>		e, as authenticated by the message protection, is authorized for the given opera
			tion.</li>
			<li>for certificate requests, <bcp14>MUST</bcp14> verify
			the binding of signature-based proof-of-possession to the proof-of-identity as d
			escribed in <xref target="RA_response_enrollment" format="default"/>.</li>
	</ul>		</ul>
	<t>These message adaptations MUST NOT be applied to kur messages descr		<t>These message adaptations <bcp14>MUST NOT</bcp14> be applied to kur
	ibed in <xref target="EE_Update" format="default"/> since their original protect		messages described in <xref target="EE_Update" format="default"/> since their o
	ion using the key and certificate to be updated needs to be preserved.</t>		riginal protection using the key and certificate to be updated needs to be prese
	<t>These message adaptations MUST NOT be applied to certificate reques		rved.</t>
	t messages described in <xref target="EE_centralKeyGeneration" format="default"/		<t>These message adaptations <bcp14>MUST NOT</bcp14> be applied to cer
	> for central key generation since their original protection needs to be preserv		tificate request messages described in <xref target="EE_centralKeyGeneration" fo
	ed up to the Key Generation Authority, which needs to use it for encrypting the		rmat="default"/> for central key generation since their original protection need
	new private key for the EE.</t>		s to be preserved up to the KGA, which needs to use it for encrypting the new pr
	<t>In both the kur and central key generation cases, if a PKI manageme		ivate key for the EE.</t>
	nt entity needs to state its approval of the original request message it MUST pr		<t>In both the kur and central key generation cases, if a PKI manageme
	ovide this using a nested message as specified in <xref target="RA_AddSingel" fo		nt entity needs to state its approval of the original request message, it <bcp14
	rmat="default"/>.</t>		>MUST</bcp14> provide this using a nested message as specified in <xref target="
	<t>When an intermediate PKI management entity modifies a message, it M		RA_AddSingel" format="default"/>.</t>
	UST NOT change the transactionID, the senderNonce, or the recipNonce - apart fro		<t>When an intermediate PKI management entity modifies a message, it <
	m the exception for the recipNonce given in <xref target="RA_response_polling" f		bcp14>MUST NOT</bcp14> change the transactionID, the senderNonce, or the recipNo
	ormat="default"/>.</t>		nce, apart from the exception for the recipNonce given in <xref target="RA_respo
			nse_polling" format="default"/>.</t>
	<section anchor="RA_keepPOPO" numbered="true" toc="default">		<section anchor="RA_keepPOPO" numbered="true" toc="default">
	<name>Not Changing Proof-of-Possession</name>		<name>Not Changing Proof-of-Possession</name>
	<t>This variant of forwarding a message means that a PKI management entity forwards a CMP message with or without modifying the message header or bo dy while preserving any included proof-of-possession.</t>		<t>This variant of forwarding a message means that a PKI management entity forwards a CMP message with or without modifying the message header or bo dy while preserving any included proof-of-possession.</t>
	<t>This variant is typically used when an RA replaces an existing MAC-based protection by its own signature-based protection, because the upstream PKI management entity does not know the respective shared secret infor mation, replacing the protection is useful.</t>		<t>This variant is typically used when an RA replaces an existing MAC-based protection with its own signature-based protection; because t he upstream PKI management entity does not know the respective shared secret inf ormation, replacing the protection is useful.</t>
	<t>Note: A signature-based proof-of-possession of a certi ficate request will be broken if any field in the certTemplate structure is chan ged.</t>		<t>Note: A signature-based proof-of-possession of a certi ficate request will be broken if any field in the certTemplate structure is chan ged.</t>
	<t>In case the PKI management entity breaks an existing proof-of-pos session, the message adaptation described in <xref target="RA_breakPOPO" format= "default"/> needs to be applied instead.</t>		<t>In case the PKI management entity breaks an existing proof-of-pos session, the message adaptation described in <xref target="RA_breakPOPO" format= "default"/> needs to be applied instead.</t>
	<t keepWithNext="true">Specific prerequisites augmenting the prerequ isites in <xref target="Prereq" format="default"/>:</t>		<t keepWithNext="true">The specific prerequisite augmenting the prer equisites in <xref target="Prereq" format="default"/> is as follows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The PKI management entity MUST be able to validate the respect ive request and have the authorization to perform approval of the request accord ing to the PKI policies.</li>		<li>The PKI management entity <bcp14>MUST</bcp14> be able to valid ate the respective request and have the authorization to perform approval of the request according to the PKI policies.</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="RA_breakPOPO" numbered="true" toc="default">		<section anchor="RA_breakPOPO" numbered="true" toc="default">
	<name>Using raVerified</name>		<name>Using raVerified</name>
	<t>This variant of forwarding a message needs to be used if a PKI ma		<t>This variant of forwarding a message needs to be used if a PKI ma
	nagement entity breaks any included proof-of-possession in a certificate request		nagement entity breaks any included proof-of-possession in a certificate request
	message, for instance because it forwards an ir or cr message with modification		message, for instance, because it forwards an ir or cr message with modificatio
	s of the certTemplate, i.e., modification, addition, or removal of fields.</t>		ns of the certTemplate, i.e., modification, addition, or removal of fields.</t>
	<t>The PKI management entity MUST verify the proof-of-possession con		<t>The PKI management entity <bcp14>MUST</bcp14> verify the proof-of
	tained in the original message using the included public key. If successful, th		-possession contained in the original message using the included public key. If
	e PKI management entity MUST change the popo field value to raVerified.</t>		successful, the PKI management entity <bcp14>MUST</bcp14> change the popo field
	<t keepWithNext="true">Specific prerequisites augmenting the prerequ		value to raVerified.</t>
	isites in <xref target="Prereq" format="default"/>:</t>		<t keepWithNext="true">Specific prerequisites augmenting the prerequ
			isites in <xref target="Prereq" format="default"/> are as follows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The PKI management entity MUST be authorized to replace the pr		<li>The PKI management entity <bcp14>MUST</bcp14> be authorized to
	oof-of-possession (after verifying it) with raVerified.</li>		replace the proof-of-possession (after verifying it) with raVerified.</li>
	<li>The PKI management entity MUST be able to validate the respect		<li>The PKI management entity <bcp14>MUST</bcp14> be able to valid
	ive request and have the authorization to perform approval of the request accord		ate the respective request and have the authorization to perform approval of the
	ing to the PKI policies.</li>		request according to the PKI policies.</li>
	</ul>		</ul>
	<t keepWithNext="true">Detailed Description of popo Field of certReq		<t keepWithNext="true">Detailed Description of the popo Field of the
	Structure:</t>		certReq Structure:</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	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
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="RA_on-behalf" numbered="true" toc="default">		<section anchor="RA_on-behalf" numbered="true" toc="default">
	<name>Acting on Behalf of other PKI Entities</name>		<name>Acting on Behalf of Other PKI Entities</name>
	<t>A PKI management entity may need to request a PKI management operatio		<t>A PKI management entity may need to request a PKI management operatio
	n on behalf of another PKI entity. In this case the PKI management entity initi		n on behalf of another PKI entity. In this case, the PKI management entity init
	ates the respective PKI management operation as described in <xref target="EE_Us		iates the respective PKI management operation as described in <xref target="EE_U
	eCases" format="default"/> acting in the role of the EE.</t>		seCases" format="default"/>, acting in the role of the EE.</t>
	<t>Note: The request message protection will not authenticate the		<t>Note: The request message protection will not authenticate the
	EE, but the RA acting on behalf of the EE.</t>		EE, but it will authenticate the RA acting on behalf of the EE.</t>
	<section anchor="RA_on-behalf_request" numbered="true" toc="defau lt">		<section anchor="RA_on-behalf_request" numbered="true" toc="defau lt">
	<name>Requesting a Certificate</name>		<name>Requesting a Certificate</name>
	<t>A PKI management entity may use one of the PKI management operati		<t>A PKI management entity may use one of the PKI managem
	ons described in <xref target="EE_request" format="default"/> to request a certi		ent operations described in <xref target="EE_request" format="default"/> to requ
	ficate on behalf of another PKI entity. It either generates the key pair itself		est a certificate on behalf of another PKI entity. It either generates the key
	and inserts the new public key in the subjectPublicKey field of the request cer		pair itself and inserts the new public key in the subjectPublicKey field of the
	tTemplate, or it uses a certificate request received from downstream, e.g., by m		request certTemplate, or it uses a certificate request received from downstream,
	eans of a different protocol. In the latter case it MUST verify the received pr		e.g., by means of a different protocol.
	oof-of-possession if this proof breaks, e.g., due to transformation from <xref t		In the latter case, it <bcp14>MUST</bcp14> verify the rec
	arget="RFC2986" format="default">PKCS#10</xref> to <xref target="RFC4211" format		eived proof-of-possession if this proof breaks, e.g., due to transformation from
	="default">CRMF</xref> certificate request format.</t>		<xref target="RFC2986" format="default">PKCS #10</xref> to <xref target="RFC421
			1" format="default">CRMF</xref>.
			It <bcp14>MUST</bcp14> also verify, based on local PKI po
			licy, that the subject name in the certTemplate identifies the EE.</t>
	<t>No specific prerequisites apply in addition to those s pecified in <xref target="EE_request" format="default"/>.</t>		<t>No specific prerequisites apply in addition to those s pecified in <xref target="EE_request" format="default"/>.</t>
	<t>Note: An upstream PKI management entity will not be ab le to differentiate this PKI management operation from the one described in <xre f target="RA_Replace" format="default"/> because in both cases the message is pr otected by the PKI management entity.</t>		<t>Note: An upstream PKI management entity will not be ab le to differentiate this PKI management operation from the one described in <xre f target="RA_Replace" format="default"/> because, in both cases, the message is protected by the PKI management entity.</t>
	<t keepWithNext="true">The message sequence for this PKI management operation is identical to the respective PKI management operation giv en in <xref target="EE_request" format="default"/>, with the following changes:< /t>		<t keepWithNext="true">The message sequence for this PKI management operation is identical to the respective PKI management operation giv en in <xref target="EE_request" format="default"/>, with the following changes:< /t>
	<ol spacing="normal" type="%d">		<ol spacing="normal" type="1">
	<li>The request messages MUST be signed using the		<li>The request messages <bcp14>MUST</bcp14> be s
	CMP protection key of the PKI management entity taking the role of the EE in th		igned using the CMP protection key of the PKI management entity taking the role
	is operation.</li>		of the EE in this operation.</li>
	<li>If inclusion of a proper proof-of-possession		<li>If inclusion of a proper proof-of-possession
	is not possible the PKI management entity MUST verify the POP provided from down		is not possible, the PKI management entity <bcp14>MUST</bcp14> verify the POP pr
	stream and use "raVerified" in its upstream request.</li>		ovided from downstream and use "raVerified" in its upstream request.</li>
			<li>The binding of the proof-of-possession to the
			proof-of-identity of the requesting EE cannot be provided when acting on behalf
			of the EE.</li>
	</ol>		</ol>
	</section>		</section>
	<section anchor="RA_on-behalf_revoke" numbered="true" toc="defaul t">		<section anchor="RA_on-behalf_revoke" numbered="true" toc="defaul t">
	<name>Revoking a Certificate</name>		<name>Revoking a Certificate</name>
	<t>A PKI management entity may use the PKI management ope ration described in <xref target="EE_Revoke" format="default"/> to revoke a cert ificate of another PKI entity. This revocation request message MUST be signed b y the PKI management entity using its own CMP protection key to prove to the PKI authorization to revoke the certificate on behalf of that PKI entity.</t>		<t>A PKI management entity may use the PKI management ope ration described in <xref target="EE_Revoke" format="default"/> to revoke a cert ificate of another PKI entity. This revocation request message <bcp14>MUST</bcp 14> be signed by the PKI management entity using its own CMP protection key to p rove to the PKI authorization to revoke the certificate on behalf of that PKI en tity.</t>
	<t>No specific prerequisites apply in addition to those s pecified in <xref target="EE_Revoke" format="default"/>.</t>		<t>No specific prerequisites apply in addition to those s pecified in <xref target="EE_Revoke" format="default"/>.</t>
	<t>Note: An upstream PKI management entity will not be ab le to differentiate this PKI management operation from the ones described in <xr ef target="RA_Replace" format="default"/>.</t>		<t>Note: An upstream PKI management entity will not be ab le to differentiate this PKI management operation from the ones described in <xr ef target="RA_Replace" format="default"/>.</t>
	<t keepWithNext="true">The message sequence for this PKI management operation is identical to that given in <xref target="EE_Revoke" form at="default"/>, with the following changes:</t>		<t keepWithNext="true">The message sequence for this PKI management operation is identical to that given in <xref target="EE_Revoke" form at="default"/>, with the following changes:</t>
	<ol spacing="normal" type="%d">		<ol spacing="normal" type="1">
	<li>The rr message MUST be signed using the CMP p		<li>The rr message <bcp14>MUST</bcp14> be signed
	rotection key of the PKI management entity acting on behalf of the EE in this op		using the CMP protection key of the PKI management entity acting on behalf of th
	eration.</li>		e EE in this operation.</li>
	</ol>		</ol>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="Transfer_types" numbered="true" toc="default">		<section anchor="Transfer_types" numbered="true" toc="default">
	<name>CMP Message Transfer Mechanisms</name>		<name>CMP Message Transfer Mechanisms</name>
	<t>CMP messages are designed to be self-contained, such that in principle		<t>CMP messages are designed to be self-contained, such that, in principle
	any reliable transfer mechanism can be used. EEs will typically support only on		, any reliable transfer mechanism can be used. EEs will typically support only
	e transfer mechanism. PKI management entities SHOULD offer HTTP and MAY offer C		one transfer mechanism. PKI management entities <bcp14>SHOULD</bcp14> offer HTT
	oAP where required. Piggybacking of CMP messages on any other reliable transfer		P and <bcp14>MAY</bcp14> offer CoAP where required. Piggybacking of CMP messages
	protocol MAY be used, and file-based transfer MAY be used in case offline transf		on any other reliable transfer protocol <bcp14>MAY</bcp14> be used, and file-ba
	er is required.</t>		sed transfer <bcp14>MAY</bcp14> be used in case offline transfer is required.</t
	<t>Independently of the means of transfer, it can happen that messages are		>
	lost or that a communication partner does not respond. To prevent waiting inde		<t>Independently of the means of transfer, it can happen that messages are
	finitely, each PKI entity that sends CMP requests should use a configurable per-		lost or that a communication partner does not respond. To prevent waiting inde
	request timeout, and each PKI management entity that handles CMP requests should		finitely, each PKI entity that sends CMP requests should use a configurable per-
	use a configurable timeout in case a further request message is to be expected		request timeout, and each PKI management entity that handles CMP requests should
	from the client side within the same transaction. In this way a hanging transac		use a configurable timeout in case a further request message is to be expected
	tion can be closed cleanly with an error as described in <xref target="Error" fo		from the client side within the same transaction. In this way, a hanging transa
	rmat="default"/> (failInfo bit: systemUnavail) and related resources (for instan		ction can be closed cleanly with an error as described in <xref target="Error" f
	ce, any cached extraCerts) can be freed.</t>		ormat="default"/> (failInfo bit: systemUnavail), and related resources (for inst
	<t>Moreover, there are various situations where the delivery of message		ance, any cached extraCerts) can be freed.</t>
	s gets delayed. For instance, a serving PKI management entity might take longer		<t>Moreover, there are various situations where the delivery of message
	than expected to form a response due to administrative processes, resource cons		s gets delayed. For instance, a serving PKI management entity might take longer
	traints, or upstream message delivery delays. The transport layer itself may ca		than expected to form a response due to administrative processes, resource cons
	use delays, for instance due to offline transport, network segmentation, or inte		traints, or upstream message delivery delays. The transport layer itself may ca
	rmittent network connectivity. Part of these issues can be detected and handled		use delays, for instance, due to offline transport, network segmentation, or int
	at CMP level using pollReq and pollRep messages as described in <xref target="E		ermittent network connectivity. Part of these issues can be detected and handle
	E_Polling" format="default"/>, while others are better handled at transfer level		d at CMP level using pollReq and pollRep messages as described in <xref target="
	. Depending on the transfer protocol and system architecture, solutions for han		EE_Polling" format="default"/>, while others are better handled at transfer leve
	dling delays at transfer level may be present and can be used for CMP connection		l. Depending on the transfer protocol and system architecture, solutions for ha
	s, for instance connection re-establishment and message retransmission.</t>		ndling delays at transfer level may be present and can be used for CMP connectio
			ns, for instance, connection reestablishment and message retransmission.</t>
	<t>Note: Long timeout periods are helpful to maximize chances to handle minor delays at lower layers without the need for polling.</t>		<t>Note: Long timeout periods are helpful to maximize chances to handle minor delays at lower layers without the need for polling.</t>
	<t>Note: When using TCP and similar reliable connection-oriented transp ort protocols, which is typical in conjunction with HTTP, there is the option to keep the connection alive over multiple request-response message pairs. This m ay improve efficiency.</t>		<t>Note: When using TCP and similar reliable connection-oriented transp ort protocols, which is typical in conjunction with HTTP, there is the option to keep the connection alive over multiple request-response message pairs. This m ay improve efficiency.</t>
	<t>When conveying CMP messages in HTTP, CoAP, or MIME-based transfer proto cols, the internet media type "application/pkixcmp" MUST be set for transfer enc oding as specified in <xref target="RFC6712" format="default">Section 3.4 of CMP over HTTP</xref> and <xref target="I-D.ietf-ace-cmpv2-coap-transport" format="d efault">Section 2.4 of CMP over CoAP</xref>.</t>		<t>When conveying CMP messages in HTTP, CoAP, or MIME-based transfer proto cols, the Internet media type "application/pkixcmp" <bcp14>MUST</bcp14> be set f or transfer encoding as specified in <xref target="RFC6712" format="default" sec tionFormat="of" section="3.4">CMP over HTTP</xref> and <xref target="RFC9482" fo rmat="default" sectionFormat="of" section="2.3">CMP over CoAP</xref>.</t>
	<section anchor="HTTP" numbered="true" toc="default">		<section anchor="HTTP" numbered="true" toc="default">
	<name>HTTP Transfer</name>		<name>HTTP Transfer</name>
	<t>This transfer mechanism can be used by a PKI entity to transfer CMP m		<t>This transfer mechanism can be used by a PKI entity to transfer CMP m
	essages over HTTP. If HTTP transfer is used the specifications as described in <		essages over HTTP. If HTTP transfer is used, the specifications described in <xr
	xref target="RFC6712" format="default"/> and updated by <xref target="I-D.ietf-l		ef target="RFC6712" format="default"/> and updated by <xref target="RFC9480" for
	amps-cmp-updates" format="default">CMP Updates</xref> MUST be followed.</t>		mat="default">CMP Updates</xref> <bcp14>MUST</bcp14> be followed.</t>
	<t>PKI management operations MUST use an URI path consisting of '/.well-		<t>PKI management operations <bcp14>MUST</bcp14> use a URI path consisti
	known/cmp/' or '/.well-known/cmp/p/&lt;name&gt;/' as specified in <xref target="		ng of '/.well-known/cmp' or '/.well-known/cmp/p/&lt;name&gt;' as specified in <x
	I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 3.3</xref>. It		ref target="RFC9480" format="default" sectionFormat="of" section="3.3">CMP Updat
	SHOULD be followed by an operation label depending on the type of PKI management		es</xref>. It <bcp14>SHOULD</bcp14> be followed by an operation label depending
	operation.</t>		on the type of PKI management operation.</t>
	<table anchor="http_endpoints" align="left">		<table anchor="http_endpoints" align="left">
	<name>HTTP URI Path Segment &lt;operation&gt;</name>		<name>HTTP URI Path Segment &lt;operation&gt;</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">PKI Management Operation</th>		<th align="left">PKI Management Operation</th>
	<th align="center">URI Path Segment</th>		<th align="center">URI Path Segment</th>
	<th align="left">Details</th>		<th align="left">Details</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left"><xref target="EE_newPKI" format="title"/></td>		<td align="left">Enrolling an End Entity to a New PKI</td>
	<td align="center">initialization</td>		<td align="center">initialization</td>
	<td align="left"><xref target="EE_newPKI" format="default"/></td>		<td align="left"><xref target="EE_newPKI" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_trustedPKI" format="title"/></td >		<td align="left">Enrolling an End Entity to a Known PKI</td>
	<td align="center">certification</td>		<td align="center">certification</td>
	<td align="left"><xref target="EE_trustedPKI" format="default"/></ td>		<td align="left"><xref target="EE_trustedPKI" format="default"/></ td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_Update" format="title"/></td>		<td align="left">Updating a Valid Certificate</td>
	<td align="center">keyupdate</td>		<td align="center">keyupdate</td>
	<td align="left"><xref target="EE_Update" format="default"/></td>		<td align="left"><xref target="EE_Update" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_P10" format="title"/></td>		<td align="left">Enrolling an End Entity Using a PKCS #10 Request< /td>
	<td align="center">pkcs10</td>		<td align="center">pkcs10</td>
	<td align="left"><xref target="EE_P10" format="default"/></td>		<td align="left"><xref target="EE_P10" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_Revoke" format="title"/></td>		<td align="left">Revoking a Certificate</td>
	<td align="center">revocation</td>		<td align="center">revocation</td>
	<td align="left"><xref target="EE_Revoke" format="default"/></td>		<td align="left"><xref target="EE_Revoke" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_CACerts" format="title"/></td>		<td align="left">Get CA Certificates</td>
	<td align="center">getcacerts</td>		<td align="center">getcacerts</td>
	<td align="left"><xref target="EE_CACerts" format="default"/></td>		<td align="left"><xref target="EE_CACerts" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_RootCAUpdate" format="title"/></ td>		<td align="left">Get Root CA Certificate Update</td>
	<td align="center">getrootupdate</td>		<td align="center">getrootupdate</td>
	<td align="left"><xref target="EE_RootCAUpdate" format="default"/> </td>		<td align="left"><xref target="EE_RootCAUpdate" format="default"/> </td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_Temp" format="title"/></td>		<td align="left">Get Certificate Request Template</td>
	<td align="center">getcertreqtemplate</td>		<td align="center">getcertreqtemplate</td>
	<td align="left"><xref target="EE_Temp" format="default"/></td>		<td align="left"><xref target="EE_Temp" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_CRLs" format="title"/></td>		<td align="left">CRL Update Retrieval</td>
	<td align="center">getcrls</td>		<td align="center">getcrls</td>
	<td align="left"><xref target="EE_CRLs" format="default"/></td>		<td align="left"><xref target="EE_CRLs" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">		<td align="left">
	<t><xref target="RA_AddBatch" format="title"/></t>		<t>Batching Messages</t>
	<t>Note: This path element is applicable only bet ween PKI management entities.</t>		<t>Note: This path element is applicable only bet ween PKI management entities.</t>
	</td>		</td>
	<td align="center">nested</td>		<td align="center">nested</td>
	<td align="left"><xref target="RA_AddBatch" format="default"/></td >		<td align="left"><xref target="RA_AddBatch" format="default"/></td >
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t keepWithNext="true">If operation labels are used:</t>		<t keepWithNext="true">If operation labels are used:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Independently of any variants used (see Sections <xre		<li>independently of any variants used (see Sections <xref target="EE_M
	f target="EE_MAC" format="counter"/>, <xref target="EE_centralKeyGeneration" for		AC" format="counter"/>, <xref target="EE_centralKeyGeneration" format="counter"/
	mat="counter"/>, and <xref target="EE_Polling" format="counter"/>) the operation		>, and <xref target="EE_Polling" format="counter"/>), the operation label corres
	label corresponding to the PKI management operation SHALL be used.</li>		ponding to the PKI management operation <bcp14>SHALL</bcp14> be used.</li>
	<li>Any certConf or pollReq messages SHALL be sent to the		<li>any certConf or pollReq messages <bcp14>SHALL</bcp14>
	same endpoint as determined by the PKI management operation.</li>		be sent to the same endpoint as determined by the PKI management operation.</li
	<li>When a single request message is nested as described		>
	in <xref target="RA_AddSingel" format="default"/>, the label to use SHALL be the		<li>when a single request message is nested as described
	same as for the underlying PKI management operation.</li>		in <xref target="RA_AddSingel" format="default"/>, the label to use <bcp14>SHALL
			</bcp14> be the same as for the underlying PKI management operation.</li>
	</ul>		</ul>
	<t>By sending a request to its preferred endpoint, the PKI entity will r		<t>By sending a request to its preferred endpoint, the PKI entity will r
	ecognize via the HTTP response status code whether a configured URI is supported		ecognize, via the HTTP response status code, whether a configured URI is support
	by the PKI management entity.</t>		ed by the PKI management entity.</t>
	<t>In case a PKI management entity receives an unexpected HTTP st		<t>In case a PKI management entity receives an unexpected HTTP st
	atus code from upstream, it MUST respond downstream with an error message as des		atus code from upstream, it <bcp14>MUST</bcp14> respond downstream with an error
	cribed in <xref target="Error" format="default"/> using a failInfo bit correspon		message as described in <xref target="Error" format="default"/>, using a failIn
	ding to the status code, e.g., systemFailure.</t>		fo bit corresponding to the status code, e.g., systemFailure.</t>
	<t>For certificate management the major security goal is integrit		<t>For certificate management, the major security goal is integri
	y and data origin authentication. For delivery of centrally generated keys, also		ty and data origin authentication. For delivery of centrally generated keys, con
	confidentiality is a must. These goals are sufficiently achieved by CMP itself,		fidentiality is also a must. These goals are sufficiently achieved by CMP itself
	also in an end-to-end fashion.</t>		, also in an end-to-end fashion.</t>
	<t>If a second line of defense is required or general privacy con cerns exist, TLS can be used to provide confidentiality on a hop-by-hop basis. TLS should be used with certificate-based authentication to further protect the HTTP transfer as described in <xref target="RFC9110" format="default"/>. In ad dition, the recommendations provided in <xref target="RFC9325" format="default"/ > should be followed.</t>		<t>If a second line of defense is required or general privacy con cerns exist, TLS can be used to provide confidentiality on a hop-by-hop basis. TLS should be used with certificate-based authentication to further protect the HTTP transfer as described in <xref target="RFC9110" format="default"/>. In ad dition, the recommendations provided in <xref target="RFC9325" format="default"/ > should be followed.</t>
	<t>Note: The requirements for checking certificates given in <xref targe t="RFC5280" format="default"/> and either <xref target="RFC5246" format="default "/> or <xref target="RFC8446" format="default"/> must be followed for the TLS la yer. Certificate status checking should be used for the TLS certificates of all communication partners.</t>		<t>Note: The requirements for checking certificates given in <xref targe t="RFC5280" format="default"/> and either <xref target="RFC5246" format="default "/> or <xref target="RFC8446" format="default"/> must be followed for the TLS la yer. Certificate status checking should be used for the TLS certificates of all communication partners.</t>
	<t>TLS with mutual authentication based on shared secret information may be used in case no suitable certificates for certificate-based authentication a re available, e.g., a PKI management operation with MAC-based protection is used .</t>		<t>TLS with mutual authentication based on shared secret information may be used in case no suitable certificates for certificate-based authentication a re available, e.g., a PKI management operation with MAC-based protection is used .</t>
	<t>Note: The entropy of the shared secret information is crucial for the level of protection available using shard secret information-based TLS authenti cation. A pre-shared key (PSK) mechanism may be used with shared secret informa tion with an entropy of at least 128 bits. Otherwise, a password-authenticated key exchange (PAKE) protocol is recommended.</t>		<t>Note: The entropy of the shared secret information is crucial for the level of protection available using shard secret information-based TLS authenti cation. A pre-shared key (PSK) mechanism may be used with shared secret informa tion with an entropy of at least 128 bits. Otherwise, a password-authenticated key exchange (PAKE) protocol is recommended.</t>
	<t>Note: The provisioning of client certificates and PSKs is out of scope of this document.</t>		<t>Note: The provisioning of client certificates and PSKs is out of scope of this document.</t>
	</section>		</section>
	<section anchor="CoAP" numbered="true" toc="default">		<section anchor="CoAP" numbered="true" toc="default">
	<name>CoAP Transfer </name>		<name>CoAP Transfer </name>
	<t>This transfer mechanism can be used by a PKI entity to transf		<t>This transfer mechanism can be used by a PKI entity to transf
	er CMP messages over <xref target="RFC7252" format="default">CoAP</xref>, e.g.,		er CMP messages over <xref target="RFC7252" format="default">CoAP</xref>, e.g.,
	in constrained environments. If CoAP transfer is used the specifications as de		in constrained environments. If CoAP transfer is used, the specifications descr
	scribed in <xref target="I-D.ietf-ace-cmpv2-coap-transport" format="default">CMP		ibed in <xref target="RFC9482" format="default">CMP over CoAP</xref> <bcp14>MUST
	over CoAP</xref> MUST be followed.</t>		</bcp14> be followed.</t>
	<t>PKI management operations MUST use an URI path consisting of '		<t>PKI management operations <bcp14>MUST</bcp14> use a URI path c
	/.well-known/cmp/' or '/.well-known/cmp/p/&lt;name&gt;/' as specified in <xref t		onsisting of '/.well-known/cmp' or '/.well-known/cmp/p/&lt;name&gt;' as specifie
	arget="I-D.ietf-ace-cmpv2-coap-transport" format="default">CMP over CoAP Section		d in <xref target="RFC9482" format="default" sectionFormat="of" section="2.1">CM
	2.1</xref>. It SHOULD be followed by an operation label depending on the type		P over CoAP</xref>. It <bcp14>SHOULD</bcp14> be followed by an operation label
	of PKI management operation.</t>		depending on the type of PKI management operation.</t>
	<table anchor="coap_endpoints" align="left">		<table anchor="coap_endpoints" align="left">
	<name>CoAP URI Path Segment &lt;operation&gt;</name>		<name>CoAP URI Path Segment &lt;operation&gt;</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">PKI Management Operation</th>		<th align="left">PKI Management Operation</th>
	<th align="center">URI Path Segment</th>		<th align="center">URI Path Segment</th>
	<th align="left">Details</th>		<th align="left">Details</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left"><xref target="EE_newPKI" format="title"/></td>		<td align="left">Enrolling an End Entity to a New PKI</td>
	<td align="center">ir</td>		<td align="center">ir</td>
	<td align="left"><xref target="EE_newPKI" format="default"/></td>		<td align="left"><xref target="EE_newPKI" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_trustedPKI" format="title"/></td >		<td align="left">Enrolling an End Entity to a Known PKI</td>
	<td align="center">cr</td>		<td align="center">cr</td>
	<td align="left"><xref target="EE_trustedPKI" format="default"/></ td>		<td align="left"><xref target="EE_trustedPKI" format="default"/></ td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_Update" format="title"/></td>		<td align="left">Updating a Valid Certificate</td>
	<td align="center">kur</td>		<td align="center">kur</td>
	<td align="left"><xref target="EE_Update" format="default"/></td>		<td align="left"><xref target="EE_Update" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_P10" format="title"/></td>		<td align="left">Enrolling an End Entity Using a PKCS #10 Request< /td>
	<td align="center">p10</td>		<td align="center">p10</td>
	<td align="left"><xref target="EE_P10" format="default"/></td>		<td align="left"><xref target="EE_P10" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_Revoke" format="title"/></td>		<td align="left">Revoking a Certificate</td>
	<td align="center">rr</td>		<td align="center">rr</td>
	<td align="left"><xref target="EE_Revoke" format="default"/></td>		<td align="left"><xref target="EE_Revoke" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_CACerts" format="title"/></td>		<td align="left">Get CA Certificates</td>
	<td align="center">crts</td>		<td align="center">crts</td>
	<td align="left"><xref target="EE_CACerts" format="default"/></td>		<td align="left"><xref target="EE_CACerts" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_RootCAUpdate" format="title"/></ td>		<td align="left">Get Root CA Certificate Update</td>
	<td align="center">rcu</td>		<td align="center">rcu</td>
	<td align="left"><xref target="EE_RootCAUpdate" format="default"/> </td>		<td align="left"><xref target="EE_RootCAUpdate" format="default"/> </td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_Temp" format="title"/></td>		<td align="left">Get Certificate Request Template</td>
	<td align="center">att</td>		<td align="center">att</td>
	<td align="left"><xref target="EE_Temp" format="default"/></td>		<td align="left"><xref target="EE_Temp" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left"><xref target="EE_CRLs" format="title"/></td>		<td align="left">CRL Update Retrieval</td>
	<td align="center">crls</td>		<td align="center">crls</td>
	<td align="left"><xref target="EE_CRLs" format="default"/></td>		<td align="left"><xref target="EE_CRLs" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">		<td align="left">
	<t><xref target="RA_AddBatch" format="title"/></t>		<t>Batching Messages</t>
	<t>Note: This path element is applicable only bet ween PKI management entities.</t>		<t>Note: This path element is applicable only bet ween PKI management entities.</t>
	</td>		</td>
	<td align="center">nest</td>		<td align="center">nest</td>
	<td align="left"><xref target="RA_AddBatch" format="default"/></td >		<td align="left"><xref target="RA_AddBatch" format="default"/></td >
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t keepWithNext="true">If operation labels are used:</t>		<t keepWithNext="true">If operation labels are used:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Independently of any variants used (see Sections <xre		<li>independently of any variants used (see Sections <xre
	f target="EE_MAC" format="counter"/>, <xref target="EE_centralKeyGeneration" for		f target="EE_MAC" format="counter"/>, <xref target="EE_centralKeyGeneration" for
	mat="counter"/>, and <xref target="EE_Polling" format="counter"/>) the operation		mat="counter"/>, and <xref target="EE_Polling" format="counter"/>), the operatio
	label corresponding to the PKI management operation SHALL be used.</li>		n label corresponding to the PKI management operation <bcp14>SHALL</bcp14> be us
	<li>Any certConf or pollReq messages SHALL be sent to the		ed.</li>
	same endpoint as determined by the PKI management operation.</li>		<li>any certConf or pollReq messages <bcp14>SHALL</bcp14>
	<li>When a single request message is nested as described		be sent to the same endpoint, as determined by the PKI management operation.</l
	in <xref target="RA_AddSingel" format="default"/>, the label to use SHALL be the		i>
	same as for the underlying PKI management operation.</li>		<li>when a single request message is nested as described
			in <xref target="RA_AddSingel" format="default"/>, the label to use <bcp14>SHALL
			</bcp14> be the same as for the underlying PKI management operation.</li>
	</ul>		</ul>
	<t>By sending a request to its preferred endpoint, the PKI entity		<t>By sending a request to its preferred endpoint, the PKI entity
	will recognize via the CoAP response status code whether a configured URI is su		will recognize, via the CoAP response status code, whether a configured URI is
	pported by the PKI management entity. The CoAP-inherent discovery mechanisms MA		supported by the PKI management entity. The CoAP-inherent discovery mechanisms
	Y also be used.</t>		<bcp14>MAY</bcp14> also be used.</t>
	<t>In case a PKI management entity receives an unexpected CoAP st		<t>In case a PKI management entity receives an unexpected CoAP st
	atus code from upstream, it MUST respond downstream with an error message as des		atus code from upstream, it <bcp14>MUST</bcp14> respond downstream with an error
	cribed in <xref target="Error" format="default"/> using a failInfo bit correspon		message, as described in <xref target="Error" format="default"/>, using a failI
	ding to the status code, e.g., systemFailure.</t>		nfo bit corresponding to the status code, e.g., systemFailure.</t>
	<t>Like for HTTP transfer, to offer a second line of defense or t		<t>Like for HTTP transfer, to offer a second line of defense or t
	o provide hop-by-hop privacy protection, DTLS may be utilized as described in <x		o provide hop-by-hop privacy protection, DTLS may be utilized as described in <x
	ref target="I-D.ietf-ace-cmpv2-coap-transport" format="default">CMP over CoAP</x		ref target="RFC9482" format="default">CMP over CoAP</xref>. If DTLS is utilized
	ref>. If DTLS is utilized, the same boundary conditions (peer authentication, e		, the same boundary conditions (peer authentication, etc.) as those stated for T
	tc.) as stated for TLS to protect HTTP transfer in <xref target="HTTP" format="d		LS to protect HTTP transfer in <xref target="HTTP" format="default"/> apply to D
	efault"/> apply to DTLS likewise.</t>		TLS likewise.</t>
	<t>Note: The provisioning of client certificates and PSKs is out of scope of this document.</t>		<t>Note: The provisioning of client certificates and PSKs is out of scope of this document.</t>
	</section>		</section>
	<section anchor="Piggybacking" numbered="true" toc="default">		<section anchor="Piggybacking" numbered="true" toc="default">
	<name>Piggybacking on Other Reliable Transfer</name>		<name>Piggybacking on Other Reliable Transfer</name>
	<t>CMP messages MAY also be transfer on some other reliable protocol, e.		<t>CMP messages <bcp14>MAY</bcp14> also be transferred on some other rel
	g., EAP or MQTT. Connection, delay, and error handling mechanisms similar to tho		iable protocol, e.g., Extensible Authentication Protocol (EAP) or Message Queuin
	se specified for HTTP in <xref target="RFC6712" format="default">RFC&nbsp;6712</		g Telemetry Transport (MQTT). Connection, delay, and error handling mechanisms s
	xref>need to be implemented.</t>		imilar to those specified for HTTP in <xref target="RFC6712" format="default"/>
	<t>A more detailed specification is out of scope of this document and wo		need to be implemented.</t>
	uld need to be given for instance in the scope of the transfer protocol used.</t		<t>A more detailed specification is out of scope of this document and wo
	>		uld need to be given, for instance, in the scope of the transfer protocol used.<
			/t>
	</section>		</section>
	<section anchor="Offline" numbered="true" toc="default">		<section anchor="Offline" numbered="true" toc="default">
	<name>Offline Transfer</name>		<name>Offline Transfer</name>
	<t>For transferring CMP messages between PKI entities, any mechanism can		<t>For transferring CMP messages between PKI entities, any mechanism tha
	be used that is able to store and forward binary objects of sufficient length a		t is able to store and forward binary objects of sufficient length and with suff
	nd with sufficient reliability while preserving the order of messages for each t		icient reliability while preserving the order of messages for each transaction c
	ransaction.</t>		an be used.</t>
	<t>The transfer mechanism should be able to indicate message loss, exces		<t>The transfer mechanism should be able to indicate message loss, exces
	sive delay, and possibly other transmission errors. In such cases the PKI entiti		sive delay, and possibly other transmission errors. In such cases, the PKI entit
	es MUST report an error as specified in <xref target="Error" format="default"/>		ies <bcp14>MUST</bcp14> report an error as specified in <xref target="Error" for
	as far as possible.</t>		mat="default"/>, as far as possible.</t>
	<section anchor="File-based" numbered="true" toc="default">		<section anchor="File-based" numbered="true" toc="default">
	<name>File-Based Transfer</name>		<name>File-Based Transfer</name>
	<t>CMP messages MAY be transferred between PKI entities using file-bas ed mechanisms, for instance when an EE is offline or a PKI management entity per forms delayed delivery. Each file MUST contain the ASN.1 DER encoding of one CM P message only, where the message may be nested. There MUST be no extraneous he ader or trailer information in the file. The file name extension ".pki" MUST be used.</t>		<t>CMP messages <bcp14>MAY</bcp14> be transferred between PKI entities using file-based mechanisms, for instance, when an EE is offline or a PKI manag ement entity performs delayed delivery. Each file <bcp14>MUST</bcp14> contain t he ASN.1 DER encoding of one CMP message only, where the message may be nested. There <bcp14>MUST</bcp14> be no extraneous header or trailer information in the file. The filename extension ".pki" <bcp14>MUST</bcp14> be used.</t>
	</section>		</section>
	<section anchor="Other_trans" numbered="true" toc="default">		<section anchor="Other_trans" numbered="true" toc="default">
	<name>Other Asynchronous Transfer Protocols</name>		<name>Other Asynchronous Transfer Protocols</name>
	<t>Other asynchronous transfer protocols, e.g., email or website up-/d		<t>Other asynchronous transfer protocols, e.g., email or website uploa
	ownload, MAY transfer CMP messages between PKI entities. A MIME wrapping is defi		d/download, <bcp14>MAY</bcp14> transfer CMP messages between PKI entities. A MIM
	ned for those environments that are MIME-native. The MIME wrapping is specified		E wrapping is defined for those environments that are MIME-native. The MIME wrap
	in <xref target="RFC8551" format="default">RFC&nbsp;8551 Section 3.1</xref>.</t>		ping is specified in <xref target="RFC8551" format="default" sectionFormat="of"
	<t>The ASN.1 DER encoding of the CMP messages MUST be transferred usin		section="3.1"/>.</t>
	g the "application/pkixcmp" content type and base64-encoded content transfer enc		<t>The ASN.1 DER encoding of the CMP messages <bcp14>MUST</bcp14> be t
	oding as specified in <xref target="RFC6712" format="default">Section 3.4 of CMP		ransferred using the "application/pkixcmp" content type and base64-encoded conte
	over HTTP</xref>. A filename MUST be included either in a "content-type" or a "		nt transfer encoding, as specified in <xref target="RFC6712" format="default" se
	content-disposition" statement. The file name extension ".pki" MUST be used.</t>		ctionFormat="of" section="3.4">CMP over HTTP</xref>. A filename <bcp14>MUST</bcp
			14> be included either in a "content-type" or a "content-disposition" statement.
			The filename extension ".pki" <bcp14>MUST</bcp14> be used.</t>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="Conformity" numbered="true" toc="default">		<section anchor="Conformity" numbered="true" toc="default">
	<name>Conformance Requirements</name>		<name>Conformance Requirements</name>
	<t>This section defines which level of support for the various features specified in this profile is required for each type of PKI entity.</t>		<t>This section defines which level of support for the various features specified in this profile is required for each type of PKI entity.</t>
	<section anchor="UseCases" numbered="true" toc="default">		<section anchor="UseCases" numbered="true" toc="default">
	<name>PKI Management Operations</name>		<name>PKI Management Operations</name>
	<t>The following table provides an overview of the PKI management operations specified in Sections <xref target="EE_UseCases" format="counter"/> and <xref target="RA_UseCases" format="counter"/> and states whether support by conforming EE, RA, and CA implementations is mandatory, recommended, optional, o r not applicable. Variants amend or change behavior of base PKI management oper ations and are therefore also included.</t>		<t>The following table provides an overview of the PKI management operations specified in Sections <xref target="EE_UseCases" format="counter"/> and <xref target="RA_UseCases" format="counter"/> and states whether support by conforming EE, RA, and CA implementations is mandatory, recommended, optional, o r not applicable. Variants amend or change behavior of base PKI management oper ations and are therefore also included.</t>
	<t>The PKI management operation specifications in <xref target="EE_UseCa ses" format="default"/> assume that either the RA or CA is the PKI management en tity that terminates the CMP protocol. If the RA terminates the CMP protocol it either responds directly as described in <xref target="RA_response" format="defa ult"/> or forwards the certificate management operation towards the CA not using CMP. <xref target="RA_forwarde_messages" format="default"/> describes different options how an RA can forward a CMP message using CMP. <xref target="RA_on-beha lf" format="default"/> offers the option that an RA operates on behalf on an EE and therefore takes the role of the EE in <xref target="EE_UseCases" format="def ault"/>.</t>		<t>The PKI management operation specifications in <xref target="EE_UseCa ses" format="default"/> assume that either the RA or CA is the PKI management en tity that terminates the Certificate Management Protocol. If the RA terminates C MP, it either responds directly as described in <xref target="RA_response" forma t="default"/>, or it forwards the certificate management operation towards the C A not using CMP. <xref target="RA_forwarde_messages" format="default"/> describe s different options of how an RA can forward a CMP message using CMP. <xref targ et="RA_on-behalf" format="default"/> offers the option that an RA operates on be half on an EE and therefore takes the role of the EE in <xref target="EE_UseCase s" format="default"/>.</t>
	<t keepWithNext="true"/>		<t keepWithNext="true"/>
	<table anchor="PKIManOp_support" align="left">		<table anchor="PKIManOp_support" align="left">
	<name>Level of Support for PKI Management Operations and Variants</n ame>		<name>Level of Support for PKI Management Operations and Variants</n ame>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">ID</th>		<th align="left">ID</th>
	<th align="left">PKI Management Operations and Variants</th>		<th align="left">PKI Management Operations and Variants</th>
	<th align="left">EE</th>		<th align="left">EE</th>
	<th align="left">RA</th>		<th align="left">RA</th>
	<th align="left">CA</th>		<th align="left">CA</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">Generic</td>		<td align="left">Generic</td>
	<td align="left"><xref target="GenericParts" format="title"/>, <		<td align="left">Generic Aspects of PKI Messages and PKI Managem
	xref target="GenericParts" format="default"/></td>		ent Operations, <xref target="GenericParts" format="default"/></td>
	<td align="left">MUST</td>		<td align="left"><bcp14>MUST</bcp14></td>
	<td align="left">MUST</td>		<td align="left"><bcp14>MUST</bcp14></td>
	<td align="left">MUST</td>		<td align="left"><bcp14>MUST</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">IR</td>		<td align="left">IR</td>
	<td align="left"><xref target="EE_newPKI" format="title"/>, <xre		<td align="left">Enrolling an End Entity to a New PKI, <xref tar
	f target="EE_newPKI" format="default"/></td>		get="EE_newPKI" format="default"/></td>
	<td align="left">MUST</td>		<td align="left"><bcp14>MUST</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MUST</td>		<td align="left"><bcp14>MUST</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CR</td>		<td align="left">CR</td>
	<td align="left"><xref target="EE_trustedPKI" format="title"/>,		<td align="left">Enrolling an End Entity to a Known PKI, <xref t
	<xref target="EE_trustedPKI" format="default"/></td>		arget="EE_trustedPKI" format="default"/></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">KUR</td>		<td align="left">KUR</td>
	<td align="left"><xref target="EE_Update" format="title"/>, <xre		<td align="left">Updating a Valid Certificate, <xref target="EE_
	f target="EE_Update" format="default"/></td>		Update" format="default"/></td>
	<td align="left">MUST</td>		<td align="left"><bcp14>MUST</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MUST</td>		<td align="left"><bcp14>MUST</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">P10CR</td>		<td align="left">P10CR</td>
	<td align="left"><xref target="EE_P10" format="title"/>, <xref t		<td align="left"> Enrolling an End Entity Using a PKCS #10
	arget="EE_P10" format="default"/></td>		Request, <xref target="EE_P10" format="default"/></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">MAC</td>		<td align="left">MAC</td>
	<td align="left"><xref target="EE_MAC" format="title"/>, with IR		<td align="left">Using MAC-Based Protection for Enrollment (IR,
	, CR, and P10CR if supported, <xref target="EE_MAC" format="default"/></td>		CR, and P10CR if supported), <xref target="EE_MAC" format="default"/></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">SHOULD 1)</td>		<td align="left"><bcp14>SHOULD</bcp14> 1)</td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CKeyGen</td>		<td align="left">CKeyGen</td>
	<td align="left"><xref target="EE_centralKeyGeneration" format="		<td align="left">Adding Central Key Pair Generation to Enrollmen
	title"/>, IR, CR, KUR, and P10CR if supported, <xref target="EE_centralKeyGenera		t (IR, CR, KUR, and P10CR if supported), <xref target="EE_centralKeyGeneration"
	tion" format="default"/></td>		format="default"/></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">RR</td>		<td align="left">RR</td>
	<td align="left"><xref target="EE_Revoke" format="title"/>, <xre		<td align="left">Revoking a Certificate, <xref target="EE_Revoke
	f target="EE_Revoke" format="default"/></td>		" format="default"/></td>
	<td align="left">SHOULD</td>		<td align="left"><bcp14>SHOULD</bcp14></td>
	<td align="left">SHOULD 2)</td>		<td align="left"><bcp14>SHOULD</bcp14> 2)</td>
	<td align="left">SHOULD 3)</td>		<td align="left"><bcp14>SHOULD</bcp14> 3)</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CACerts</td>		<td align="left">CACerts</td>
	<td align="left"><xref target="EE_CACerts" format="title"/>, <xr		<td align="left">Get CA Certificates, <xref target="EE_CACerts"
	ef target="EE_CACerts" format="default"/></td>		format="default"/></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">RootUpd</td>		<td align="left">RootUpd</td>
	<td align="left"><xref target="EE_RootCAUpdate" format="title"/>		<td align="left">Get Root CA Certificate Update, <xref target="E
	, <xref target="EE_RootCAUpdate" format="default"/></td>		E_RootCAUpdate" format="default"/></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">ReqTempl</td>		<td align="left">ReqTempl</td>
	<td align="left"><xref target="EE_Temp" format="title"/>, <xref		<td align="left">Get Certificate Request Template, <xref target=
	target="EE_Temp" format="default"/></td>		"EE_Temp" format="default"/></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CRLUpd</td>		<td align="left">CRLUpd</td>
	<td align="left"><xref target="EE_CRLs" format="title"/>, <xref		<td align="left">CRL Update Retrieval, <xref target="EE_CRLs" fo
	target="EE_CRLs" format="default"/></td>		rmat="default"/></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Polling</td>		<td align="left">Polling</td>
	<td align="left"><xref target="EE_Polling" format="title"/>, <xr		<td align="left">Handling Delayed Delivery, <xref target="EE_Pol
	ef target="EE_Polling" format="default"/></td>		ling" format="default"/></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CertResp</td>		<td align="left">CertResp</td>
	<td align="left"><xref target="RA_response_enrollment" format="t itle"/> (IR, CR, KUR, and P10CR if supported), <xref target="RA_response_enrollm ent" format="default"/></td>		<td align="left">Responding to a Certificate Request (IR, CR, KU R, and P10CR if supported), <xref target="RA_response_enrollment" format="defaul t"/></td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MUST</td>		<td align="left"><bcp14>MUST</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CertConf</td>		<td align="left">CertConf</td>
	<td align="left"><xref target="RA_response_confirmation" format= "title"/>, <xref target="RA_response_confirmation" format="default"/></td>		<td align="left">Responding to a Confirmation Message, <xref tar get="RA_response_confirmation" format="default"/></td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MUST</td>		<td align="left"><bcp14>MUST</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">RevResp</td>		<td align="left">RevResp</td>
	<td align="left"><xref target="RA_response_revocation" format="t itle"/>, <xref target="RA_response_revocation" format="default"/></td>		<td align="left">Responding to a Revocation Request, <xref targe t="RA_response_revocation" format="default"/></td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">SHOULD</td>		<td align="left"><bcp14>SHOULD</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">GenResp</td>		<td align="left">GenResp</td>
	<td align="left"><xref target="RA_response_support" format="titl e"/> (CACerts, RootUpd, ReqTempl, CRLUpd if supported), <xref target="RA_respons e_support" format="default"/></td>		<td align="left">Responding to a Support Message (CACerts, RootU pd, ReqTempl, CRLUpd if supported), <xref target="RA_response_support" format="d efault"/></td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">InitPoll</td>		<td align="left">InitPoll</td>
	<td align="left"><xref target="RA_response_polling" format="titl e"/>, <xref target="RA_response_polling" format="default"/></td>		<td align="left">Initiating Delayed Delivery, <xref target="RA_r esponse_polling" format="default"/></td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">FwdKeep</td>		<td align="left">FwdKeep</td>
	<td align="left"><xref target="RA_forwarde_messages" format="tit le"/> - <xref target="RA_noChange" format="title"/>, <xref target="RA_noChange" format="default"/></td>		<td align="left">Forwarding Messages - Not Changing Protection, <xref target="RA_noChange" format="default"/></td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	<td align="left">MUST</td>		<td align="left"><bcp14>MUST</bcp14></td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">FwdAddS</td>		<td align="left">FwdAddS</td>
	<td align="left"><xref target="RA_forwarde_messages" format="tit le"/> - <xref target="RA_AddSingel" format="title"/>, <xref target="RA_AddSingel " format="default"/></td>		<td align="left">Forwarding Messages - Adding Protection to a Re quest Message, <xref target="RA_AddSingel" format="default"/></td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	<td align="left">MUST</td>		<td align="left"><bcp14>MUST</bcp14></td>
	<td align="left">MUST</td>		<td align="left"><bcp14>MUST</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">FwdAddB</td>		<td align="left">FwdAddB</td>
	<td align="left"><xref target="RA_forwarde_messages" format="tit le"/> - <xref target="RA_AddBatch" format="title"/>, <xref target="RA_AddBatch" format="default"/></td>		<td align="left">Forwarding Messages - Batching Messages, <xref target="RA_AddBatch" format="default"/></td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">FwdReqKP</td>		<td align="left">FwdReqKP</td>
	<td align="left"><xref target="RA_forwarde_messages" format="tit le"/> - <xref target="RA_keepPOPO" format="title"/>, <xref target="RA_keepPOPO" format="default"/></td>		<td align="left">Forwarding Messages - Not Changing Proof-of-Pos session, <xref target="RA_keepPOPO" format="default"/></td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	<td align="left">SHOULD 1)</td>		<td align="left"><bcp14>SHOULD</bcp14> 1)</td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">FwdReqBP</td>		<td align="left">FwdReqBP</td>
	<td align="left"><xref target="RA_forwarde_messages" format="tit le"/> - <xref target="RA_breakPOPO" format="title"/>, <xref target="RA_breakPOPO " format="default"/></td>		<td align="left">Forwarding Messages - Using raVerified, <xref t arget="RA_breakPOPO" format="default"/></td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CertROnB</td>		<td align="left">CertROnB</td>
	<td align="left"><xref target="RA_on-behalf" format="title"/> - <xref target="RA_on-behalf_request" format="title"/>, <xref target="RA_on-behalf _request" format="default"/></td>		<td align="left">Acting on Behalf of Other PKI Entities - Reques ting a Certificate, <xref target="RA_on-behalf_request" format="default"/></td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">RevROnB</td>		<td align="left">RevROnB</td>
	<td align="left"><xref target="RA_on-behalf" format="title"/> - <xref target="RA_on-behalf_revoke" format="title"/>, <xref target="RA_on-behalf_ revoke" format="default"/></td>		<td align="left">Acting on Behalf of Other PKI Entities - Revoki ng a Certificate, <xref target="RA_on-behalf_revoke" format="default"/></td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	<td align="left">SHOULD 2)</td>		<td align="left"><bcp14>SHOULD</bcp14> 2)</td>
	<td align="left">SHOULD 3)</td>		<td align="left"><bcp14>SHOULD</bcp14> 3)</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>1) The RA should be able to change the CMP message protectio		<ol type="%d)" spacing="normal">
	n from MAC-based to signature-based protection, see <xref target="RA_keepPOPO" f		<li>The RA should be able to change the CMP message protection
	ormat="default"/>.</t>		from MAC-based to signature-based protection; see <xref target="RA_keepPOPO" for
	<t>2) The RA should be able to request certificate revocation o		mat="default"/>.</li>
	n behalf of an EE, see <xref target="RA_on-behalf_revoke" format="default"/>, e.		<li>The RA should be able to request certificate revocation on
	g., in order to handle incidents.</t>		behalf of an EE (see <xref target="RA_on-behalf_revoke" format="default"/>), e.g
	<t>3) An alternative would be to perform revocation at the CA w		., in order to handle incidents.</li>
	ithout using CMP, for instance using a local administration interface.</t>		<li>An alternative would be to perform revocation at the CA wit
			hout using CMP, for instance, using a local administration interface.</li>
			</ol>
	</section>		</section>
	<section anchor="Transport" numbered="true" toc="default">		<section anchor="Transport" numbered="true" toc="default">
	<name>Message Transfer</name>		<name>Message Transfer</name>
	<t>CMP does not have specific needs regarding message transfer, e		<t>CMP does not have specific needs regarding message transfer, e
	xcept that for each request message sent, eventually a sequence of one response		xcept that, for each request message sent, eventually a sequence of one response
	message should be received. Therefore, virtually any reliable transfer mechanis		message should be received. Therefore, virtually any reliable transfer mechani
	m can be used, such as HTTP, CoAP, and file-based offline transfer. Thus, this		sm can be used, such as HTTP, CoAP, and file-based offline transfer. Thus, this
	document does not require any specific transfer protocol to be supported by conf		document does not require any specific transfer protocol to be supported by con
	orming implementations.</t>		forming implementations.</t>
	<t>On different links between PKI entities, e.g., EE-RA and RA-CA		<t>On different links between PKI entities (e.g., EE-RA and RA-CA
	, different transfer mechanisms as specified in <xref target="Transfer_types" fo		), different transfer mechanisms, as specified in <xref target="Transfer_types"
	rmat="default"/> may be used.</t>		format="default"/>, may be used.</t>
	<t>HTTP SHOULD be supported and CoAP MAY be supported at all PKI		<t>HTTP <bcp14>SHOULD</bcp14> be supported and CoAP <bcp14>MAY</b
	entities for maximizing general interoperability at transfer level. Yet full fle		cp14> be supported at all PKI entities for maximizing general interoperability a
	xibility is retained to choose whatever transfer mechanism is suitable, for inst		t transfer level. Yet full flexibility is retained to choose whatever transfer m
	ance for devices and system architectures with specific constraints.</t>		echanism is suitable, for instance, for devices and system architectures with sp
			ecific constraints.</t>
	<t>The following table lists the name and level of support specif ied for each transfer mechanism.</t>		<t>The following table lists the name and level of support specif ied for each transfer mechanism.</t>
	<table anchor="Trans_Support" align="left">		<table anchor="Trans_Support" align="left">
	<name>Level of Support for Message Transfer Types</name>		<name>Level of Support for Message Transfer Types</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">ID</th>		<th align="left">ID</th>
	<th align="left">Message Transfer Type</th>		<th align="left">Message Transfer Type</th>
	<th align="left">EE</th>		<th align="left">EE</th>
	<th align="left">RA</th>		<th align="left">RA</th>
	<th align="left">CA</th>		<th align="left">CA</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">HTTP</td>		<td align="left">HTTP</td>
	<td align="left"><xref target="HTTP" format="title"/>, <xref tar		<td align="left">HTTP Transfer, <xref target="HTTP" format="defa
	get="HTTP" format="default"/></td>		ult"/></td>
	<td align="left">SHOULD</td>		<td align="left"><bcp14>SHOULD</bcp14></td>
	<td align="left">SHOULD</td>		<td align="left"><bcp14>SHOULD</bcp14></td>
	<td align="left">SHOULD</td>		<td align="left"><bcp14>SHOULD</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CoAP</td>		<td align="left">CoAP</td>
	<td align="left"><xref target="CoAP" format="title"/>, <xref tar		<td align="left">CoAP Transfer, <xref target="CoAP" format="defa
	get="CoAP" format="default"/></td>		ult"/></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Piggyb</td>		<td align="left">Piggyb</td>
	<td align="left"><xref target="Piggybacking" format="title"/>, <		<td align="left">Piggybacking on Other Reliable Transfer, <xref
	xref target="Piggybacking" format="default"/></td>		target="Piggybacking" format="default"/></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Offline</td>		<td align="left">Offline</td>
	<td align="left"><xref target="Offline" format="title"/>, <xref		<td align="left">Offline Transfer, <xref target="Offline" format
	target="Offline" format="default"/></td>		="default"/></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	<td align="left">MAY</td>		<td align="left"><bcp14>MAY</bcp14></td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	<section anchor="IANA" numbered="true" toc="default">		<section anchor="IANA" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>This document defines new entries with the following content in the "CMP Well-Known URI Path Segments" registry (see https://www.iana.org/assignment s/cmp/) as defined in <xref target="RFC8615" format="default">RFC&nbsp;8615</xre f>.</t>		<t>IANA has registered the following content in the "CMP Well-Known URI Path Segments" registry (see <eref brackets="angle" target="https://www.iana.or g/assignments/cmp"/>), as defined in <xref target="RFC8615" format="default"/>.< /t>
	<table anchor="Trans_operationLabels" align="left">		<table anchor="Trans_operationLabels" align="left">
	<name>New "CMP Well-Known URI Path Segments" Registry Entries</name>		<name>New "CMP Well-Known URI Path Segments" Registry Entries</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Path Segment</th>		<th align="left">Path Segment</th>
	<th align="left">Description</th>		<th align="left">Description</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">initialization</td>		<td align="left">initialization</td>
	<td align="left"><xref target="EE_newPKI" format="title"/> over HT		<td align="left">Enrolling an End Entity to a New PKI over HTTP</t
	TP</td>		d>
	<td align="left">[thisRFC]</td>		<td align="left">RFC 9483, <xref target="EE_newPKI" format="defaul
			t"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">certification</td>		<td align="left">certification</td>
	<td align="left"><xref target="EE_trustedPKI" format="title"/> ove		<td align="left">Enrolling an End Entity to a Known PKI over HTTP<
	r HTTP</td>		/td>
	<td align="left">[thisRFC]</td>		<td align="left">RFC 9483, <xref target="EE_trustedPKI" format="de
			fault"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">keyupdate</td>		<td align="left">keyupdate</td>
	<td align="left"><xref target="EE_Update" format="title"/> over HT		<td align="left">Updating a Valid Certificate over HTTP</td>
	TP</td>		<td align="left">RFC 9483, <xref target="EE_Update" format="defaul
	<td align="left">[thisRFC]</td>		t"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">pkcs10</td>		<td align="left">pkcs10</td>
	<td align="left"><xref target="EE_P10" format="title"/> over HTTP<		<td align="left">Enrolling an End Entity Using a PKCS #10 Request
	/td>		over HTTP</td>
	<td align="left">[thisRFC]</td>		<td align="left">RFC 9483, <xref target="EE_P10" format="default"/
			></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">revocation</td>		<td align="left">revocation</td>
	<td align="left"><xref target="EE_Revoke" format="title"/> over HT		<td align="left">Revoking a Certificate over HTTP</td>
	TP</td>		<td align="left">RFC 9483, <xref target="EE_Revoke" format="defaul
	<td align="left">[thisRFC]</td>		t"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">getcacerts</td>		<td align="left">getcacerts</td>
	<td align="left"><xref target="EE_CACerts" format="title"/> over H		<td align="left">Get CA Certificates over HTTP</td>
	TTP</td>		<td align="left">RFC 9483, <xref target="EE_CACerts" format="defau
	<td align="left">[thisRFC]</td>		lt"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">getrootupdate</td>		<td align="left">getrootupdate</td>
	<td align="left"><xref target="EE_RootCAUpdate" format="title"/> o		<td align="left">Get Root CA Certificate Update over HTTP</td>
	ver HTTP</td>		<td align="left">RFC 9483, <xref target="EE_RootCAUpdate" format="
	<td align="left">[thisRFC]</td>		default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">getcertreqtemplate</td>		<td align="left">getcertreqtemplate</td>
	<td align="left"><xref target="EE_Temp" format="title"/> over HTTP		<td align="left">Get Certificate Request Template over HTTP</td>
	</td>		<td align="left">RFC 9483, <xref target="EE_Temp" format="default"
	<td align="left">[thisRFC]</td>		/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">getcrls</td>		<td align="left">getcrls</td>
	<td align="left"><xref target="EE_CRLs" format="title"/> over HTTP		<td align="left">CRL Update Retrieval over HTTP</td>
	</td>		<td align="left">RFC 9483, <xref target="EE_CRLs" format="default"
	<td align="left">[thisRFC]</td>		/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">nested</td>		<td align="left">nested</td>
	<td align="left"><xref target="RA_AddBatch" format="title"/> over		<td align="left">Batching Messages over HTTP</td>
	HTTP</td>		<td align="left">RFC 9483, <xref target="RA_AddBatch" format="defa
	<td align="left">[thisRFC]</td>		ult"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">ir</td>		<td align="left">ir</td>
	<td align="left"><xref target="EE_newPKI" format="title"/> over Co		<td align="left">Enrolling an End Entity to a New PKI over CoAP</t
	AP</td>		d>
	<td align="left">[thisRFC]</td>		<td align="left">RFC 9483, <xref target="EE_newPKI" format="defaul
			t"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">cr</td>		<td align="left">cr</td>
	<td align="left"><xref target="EE_trustedPKI" format="title"/> ove		<td align="left">Enrolling an End Entity to a Known PKI over CoAP<
	r CoAP</td>		/td>
	<td align="left">[thisRFC]</td>		<td align="left">RFC 9483, <xref target="EE_trustedPKI" format="de
			fault"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">kur</td>		<td align="left">kur</td>
	<td align="left"><xref target="EE_Update" format="title"/> over Co		<td align="left">Updating a Valid Certificate over CoAP</td>
	AP</td>		<td align="left">RFC 9483, <xref target="EE_Update" format="defaul
	<td align="left">[thisRFC]</td>		t"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">p10</td>		<td align="left">p10</td>
	<td align="left"><xref target="EE_P10" format="title"/> over CoAP<		<td align="left">Enrolling an End Entity Using a PKCS #10 Request
	/td>		over CoAP</td>
	<td align="left">[thisRFC]</td>		<td align="left">RFC 9483, <xref target="EE_P10" format="default"/
			></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">rr</td>		<td align="left">rr</td>
	<td align="left"><xref target="EE_Revoke" format="title"/> over Co		<td align="left">Revoking a Certificate over CoAP</td>
	AP</td>		<td align="left">RFC 9483, <xref target="EE_Revoke" format="defaul
	<td align="left">[thisRFC]</td>		t"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">crts</td>		<td align="left">crts</td>
	<td align="left"><xref target="EE_CACerts" format="title"/> over C		<td align="left">Get CA Certificates over CoAP</td>
	oAP</td>		<td align="left">RFC 9483, <xref target="EE_CACerts" format="defau
	<td align="left">[thisRFC]</td>		lt"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">rcu</td>		<td align="left">rcu</td>
	<td align="left"><xref target="EE_RootCAUpdate" format="title"/> o		<td align="left">Get Root CA Certificate Update over CoAP</td>
	ver CoAP</td>		<td align="left">RFC 9483, <xref target="EE_RootCAUpdate" format="
	<td align="left">[thisRFC]</td>		default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">att</td>		<td align="left">att</td>
	<td align="left"><xref target="EE_Temp" format="title"/> over CoAP		<td align="left">Get Certificate Request Template over CoAP</td>
	</td>		<td align="left">RFC 9483, <xref target="EE_Temp" format="default"
	<td align="left">[thisRFC]</td>		/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">crls</td>		<td align="left">crls</td>
	<td align="left"><xref target="EE_CRLs" format="title"/> over CoAP		<td align="left">CRL Update Retrieval over CoAP</td>
	</td>		<td align="left">RFC 9483, <xref target="EE_CRLs" format="default"
	<td align="left">[thisRFC]</td>		/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">nest</td>		<td align="left">nest</td>
	<td align="left"><xref target="RA_AddBatch" format="title"/> over		<td align="left">Batching Messages over CoAP</td>
	CoAP</td>		<td align="left">RFC 9483, <xref target="RA_AddBatch" format="defa
	<td align="left">[thisRFC]</td>		ult"/></td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>&lt; TBD: New entries must be added to the registry "CMP Wel l-Known URI Path Segments". &gt;</t>
	</section>		</section>
	<section anchor="Security" numbered="true" toc="default">		<section anchor="Security" numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>The security considerations as laid out in <xref target="RFC4210" forma		<t>The security considerations laid out in <xref target="RFC4210" format="
	t="default">CMP</xref> updated by <xref target="I-D.ietf-lamps-cmp-updates" form		default">CMP</xref> and updated by <xref target="RFC9480" format="default">CMP U
	at="default">CMP Updates</xref> and <xref target="I-D.ietf-lamps-cmp-algorithms"		pdates</xref>, <xref target="RFC9481" format="default">CMP Algorithms</xref>, <x
	format="default">CMP Algorithms</xref>, <xref target="RFC4211" format="default"		ref target="RFC4211" format="default">CRMF</xref>, <xref target="RFC9045" format
	>CRMF</xref> updated by <xref target="RFC9045" format="default">Algorithm Requir		="default">Algorithm Requirements Update</xref>, <xref target="RFC6712" format="
	ements Update</xref>, <xref target="RFC6712" format="default">CMP over HTTP</xre		default">CMP over HTTP</xref>, and <xref target="RFC9482" format="default">CMP o
	f>, and <xref target="I-D.ietf-ace-cmpv2-coap-transport" format="default">CMP ov		ver CoAP</xref> apply.</t>
	er CoAP</xref> apply.</t>		<t>Trust anchors for chain validations are often provided in the form o
	<t>Trust anchors for chain validations are often provided in the form o		f self-signed certificates. All trust anchors <bcp14>MUST</bcp14> be stored on t
	f self-signed certificates. All trust anchors MUST be stored on the device with		he device with integrity protection. In some cases, a PKI entity may not have su
	integrity protection. In some cases, a PKI entity may not have sufficient storag		fficient storage for the complete certificates. In such cases, it may only store
	e for the complete certificates. In such cases it may only store, e.g., a hash o		, e.g., a hash of each self-signed certificate and require receiving the certifi
	f each self-signed certificate and require receiving the certificate in the extr		cate in the extraCerts field, as described in <xref target="extraCerts" format="
	aCerts field as described in <xref target="extraCerts" format="default"/>. If su		default"/>. If such self-signed certificates are provided in-band in the message
	ch self-signed certificates are provided in-band in the messages, they MUST be v		s, they <bcp14>MUST</bcp14> be verified using information from the trust store o
	erified using information from the trust store of the PKI entity.</t>		f the PKI entity.</t>
	<t>For TLS using shared secret information-based authentication, both PSK		<t>For TLS using shared secret information-based authentication, both PSK
	and PAKE provide the same amount of protection against a real-time authenticatio		and PAKE provide the same amount of protection against a real-time authenticatio
	n attack which is directly the amount of entropy in the shared secret. The diffe		n attack, which is directly the amount of entropy in the shared secret. The diff
	rence between a pre-shared key (PSK) and a password-authenticated key exchange (		erence between a pre-shared key (PSK) and a password-authenticated key exchange
	PAKE) protocol is in the level of long-term confidentiality of the TLS messages		(PAKE) protocol is in the level of long-term confidentiality of the TLS messages
	against brute-force decryption, where a PSK-based cipher suite only provides sec		against brute-force decryption, where a PSK-based cipher suite only provides se
	urity according to the entropy of the shared secret, while a PAKE-based cipher s		curity according to the entropy of the shared secret, while a PAKE-based cipher
	uite provides full security independent of the entropy of the shared secret.</t>		suite provides full security independent of the entropy of the shared secret.</t
	</section>		>
	<section anchor="Acknowledgements" numbered="true" toc="default">
	<name>Acknowledgements</name>
	<t>We thank the various reviewers of this document.</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<!-- References split into informative and normative -->		<displayreference target="I-D.ietf-anima-brski-ae" to="BRSKI-AE"/>
			<displayreference target="I-D.ietf-anima-brski-prm" to="BRSKI-PRM"/>
	<!-- There are 2 ways to insert reference entries from the citation libraries		<displayreference target="I-D.ietf-netconf-sztp-csr" to="SZTP-CSR"/>
	:		<displayreference target="I-D.ietf-lamps-rfc4210bis" to="PKIX-CMP"/>
	1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (		<displayreference target="I-D.ietf-lamps-rfc6712bis" to="HTTP-CMP"/>
	as shown)
	2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml
	"?> here
	(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x
	ml")
	Both are cited textually in the same manner: by using xref elements.
	If you use the PI option, xml2rfc will, by default, try to find included fil
	es in the same
	directory as the including file. You can also define the XML_LIBRARY environ
	ment variable
	with a value containing a set of directories to search. These can be either
	in the local
	filing system or remote ones accessed by http (http://domain/dir/... ).-->
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
	C.2119.xml"?-->		19.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refe		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	rence.RFC.2119.xml"/>		986.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	FC.2986.xml"/>		210.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	FC.4210.xml"/>		211.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	FC.4211.xml"/>		280.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	FC.5280.xml"/>		652.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	FC.5652.xml"/>		958.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	FC.5958.xml"/>		712.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	FC.6712.xml"/>		174.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RF
	FC.8174.xml"/>		C.8615.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refe		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	rence.RFC.8615.xml"/>		933.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	FC.8933.xml"/>		045.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	FC.9045.xml"/>		110.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	FC.9110.xml"/>		325.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.9325.xml"/>		<reference anchor="RFC9480" target="https://www.rfc-editor.org/info/rfc9480">
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-la		<front>
	mps-cmp-updates.xml"/>		<title>Certificate Management Protocol (CMP) Updates</title>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-la		<author fullname="Hendrik Brockhaus" initials="H." surname="Brockhaus">
	mps-cmp-algorithms.xml"/>		<organization>Siemens</organization>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ac		</author>
	e-cmpv2-coap-transport.xml"/>		<author fullname="David von Oheimb" initials="D." surname="von Oheimb">
			<organization>Siemens</organization>
			</author>
			<author fullname="John Gray" initials="J." surname="Gray">
			<organization>Entrust</organization>
			</author>
			<date month="October" year="2023"/>
			</front>
			<seriesInfo name="RFC" value="9480"/>
			<seriesInfo name="DOI" value="10.17487/RFC9480"/>
			</reference>
			<reference anchor="RFC9481" target="https://www.rfc-editor.org/info/rfc9481">
			<front>
			<title>Certificate Management Protocol (CMP) Algorithms</title>
			<author fullname="Hendrik Brockhaus" initials="H." surname="Brockhaus">
			<organization>Siemens AG</organization>
			</author>
			<author fullname="Hans Aschauer" initials="H." surname="Aschauer">
			<organization>Siemens AG</organization>
			</author>
			<author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
			<organization>Entrust</organization>
			</author>
			<author fullname="John Gray" initials="J." surname="Gray">
			<organization>Entrust</organization>
			</author>
			<date month="October" year="2023"/>
			</front>
			<seriesInfo name="RFC" value="9481"/>
			<seriesInfo name="DOI" value="10.17487/RFC9481"/>
			</reference>
			<reference anchor="RFC9482" target="https://www.rfc-editor.org/info/rfc9482">
			<front>
			<title>
			Constrained Application Protocol (CoAP) Transfer for the Certificate Management
			Protocol
			</title>
			<author fullname="Mohit Sahni" initials="M." surname="Sahni" role="editor">
			<organization>Palo Alto Networks</organization>
			</author>
			<author fullname="Saurabh Tripathi" initials="S." surname="Tripathi" role="edito
			r">
			<organization>Palo Alto Networks</organization>
			</author>
			<date month="October" year="2023"/>
			</front>
			<seriesInfo name="RFC" value="9482"/>
			<seriesInfo name="DOI" value="10.17487/RFC9482"/>
			</reference>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	C.2119.xml"?-->		647.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	FC.3647.xml"/>		246.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	FC.5246.xml"/>		753.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	FC.5753.xml"/>		030.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	FC.7030.xml"/>		252.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	FC.7252.xml"/>		366.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	FC.8366.xml"/>		446.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	FC.8446.xml"/>		551.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	FC.8551.xml"/>		572.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	FC.8572.xml"/>		649.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	FC.8649.xml"/>		995.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.8995.xml"/>		<reference anchor="I-D.ietf-anima-brski-ae" target="https://datatracker.ietf.org
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-an		/doc/html/draft-ietf-anima-brski-ae-05">
	ima-brski-ae.xml"/>		<front>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-an		<title>
	ima-brski-prm.xml"/>		BRSKI-AE: Alternative Enrollment Protocols in BRSKI
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ne		</title>
	tconf-sztp-csr.xml"/>		<author fullname="David von Oheimb" initials="D." surname="von Oheimb">
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-la		<organization>Siemens AG</organization>
	mps-rfc4210bis.xml"/>		</author>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-la		<author fullname="Steffen Fries" initials="S." surname="Fries">
	mps-rfc6712bis.xml"/>		<organization>Siemens AG</organization>
	<!-- A reference written by an organization not a person. -->		</author>
			<author fullname="Hendrik Brockhaus" initials="H." surname="Brockhaus">
			<organization>Siemens AG</organization>
			</author>
			<date day="28" month="June" year="2023"/>
			</front>
			<seriesInfo name="Internet-Draft" value="draft-ietf-anima-brski-ae-05"/>
			</reference>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ani
			ma-brski-prm.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-net
			conf-sztp-csr.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lam
			ps-rfc4210bis.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
			ietf-lamps-rfc6712bis.xml"/>
	<reference anchor="NIST.CSWP.04162018" target="http://nvlpubs.nis t.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf">		<reference anchor="NIST.CSWP.04162018" target="http://nvlpubs.nis t.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf">
	<front>		<front>
	<title>Framework for Improving Critical Infrastru		<title>Framework for Improving Critical Infrastructure Cybers
	cture Cybersecurity, Version 1.1</title>		ecurity</title>
	<author>		<author>
	<organization>National Institute of Stand		<organization>National Institute of Standards and Technolog
	ards and Technology (NIST)</organization>		y (NIST)</organization>
	</author>		</author>
	<date year="2018" month="April"/>		<date year="2018" month="April"/>
	</front>		</front>
	<seriesInfo name="NIST" value="NIST.CSWP.04162018"/>		<refcontent>Version 1.1</refcontent>
	<seriesInfo name="DOI" value="10.6028/NIST.CSWP.04162018"		<seriesInfo name="DOI" value="10.6028/NIST.CSWP.04162018"/>
	/>
	</reference>		</reference>
	<reference anchor="NIST.SP.800-57p1r5" target="https://doi.org/10 .6028/NIST.SP.800-57pt1r5">		<reference anchor="NIST.SP.800-57p1r5" target="https://doi.org/10 .6028/NIST.SP.800-57pt1r5">
	<front>		<front>
	<title>Recommendation for key management, part 1		<title>Recommendation for Key Management: Part 1 - General</t
	:general</title>		itle>
	<author initials="E B" surname="Barker" fullname=		<author initials="E" surname="Barker" fullname="Elaine Barker
	"E B Barker">		">
	<organization/>		<organization/>
	</author>		</author>
	<date year="2020"/>		<date year="2020" month="May"/>
	</front>		</front>
	<seriesInfo name="NIST" value="NIST.SP.800-57pt1r5"/>		<seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
	<seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5
	"/>
	</reference>		</reference>
	<reference anchor="IEEE.802.1AR_2018" target="https://ieeexplore.ieee.o
	rg/document/8423794">		<reference anchor="IEEE.802.1AR_2018" target="https://ieeexplore.
			ieee.org/document/8423794">
	<front>		<front>
	<title>IEEE Standard for Local and metropolitan area netw		<title>IEEE Standard for Local and Metropolitan Area Networks -
	orks - Secure Device Identity</title>		Secure Device Identity</title>
	<author>		<author>
	<organization>IEEE</organization>		<organization>IEEE</organization>
	</author>		</author>
	<date day="2" month="August" year="2018"/>		<date month="August" year="2018"/>
	</front>		</front>
	<seriesInfo name="IEEE" value="802.1AR-2018"/>		<seriesInfo name="IEEE Std" value="802.1AR-2018"/>
	<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8423794"/>		<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8423794"/>
	</reference>		</reference>
	<reference anchor="ETSI-3GPP.33.310" target="http://www.3gpp.org/ ftp/Specs/html-info/33310.htm">		<reference anchor="ETSI-3GPP.33.310" target="http://www.3gpp.org/ ftp/Specs/html-info/33310.htm">
	<front>		<front>
	<title>Network Domain Security (NDS); Authenticat		<title>Network Domain Security (NDS); Authentication Framewor
	ion Framework (AF)</title>		k (AF)</title>
	<author>		<author>
	<organization>3GPP</organization>		<organization>3GPP</organization>
	</author>		</author>
	<date day="16" month="December" year="2020"/>		<date month="December" year="2020"/>
	</front>		</front>
	<seriesInfo name="3GPP TS" value="33.310 16.6.0"/>		<seriesInfo name="3GPP TS" value="33.310 16.6.0"/>
	</reference>		</reference>
	<reference anchor="ETSI-EN.319411-1" target="https://www.etsi.org /deliver/etsi_en/319400_319499/31941101/01.03.01_60/en_31941101v010301p.pdf">		<reference anchor="ETSI-EN.319411-1" target="https://www.etsi.org /deliver/etsi_en/319400_319499/31941101/01.03.01_60/en_31941101v010301p.pdf">
	<front>		<front>
	<title>Electronic Signatures and Infrastructures		<title>Electronic Signatures and Infrastructures (ESI); Polic
	(ESI); Policy and security requirements for Trust Service Providers issuing cert		y and security requirements for Trust Service Providers issuing certificates; Pa
	ificates; Part 1: General requirements</title>		rt 1: General requirements</title>
	<author>		<author>
	<organization>ETSI</organization>		<organization>ETSI</organization>
	</author>		</author>
	<date month="May" year="2021"/>		<date month="May" year="2021"/>
	</front>		</front>
	<seriesInfo name="ETSI EN" value="319 411-1 V1.3.1"/>		<seriesInfo name="ETSI EN" value="319 411-1"/>
			<refcontent>V1.3.1</refcontent>
	</reference>		</reference>
	<reference anchor="UNISIG.Subset-137" target="https://www.era.europa.eu/
	sites/default/files/filesystem/ertms/ccs_tsi_annex_a_-_mandatory_specifications/		<reference anchor="UNISIG.Subset-137" target="https://www.era.eur
	set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-_subset-137_v100.pdf">		opa.eu/system/files/2023-01/sos3_index083_-_subset-137_v100.pdf">
	<front>		<front>
	<title>Subset-137; ERTMS/ETCS On-line Key Management FFFIS; V1.0.0</		<title>ERTMS/ETCS On-line Key Management FFFIS</title>
	title>		<author>
	<author>		<organization>UNISIG</organization>
	<organization>UNISIG</organization>		</author>
	</author>		<date month="December" year="2015"/>
	<date month="December" year="2015"/>		</front>
	</front>		<refcontent>Subset-137, V1.0.0</refcontent>
	</reference>		</reference>
	<reference anchor="IEC.62443-3-3" target="https://webstore.iec.ch/public ation/7033">		<reference anchor="IEC.62443-3-3" target="https://webstore.iec.ch/public ation/7033">
	<front>		<front>
	<title>Industrial communication networks - Network and system securi ty - Part 3-3: System security requirements and security levels</title>		<title>Industrial communication networks - Network and system securi ty - Part 3-3: System security requirements and security levels</title>
	<author>		<author>
	<organization>IEC</organization>		<organization>IEC</organization>
	</author>		</author>
	<date month="August" year="2013"/>		<date month="August" year="2013"/>
	</front>		</front>
	<seriesInfo name="IEC" value="62443-3-3"/>		<seriesInfo name="IEC" value="62443-3-3:2013"/>
	</reference>		</reference>
	</references>		</references>
	</references>		</references>
	<section anchor="Param_Example" numbered="true" toc="default">		<section anchor="Param_Example" numbered="true" toc="default">
	<name>Example CertReqTemplate</name>		<name>Example CertReqTemplate</name>
	<t keepWithNext="true">Suppose the server requires that the certTemplate c ontains</t>		<t keepWithNext="true">Suppose the server requires that the certTemplate c ontains:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>the issuer field with a value to be filled in by the EE,</li>		<li>the issuer field with a value to be filled in by the EE,</li>
	<li>the subject field with a common name to be filled in by the EE and t wo organizational unit fields with given values "myDept" and "myGroup",</li>		<li>the subject field with a common name to be filled in by the EE and t wo organizational unit fields with given values "myDept" and "myGroup",</li>
	<li>the publicKey field contains an ECC key on curve secp256r1 or an RSA public key of length 2048,</li>		<li>the publicKey field contains an Elliptic Curve Cryptography (ECC) ke y on curve secp256r1 or an RSA public key of length 2048,</li>
	<li>the subjectAltName extension with DNS name "www.myServer.com" and an IP address to be filled in,</li>		<li>the subjectAltName extension with DNS name "www.myServer.com" and an IP address to be filled in,</li>
	<li>the keyUsage extension marked critical with the value digitalSignatu re and keyAgreement, and</li>		<li>the keyUsage extension marked critical with the value digitalSignatu re and keyAgreement, and</li>
	<li>the extKeyUsage extension with values to be filled in by the EE.</li >		<li>the extKeyUsage extension with values to be filled in by the EE.</li >
	</ul>		</ul>
	<t keepWithNext="true">Then the infoValue with certTemplate and keySpec fi elds returned to the EE will be encoded as follows:</t>		<t keepWithNext="true">Then the infoValue with certTemplate and keySpec fi elds returned to the EE will be encoded as follows:</t>
	<artwork align="left" name="Example_CertReqTemplate" type="" alt=""><![CDA TA[		<artwork align="left" name="" type="" alt=""><![CDATA[
	SEQUENCE {		SEQUENCE {
	SEQUENCE {		SEQUENCE {
	[3] {		[3] {
	SEQUENCE {}		SEQUENCE {}
	}		}
	[5] {		[5] {
	SEQUENCE {		SEQUENCE {
	SET {		SET {
	SEQUENCE {		SEQUENCE {
	OBJECT IDENTIFIER commonName (2 5 4 3)		OBJECT IDENTIFIER commonName (2 5 4 3)
	skipping to change at line 2812 ¶		skipping to change at line 2864 ¶
	}		}
	}		}
	SEQUENCE {		SEQUENCE {
	OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12)		OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12)
	INTEGER 2048		INTEGER 2048
	}		}
	}		}
	}		}
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="History" numbered="true" toc="default">		<section anchor="Acknowledgements" numbered="false" toc="default">
	<name>History of Changes</name>		<name>Acknowledgements</name>
	<t>Note: This appendix will be deleted in the final version of the documen		<t>We thank the various reviewers of this document.</t>
	t.</t>
	<t keepWithNext="true">From version 20 -&gt; 21:</t>
	<ul spacing="compact">
	<li>Addressed comment from Murray checking each usage of key word "SH
	OULD" and changing it to "MUST", "MAY", or "should" where needed or adding an ex
	planation how interoperability may be affected (see thread "Murray Kucherawy's N
	o Objection on draft-ietf-lamps-lightweight-cmp-profile-18: (with COMMENT)")</li
	>
	<li>Some minor editorial changes</li>
	</ul>
	<t keepWithNext="true">From version 19 -&gt; 20:</t>
	<ul spacing="compact">
	<li>Addressed comment from John (see thread "[IANA #1261900] expert r
	eview for draft-ietf-lamps-lightweight-cmp-profile (cmp)")</li>
	</ul>
	<t keepWithNext="true">From version 18 -&gt; 19:</t>
	<ul spacing="compact">
	<li>Addressed comment from Murray, moving section 'Convention and Ter
	minology' after Section 1.1 and adding a paragraph on the use of key word "SHOUL
	D", moving section 'Compatibility with Existing CMP Profiles' right before secti
	on 'Use of CMP in SZTP and BRSKI Environments', and adding a paragraph to sectio
	n 'Scope of this Document' also clarifying the use of key word "SHOULD" (see thr
	ead "Murray Kucherawy's No Objection on draft-ietf-lamps-lightweight-cmp-profile
	-18: (with COMMENT)")</li>
	<li>Updated Section 4.1.6 to reflect the changes to CMP Updates on gu
	idance which CMS key management technique to use with central key management (se
	e thread "CMS: selection of key management technique to use for EnvelopedData")
	and removed normative language regarding which key management technique to suppo
	rt</li>
	</ul>
	<t keepWithNext="true">From version 17 -&gt; 18:</t>
	<ul spacing="compact">
	<li>Addressed comment from Paul (see thread "Paul Wouters' Yes on dra
	ft-ietf-lamps-lightweight-cmp-profile-16: (with COMMENT)")</li>
	<li>Updated Section 4.3.4 with one minor correction and one clarifica
	tion (see thread "Minor change to draft-ietf-lamps-lightweight-cmp-profile-17 on
	Section 4.3.4 CRL Update Retrieval")</li>
	</ul>
	<t keepWithNext="true">From version 16 -&gt; 17:</t>
	<ul spacing="compact">
	<li>Addressed comment from Paul (see thread "Paul Wouters' Yes on dra
	ft-ietf-lamps-lightweight-cmp-profile-16: (with COMMENT)")</li>
	<li>Addressed comment from Robert (see thread “Robert Wilton’s No Obj
	ection on draft-ietf-lamps-lightweight-cmp-profile-16: (with COMMENT)")</li>
	</ul>
	<t keepWithNext="true">From version 15 -&gt; 16:</t>
	<ul spacing="compact">
	<li>Addressed comment from Warren (see thread "Warren Kumari's No Rec
	ord on draft-ietf-lamps-lightweight-cmp-profile-15: (with COMMENT)")</li>
	<li>Addressed comment from Sheng (see thread "Intdir telechat review
	of draft-ietf-lamps-lightweight-cmp-profile-15")</li>
	<li>Addressed comment from Niklas (see thread "Iotdir telechat review
	of draft-ietf-lamps-lightweight-cmp-profile-15")</li>
	<li>Addressed comment from Erik (see thread "Erik Kline's No Objectio
	n on draft-ietf-lamps-lightweight-cmp-profile-15: (with COMMENT)")</li>
	<li>Streamlined wording in two ASN.1 comments</li>
	</ul>
	<t keepWithNext="true">From version 14 -&gt; 15:</t>
	<ul spacing="compact">
	<li>Added a reference to HashOfRootKey extension to note in Section 3
	.3</li>
	<li>Addressed comment from Joel (see thread "Genart last call review
	of draft-ietf-lamps-lightweight-cmp-profile-14")</li>
	<li>Addressed comment from Robert (see thread "Artart last call revie
	w of draft-ietf-lamps-lightweight-cmp-profile-14")</li>
	</ul>
	<t keepWithNext="true">From version 13 -&gt; 14:</t>
	<ul spacing="compact">
	<li>Addressed comments from AD Evaluation (see thread "AD Review of d
	raft-ietf-lamps-lightweight-cmp-profile-13")</li>
	<li>Added a note to Section 1 informing about rfc4210bis and rfc6712b
	is activity</li>
	<li>Added support for constrained PKI entities that can, e.g., only s
	tore a hash of a self-signed certificate as trust anchor and require the self-si
	gned certificate to be provided in-line in extraCerts, see Section 3.3 and Secti
	on 9</li>
	<li>Addressed idnits feedback, specifically changing the followin
	g RFC reference: RFC3278 -> RFC5753</li>
	</ul>
	<t keepWithNext="true">From version 12 -&gt; 13:</t>
	<ul spacing="compact">
	<li>Some minor clarifications regarding 'exactly one element' -> 'seq
	uence of one element'</li>
	<li>Adding authors contact details</li>
	</ul>
	<t keepWithNext="true">From version 11 -&gt; 12:</t>
	<ul spacing="compact">
	<li>Added a note to Section 4.1.6 to clarify the combination of centr
	al key generation with certificate update</li>
	<li>Updated Section 4.3.4 for clarification that only one CRL per rou
	nd-trip is requested</li>
	<li>Updated Section 7.1 to fix a wrong change from the last update in
	the first two rows of Table 3</li>
	</ul>
	<t keepWithNext="true">From version 10 -&gt; 11:</t>
	<ul spacing="compact">
	<li>Updated Section 3.2, 3.5, and 3.6.4 to define more clearly signat
	ure-based protection as the default and the exception for not protecting error m
	essages as mentioned at IETF 113</li>
	<li>Streamlined headlines in Section 4.1</li>
	<li>Updates Section 6.1 and Section 6.2 regarding new well-known path
	segment for profile labels as discussed during IETF 113</li>
	<li>Updated Section 7.1. on the support of PKI management operations
	required for EEs, RAs, and CAs as mentioned at IETF 113</li>
	<li>Updates Section 8 adding well-known path segments on PKI manageme
	nt operations to be used with HTTP and CoAP</li>
	<li>Capitalized all headlines</li>
	</ul>
	<t keepWithNext="true">From version 09 -&gt; 10:</t>
	<ul spacing="compact">
	<li>Resolved some nits reported by I-D nit checker tool</li>
	<li>Resolve some wording issues</li>
	</ul>
	<t keepWithNext="true">From version 08 -&gt; 09:</t>
	<ul spacing="compact">
	<li>Updated Section 1.1 and 1.2 and converted Section 2.2 and 2.3 int
	o more detailed tables in Section 7 (see thread "WG Last Call for draft-ietf-lam
	ps-cmp-updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08")</li>
	<li>Updated Section 3.1 and 4.1.1 making implicitConfirm recommended for
	ir/cr/p10cr/kur and providing further recommendations on its use (see thread "c
	ertConf - WG Last Call for draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-
	lightweight-cmp-profile-08")</li>
	<li>Updated Section 4.1.6 adding some clarifications regarding valida
	ting the authorization of centrally generated keys</li>
	<li>Updated Section 4.3.4 adding some clarifications on CRL update retri
	eval (see thread "CRL update retrieval - WG Last Call for draft-ietf-lamps-cmp-u
	pdates-14 and draft-ietf-lamps-lightweight-cmp-profile-08")</li>
	<li>Updated references to CMP Updates pointing to concrete sections (
	see thread "CRL update retrieval - WG Last Call for draft-ietf-lamps-cmp-updates
	-14 and draft-ietf-lamps-lightweight-cmp-profile-08"))</li>
	<li>Corrected a couple of nits elsewhere</li>
	</ul>
	<t keepWithNext="true">From version 07 -&gt; 08:</t>
	<ul spacing="compact">
	<li>Updates Section 4.1.6.1. regarding content of the originator and
	keyEncryptionAlgorithm fields (see thread "AD review of draft-ietf-lamps-cmp-alg
	orithms-07")</li>
	<li>Rolled back part of the changes on root CA certificate updates in Se
	ction 4.3.2 (see thread "Allocation of OIDs for CRL update retrieval (draft-ietf
	-lamps-cmp-updates-13)")</li>
	</ul>
	<t keepWithNext="true">From version 06 -&gt; 07:</t>
	<ul spacing="compact">
	<li>Added references to [draft-ietf-netconf-sztp-csr] in new Section
	1.5 and Section 4.1.4</li>
	<li>Added reference to [I-D.ietf-anima-brski-ae] in new Section 1.5 and
	Section 4.1.1</li>
	<li>Changed reference in Section 2 to [I-D.ietf-anima-brski-prm] as the
	PUSH use case is continued to be discussed in this draft after the split of BRSK
	I-AE</li>
	<li>Improved note regarding UNISIG Subset-137 in Section 1.6</li>
	<li>Removed "rootCaCert" in Section 3.1 and updated the structure of the
	genm request for root CA certificate updates in Section 4.3.2.</li>
	<li>Simplified handling of sender and recipient nonces in case of delaye
	d delivery in Sections 3.1, 3.5, 4.4, and 5.1.2</li>
	<li>Changed the order of Sections 4.1.4 and 4.1.5</li>
	<li>Added reference on RFC 8933 regarding CMS signedAttrs to Section 4.1
	.6</li>
	<li>Added Section 4.3.4 on CRL update retrieval</li>
	<li>Generalized delayed enrollment to delayed delivery in Section 4.4 an
	d 5.1.2, updated the state machine in the introduction of Section 4</li>
	<li>Updated Section 6 regarding delayed message transfer</li>
	<li>Changed file name extension from ".PKI" to ".pki", deleted operation
	al path for central key generation, and added an operational path for CRL update
	retrieval in Sections 6.1 and 6.2</li>
	<li>Shifted many security considerations to CMP Updates</li>
	<li>Replaced the term "transport" by "transfer" where appropriate to pre
	vent confusion regarding TCP vs. HTTP and CoAP</li>
	<li>Various editorial changes and language corrections</li>
	</ul>
	<t keepWithNext="true">From version 05 -&gt; 06:</t>
	<ul spacing="compact">
	<li>Changed in Section 2.3 the normative requirement in of adding pro
	tection to a single message to mandatory and replacing protection to optional</l
	i>
	<li>Added Section 3.4 specifying generic prerequisites to PKI management
	operations</li>
	<li>Added Section 3.5 specifying generic message validation</li>
	<li>Added Section 3.6 on generic error reporting. This section replaces
	the former error handling section from Section 4 and 5.</li>
	<li>Added reference to using hashAlg</li>
	<li>Updates Section 4.3.2 and Section 4.3.3 to align with CMP Updates</l
	i>
	<li>Added Section 5.1 specifying the behavior of PKI management entities
	when responding to requests</li>
	<li>Reworked Section 5.2.3. on usage of nested messages</li>
	<li>Updates Section 5.3 on performing PKI management operation on behalf
	of another entity</li>
	<li>Updates Section 6.2 on HTTPS transport of CMP messages as discusses
	at IETF 110 and email thread "I-D Action: draft-ietf-lamps-lightweight-cmp-profi
	le-05.txt"</li>
	<li>Added CoAP endpoints to Section 6.4</li>
	<li>Added security considerations on usage of shared secret information<
	/li>
	<li>Updated the example in Appendix A</li>
	<li>Added newly registered OIDs to the example in Appendix A</li>
	<li>Updated new RFC numbers for I-D.ietf-lamps-crmf-update-algs</li>
	<li>Multiple language corrections, clarifications, and changes in wordin
	g</li>
	</ul>
	<t keepWithNext="true">From version 04 -&gt; 05:</t>
	<ul spacing="compact">
	<li>Changed to XML V3</li>
	<li>Added algorithm names introduced in CMP Algorithms Section 7.3 to Se
	ction 4 of this document</li>
	<li>Updates Syntax in Section 4.4.3 due to changes made in CMP Updates</
	li>
	<li>Deleted the text on HTTP-based discovery as discussed in Section 6.1
	</li>
	<li>Updates Appendix A due to change syntax in Section 4.4.3</li>
	<li>Many clarifications and changes in wording thanks to David's extensi
	ve review</li>
	</ul>
	<t keepWithNext="true">From version 03 -&gt; 04:</t>
	<ul spacing="compact">
	<li>Deleted normative text sections on algorithms and refer to CMP Algor
	ithms and CRMF Algorithm Requirements Update instead</li>
	<li>Some clarifications and changes in wording</li>
	</ul>
	<t keepWithNext="true">From version 02 -&gt; 03:</t>
	<ul spacing="compact">
	<li>Updated the interoperability with [UNISIG.Subset-137] in Section 1.4
	.</li>
	<li>Changed Section 2.3 to a tabular layout to enhanced readability</li>
	<li>Added a ToDo to section 3.1 on aligning with the CMP Algorithms draf
	t that will be set up as decided in IETF 108</li>
	<li>Updated section 4.1.6 to add the AsymmetricKey Package structure to
	transport a newly generated private key as decided in IETF 108</li>
	<li>Added a ToDo to section 4.1.7 on required review of the nonce handli
	ng in case an offline LRA responds and not forwards the pollReq messages</li>
	<li>Updated Section 4 due to the definition of the new ITAV OIDs in CMP
	Updates</li>
	<li>Updated Section 4.4.4 to utilize controls instead of rsaKeyLen (see
	thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen")</li>
	<li>Deleted the section on definition and discovery of HTTP URIs and cop
	ied the text to the HTTP transport section and to CMP Updates section 3.2</li>
	<li>Added some explanation to Section 5.1.2 and Section 5.1.3 on using n
	ested messages when a protection by the RA is required.</li>
	<li>Deleted the section on HTTP URI definition and discovery as some con
	tent was moved to CMP Updates. The rest of the content was moved back to the HTT
	P transport section</li>
	<li>Deleted the ASN.1 module after moving the new OIDs id-it-caCerts, id
	-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates</li>
	<li>Minor changes in wording and addition of some open ToDos</li>
	</ul>
	<t keepWithNext="true">From version 01 -&gt; 02:</t>
	<ul spacing="compact">
	<li>Extend <xref target="Compatibility" format="default"/> with regard t
	o conflicts with UNISIG Subset-137.</li>
	<li>Minor clarifications on extraCerts in <xref target="extraCerts" form
	at="default"/> and <xref target="EE_newPKI" format="default"/>.</li>
	<li>Complete specification of requesting a certificate from a trusted PK
	I with signature protection in <xref target="EE_trustedPKI" format="default"/>.<
	/li>
	<li>Changed from symmetric key-encryption to password-based key manageme
	nt technique in <xref target="EE_KGPB" format="default"/> as discussed on the m
	ailing list (see thread "draft-ietf-lamps-lightweight-cmp-profile-01, section 5.
	1.6.1")</li>
	<li>Changed delayed enrollment described in <xref target="EE_Polling" fo
	rmat="default"/> from recommended to optional as decided at IETF 107</li>
	<li>Introduced the new RootCAKeyUpdate structure for root CA certificate
	update in <xref target="EE_RootCAUpdate" format="default"/> as decided at IETF
	107 (also see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, section
	5.4.3")</li>
	<li>Extend the description of the CertReqTemplate PKI management operati
	on, including an example added in the Appendix. Keep rsaKeyLen as a single inte
	ger value in <xref target="EE_Temp" format="default"/> as discussed on the maili
	ng list (see thread "draft-ietf-lamps-lightweight-cmp-profile-01, section 5.4.4"
	)</li>
	<li>Deleted Sections "Get certificate management configuration" and "Get
	enrollment voucher" as decided at IETF 107</li>
	<li>Complete specification of adding an additional protection by an PKI
	management entity in <xref target="RA_Add" format="default"/>.</li>
	<li>Added a section on HTTP URI definition and discovery and extended <x
	ref target="HTTP" format="default"/> on definition and discovery of supported HT
	TP URIs and content types, add a path for nested messages as specified in <xref
	target="RA_Add" format="default"/> and delete the paths for /getCertMgtConfig an
	d /getVoucher</li>
	<li>Changed <xref target="Offline" format="default"/> to address offline
	transport and added more detailed specification file-based transport of CMP</li
	>
	<li>Added a reference to the new I-D of Mohit Sahni on "CoAP Transport f
	or CMPV2" in <xref target="CoAP" format="default"/>; thanks to Mohit supporting
	the effort to ease utilization of CMP</li>
	<li>Moved the change history to the Appendix</li>
	<li>Minor changes in wording</li>
	</ul>
	<t keepWithNext="true">From version 00 -&gt; 01:</t>
	<ul spacing="compact">
	<li>
	<t>Harmonize terminology with <xref target="RFC4210" format="default">
	CMP</xref>, e.g.,</t>
	<ul spacing="compact">
	<li>transaction, message sequence, exchange, use case -&gt; PKI mana
	gement operation</li>
	<li>PKI component, (L)RA/CA -&gt; PKI management entity</li>
	</ul>
	</li>
	<li>Minor changes in wording</li>
	</ul>
	<t keepWithNext="true">From draft-brockhaus-lamps-lightweight-cmp-profile-
	03 -&gt; draft-ietf-lamps-lightweight-cmp-profile-00:</t>
	<ul spacing="compact">
	<li>Changes required to reflect WG adoption</li>
	<li>Minor changes in wording</li>
	</ul>
	<t keepWithNext="true">From version 02 -&gt; 03:</t>
	<ul spacing="compact">
	<li>Added a short summary of <xref target="RFC4210" format="default"/> A
	ppendix D and E in <xref target="Existing_profiles" format="default"/>.</li>
	<li>Clarified some references to different sections and added some clari
	fication in response to feedback from Michael Richardson and Tomas Gustavsson.</
	li>
	<li>Added an additional label to the operational path to address multipl
	e CAs or certificate profiles in <xref target="HTTP" format="default"/>.</li>
	</ul>
	<t keepWithNext="true">From version 01 -&gt; 02:</t>
	<ul spacing="compact">
	<li>Added some clarification on the key management techniques for protec
	tion of centrally generated keys in <xref target="EE_centralKeyGeneration" forma
	t="default"/>.</li>
	<li>Added some clarifications on the certificates for root CA certificat
	e update in <xref target="EE_RootCAUpdate" format="default"/>.</li>
	<li>Added a section to specify the usage of nested messages for RAs to a
	dd an additional protection for further discussion, see <xref target="RA_Add" fo
	rmat="default"/>.</li>
	<li>Added a table containing endpoints for HTTP transport in <xref targe
	t="HTTP" format="default"/> to simplify addressing PKI management entities.</li>
	<li>Added some ToDos resulting from discussion with Tomas Gustavsson.</l
	i>
	<li>Minor clarifications and changes in wording.</li>
	</ul>
	<t keepWithNext="true">From version 00 -&gt; 01:</t>
	<ul spacing="compact">
	<li>Added a section to specify the enrollment with an already trusted PK
	I for further discussion, see <xref target="EE_trustedPKI" format="default"/>.</
	li>
	<li>Complete specification of requesting a certificate from a legacy PKI
	using a <xref target="RFC2986" format="default">PKCS#10</xref> request in <xref
	target="EE_P10" format="default"/>.</li>
	<li>Complete specification of adding central generation of a key pair on
	behalf of an end entity in <xref target="EE_centralKeyGeneration" format="defau
	lt"/>.</li>
	<li>Complete specification of handling delayed enrollment due to asynchr
	onous message delivery in <xref target="EE_Polling" format="default"/>.</li>
	<li>Complete specification of additional support messages, e.g., to upda
	te a Root CA certificate or to request an <xref target="RFC8366" format="default
	">RFC&nbsp;8366</xref> voucher, in <xref target="EE_GeneralMessage" format="defa
	ult"/>.</li>
	<li>Minor changes in wording.</li>
	</ul>
	<t keepWithNext="true">From draft-brockhaus-lamps-industrial-cmp-profile-0
	0 -&gt; draft-brockhaus-lamps-lightweight-cmp-profile-00:</t>
	<ul spacing="compact">
	<li>Change focus from industrial to more multi-purpose use cases and lig
	htweight CMP profile.</li>
	<li>Incorporate the omitted confirmation into the header specified in <x
	ref target="Header" format="default"/> and described in the standard enrollment
	use case in <xref target="EE_newPKI" format="default"/> due to discussion with T
	omas Gustavsson.</li>
	<li>Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's e
	ntities certificate' in <xref target="RA_on-behalf_revoke" format="default"/>, b
	ecause it is regarded as important functionality in many environments to enable
	the management station to revoke EE certificates.</li>
	<li>Complete the specification of the revocation message flow in <xref t
	arget="EE_Revoke" format="default"/> and <xref target="RA_on-behalf_revoke" form
	at="default"/>.</li>
	<li>The CoAP based transport mechanism and piggybacking of CMP messages
	on top of other reliable transport protocols is out of scope of this document an
	d would need to be specified in another document.</li>
	<li>Further minor changes in wording.</li>
	</ul>
	</section>		</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 398 change blocks.
	2433 lines changed or deleted		2176 lines changed or added
This html diff was produced by rfcdiff 1.48.