<?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 [
  <!-- declare nbsp and friends -->
 <!ENTITY nbsp "&#xa0;">    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy "&#x2011;">   "&#8209;">
 <!ENTITY wj "&#x2060;">
]><?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 -->     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
	category="std"
	consensus="true"
	number="9483"
	docName="draft-ietf-lamps-lightweight-cmp-profile-21"
	ipr="trust200902"
	obsoletes=""
	updates=""
	submissionType="IETF"
	xml:lang="en"
	tocInclude="true"
	tocDepth="4"
	symRefs="true"
	sortRefs="true"
	version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title abbrev="Lightweight CMP Profile">Lightweight abbrev="LCMPP">Lightweight Certificate Management Protocol (CMP) Profile</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-lightweight-cmp-profile-21"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->
   <!-- Another author who claims to be an editor --> name="RFC" value="9483"/>
   <author fullname="Hendrik Brockhaus" initials="H." surname="Brockhaus">
      <organization abbrev="Siemens">Siemens</organization>
      <address>
        <postal>
          <street>Werner-von-Siemens-Strasse 1</street>
          <code>80333</code>
          <city>Munich</city>
          <country>Germany</country>
        </postal>
        <email>hendrik.brockhaus@siemens.com</email>
        <uri>https://www.siemens.com</uri>
      </address>
    </author>
   <author fullname="David von Oheimb" initials="D." surname="von Oheimb">
      <organization abbrev="Siemens">Siemens</organization>
      <address>
        <postal>
          <street>Werner-von-Siemens-Strasse 1</street>
          <code>80333</code>
          <city>Munich</city>
          <country>Germany</country>
        </postal>
        <email>david.von.oheimb@siemens.com</email>
        <uri>https://www.siemens.com</uri>
      </address>
    </author>
    <author fullname="Steffen Fries" initials="S." surname="Fries">
      <organization abbrev="Siemens">Siemens AG</organization>
      <address>
        <postal>
          <street>Werner-von-Siemens-Strasse 1</street>
          <code>80333</code>
          <city>Munich</city>
          <country>Germany</country>
        </postal>
        <email>steffen.fries@siemens.com</email>
        <uri>https://www.siemens.com</uri>
      </address>
    </author>
    <date year="2023"/>
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
        in the current day for you. If only the current year is specified, xml2rfc 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 specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. --> year="2023" month="October"/>
   <area>Internet</area>
    <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>
    <abstract>
      <t>This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and IoT Internet of Things (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 based on HTTP or Constrained Application Protocol (CoAP) in a succinct but sufficiently detailed and self-contained way.  To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory.  More specialized or complex use cases are supported with optional features.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="Introduction" numbered="true" toc="default">
      <name>Introduction</name>
	  <t>[RFC Editor:</t>
	  <t>Please perform the following substitution.</t>
        <ul spacing="normal">
          <li>RFCXXXX --> the assigned numerical RFC value for this draft</li>
          <li>RFCAAAA --> the assigned numerical RFC value for <xref target="I-D.ietf-lamps-cmp-updates" format="default"/></li>
          <li>RFCBBBB --> the assigned numerical RFC value for <xref target="I-D.ietf-lamps-cmp-algorithms" format="default"/></li>
		  </ul>
	  <t>Please also update the following references to associated drafts in progress to reflect their final RFC assignments, if available:</t>
        <ul spacing="normal">
          <li><xref target="I-D.ietf-lamps-cmp-updates" format="default"/></li>
          <li><xref target="I-D.ietf-lamps-cmp-algorithms" format="default"/></li>
          <li><xref target="I-D.ietf-ace-cmpv2-coap-transport" format="default"/></li>
          <li><xref target="I-D.ietf-netconf-sztp-csr" format="default"/></li>
          <li><xref target="I-D.ietf-anima-brski-ae" format="default"/></li>
          <li><xref target="I-D.ietf-anima-brski-prm" format="default"/></li>
		  </ul>
	  <t>]</t>
      <t>This document specifies PKI management operations supporting machine-to-machine and IoT use cases. Its focus is to maximize automation and interoperability between all involved PKI entities, ranging from end entities (EE) (EEs) over any number of intermediate PKI management entities entities, such as Registration Authorities (RA) registration authorities (RAs), to the CMP <xref target="RFC4210" format="default">Certificate Management Protocol (CMP)</xref> endpoints of Certification Authority certification authority (CA) systems.  This profile makes use of the concepts and syntax specified in <xref target="RFC4210" format="default">CMP</xref>, format="default">CMP</xref> <xref target="I-D.ietf-lamps-cmp-updates" format="default"/>, and target="RFC9480" format="default"/> <xref target="I-D.ietf-lamps-cmp-algorithms" target="RFC9481" format="default"/>, <xref target="RFC4211" format="default">CRMF</xref> and format="default">Certificate Request Message Format (CRMF)</xref> <xref target="RFC9045" format="default"/>, <xref target="RFC5652" format="default">CMS</xref> and format="default">Cryptographic Message Syntax (CMS)</xref> <xref target="RFC8933" format="default"/>, <xref target="RFC6712" format="default">HTTP transfer for CMP</xref>, and <xref target="I-D.ietf-ace-cmpv2-coap-transport" target="RFC9482" format="default">CoAP transfer for CMP</xref>.  CMP, CRMF CRMF, and CMS are feature-rich specifications, but most application scenarios use only a limited subset of the same specified functionality.  Additionally, the standards are not always precise enough 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 adequate detail to make the implementation of interoperable automated certificate management as straightforward and lightweight as possible.</t>
	  <t>Note: In the meantime
	  <t>While this document was being developed, documents intended to obsolete  RFC 4210 <xref target="I-D.ietf-lamps-rfc4210bis" format="default">RFC4210bis</xref> format="default"/> and RFC 6712 <xref target="I-D.ietf-lamps-rfc6712bis" format="default">RFC6712bis</xref> drafts format="default"/> were submitted incorporating posted, and they include the full set of changes listed described in <xref target="I-D.ietf-lamps-cmp-updates" target="RFC9480" format="default">CMP Updates</xref> into the original RFC text.</t> Updates</xref>.</t>
      <section anchor="How_to_read" numbered="true" toc="default">
        <name>How to Read This Document</name>
		<t>This document has become longer than the authors would have liked it to be.  Yet apart from studying <xref target="GenericParts" format="default"/>, which contains general requirements, the reader does not have to work through the whole document.  The guidance in Sections <xref target="Structure" format="counter"/> and <xref target="Conformity" format="counter"/> should be used to figure out which parts of Sections <xref target="EE_UseCases" format="default"/> format="counter"/> to <xref target="Transfer_types" format="default"/> format="counter"/> are relevant for the target certificate management solution solution, depending on the PKI management operations, their variants, and types of message transfer needed.</t>
		<t>Since conformity to this document can be achieved by implementing only the functionality declared mandatory in <xref target="Conformity" format="default"/>, the profile can still be called lightweight because because, in particular for end entities entities, the mandatory-to-implement set of features is rather limited.</t>
      </section>
      <section anchor="Convention_Terminology" numbered="true" toc="default">
        <name>Conventions and Terminology</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here.</t>
		<t>The key word term "PROHIBITED" is to be interpreted to mean that the respective ASN.1 field SHALL NOT <bcp14>SHALL NOT</bcp14> be present or used.</t>
        <t keepWithNext="true">Technical terminology is used in conformance with <xref target="RFC4210" format="default">RFC&nbsp;4210</xref>, format="default"/>, <xref target="RFC4211" format="default">RFC&nbsp;4211</xref>, format="default"/>, <xref target="RFC5280" format="default">RFC&nbsp;5280</xref>, format="default"/>, and <xref target="IEEE.802.1AR_2018" format="default">IEEE&nbsp;802.1AR</xref>. The following key words are terminology is used:</t>
        <dl newline="false" spacing="normal" indent="7">
          <dt>CA:</dt>
          <dd>Certification authority, which issues certificates.</dd>
          <dt>RA:</dt>
          <dd>Registration authority, an optional PKI component to which a CA delegates certificate management functions functions, such as end entity authentication and authorization checks for incoming requests. An RA can also provide conversion between various certificate management protocols and other protocols providing some operations related to certificate management.</dd>
          <dt>LRA:</dt>
          <dd>
	    <t>Local registration authority, a specific form of RA with proximity to the end entities.</t>
		<t>Note: For ease of reading, this document also uses the term "RA" also for LRAs in all cases where the difference is not relevant.</t>
			</dd>
          <dt>KGA:</dt>
          <dd>Key generation authority, an optional system component, typically co-located colocated with an RA or CA, that offers key generation services to end entities.</dd>
          <dt>EE:</dt>
          <dd>End entity, typically a device or service that holds a public-private key pair for which it manages a public-key public key certificate. An identifier for the EE is given as the subject of its certificate.</dd>
        </dl>
        <t keepWithNext="true">The following terminology is reused from <xref target="RFC4210" format="default">RFC&nbsp;4210</xref>, format="default"/> as follows:</t>
        <dl newline="false" spacing="normal" indent="28"> indent="29">
          <dt>PKI management operation:</dt>
          <dd>All CMP messages belonging to a single transaction.  The transaction is identified by the transactionID field of the message headers.</dd>
          <dt>PKI management entity:</dt>
          <dd>A non-EE PKI entity, i.e., an RA or a CA.</dd>
          <dt>PKI entity:</dt>
          <dd>An EE or PKI management entity.</dd>
        </dl>
		<t>CMP messages are referred to by the names of PKIBody choices defined in <xref target="RFC4210" format="default">RFC&nbsp;4210 Section 5.1.2</xref> 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 document:</t>
        <dl newline="false" spacing="normal" indent="30"> indent="29">
          <dt>CMP protection key:</dt>
          <dd>The private key used to sign a CMP message.</dd>
          <dt>CMP protection certificate:</dt>
          <dd>The certificate related to the CMP protection key.  If the keyUsage extension is present, it MUST <bcp14>MUST</bcp14> include digitalSignature.</dd>
        </dl>
      </section>
      <section anchor="Motivation" numbered="true" toc="default">
        <name>Motivation for a Lightweight Profile of CMP</name>
        <t>CMP was standardized in 1999 and is implemented in several PKI products. In 2005, a completely reworked and enhanced version 2 of <xref target="RFC4210" format="default">CMP</xref> and <xref target="RFC4211" format="default">CRMF</xref> has been published, followed by a document specifying a transfer mechanism 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="RFC4210" format="default">RFC&nbsp;4210</xref> format="default">CMP</xref> and <xref target="I-D.ietf-lamps-cmp-updates" target="RFC9480" format="default">CMP Updates</xref> offer a very large set of features and options.  On the one hand, this makes CMP applicable to a very wide range of scenarios, but scenarios; on the other hand, a full implementation supporting all options is not realistic because this would take undue effort.</t>
	<t>In order to reduce complexity, the set of mandatory PKI management operations and variants required by this specification has been kept lean.  This limits development effort efforts and minimizes resource needs, which is particularly important for memory-constrained devices.  To this end, when there was design flexibility to either have necessary complexity on the EE or in the PKI management entity, this profile chose to include it in the PKI management entities where typically more computational resources are available.  Additional recommended PKI management operations and variants support some more complex scenarios that are considered beneficial for environments with more specific demands or boundary conditions.  The optional PKI management operations support less common scenarios and requirements.</t>
        <t>Moreover, many details of the CMP protocol Certificate Management Protocol have been left open or have not been specified in full preciseness. The profiles specified in Appendices <xref target="RFC4210" format="default">Appendix D sectionFormat="bare" section="D"/> and E <xref target="RFC4210" sectionFormat="bare" section="E"/> of RFC&nbsp;4210</xref> <xref target="RFC4210" format="default"/> define some more detailed PKI management operations. Yet, Yet the specific needs of highly automated scenarios for a machine-to-machine communication are not covered sufficiently.</t>
        <t>Profiling is a way to reduce feature richness and complexity of standards to what is needed for specific use cases. 3GPP and UNISIG already use profiling of CMP as a way to cope with these challenges.  To profile means to take advantage of the strengths of the given protocol, protocol while explicitly narrowing down the options it provides to those needed for the purpose(s) at hand and eliminating all identified ambiguities. In this way way, the general aspects of the protocol are utilized and only the special requirements of the target scenarios need to be dealt with using distinct features the protocol offers.</t>
        <t>Defining a profile for a new target environment takes high effort because the range of available options needs to be well understood and the selected options need to be consistent with each other and suitably cover the intended application scenario.  Since most industrial PKI management use cases typically have much in common common, it is worth sharing this effort, which is the aim of this document.  Other standardization bodies can reference this document and further tailor the PKI management operations to their needs to avoid coming up with individual profiles from scratch.</t>
      </section>
      <section anchor="Lightweight_profile" numbered="true" toc="default">
        <name>Special Requirements of Industrial and IoT Scenarios</name>
        <t>The profiles specified in Appendices <xref target="RFC4210" format="default">Appendix D format="default" sectionFormat="bare" section="D"/> and E <xref target="RFC4210" sectionFormat="bare" section="E"/> of RFC&nbsp;4210</xref> <xref target="RFC4210"/> have been developed particularly for managing certificates of human end entities. With the evolution of distributed systems and client-server architectures, certificates for machines and applications on them have become widely used. This trend has strengthened even more in emerging industrial and IoT scenarios. CMP is sufficiently flexible to support them well.</t>
        <t>Today's IT security architectures for industrial solutions typically use certificates for endpoint authentication within protocols like IPsec, TLS, or SSH. Secure Shell (SSH). Therefore, the security of these architectures highly relies upon the security and availability of the implemented certificate management operations.</t>
        <t>Due to increasing security and availability needs in operational technology, especially when used for critical infrastructures and systems with a high number of certificates, a state-of-the-art certificate management system must be constantly available and cost-efficient, which calls for high automation and reliability. Consequently, the <xref target="NIST.CSWP.04162018" format="default">NIST Framework format="default"> "Framework for Improving Critical Infrastructure Cybersecurity</xref> Cybersecurity"</xref> refers to proper processes for issuance, management, verification, revocation, and audit for of authorized devices, users, and processes involving identity and credential management. Such PKI management operations according According to commonly accepted best practices practices, such PKI management operations are also required in <xref target="IEC.62443-3-3" format="default">IEC&nbsp;62443-3-3</xref> format="default"/> for security level 2 and higher.</t>
        <t>Further challenges in many industrial systems are network segmentation and asynchronous communication. Also, PKI management entities like Certification Authorities (CA) typically certification authorities (CAs) are not typically deployed on-site but in a highly protected data center environment, e.g., operated according to <xref target="ETSI-EN.319411-1" format="default">ETSI Policy and security requirements for Trust Service Providers issuing certificates</xref>.  Certificate management must be able to cope with such network architectures. CMP offers the required flexibility and functionality, namely authenticated self-contained messages, efficient polling, and support for asynchronous message transfer while retaining end-to-end authentication.</t>
      </section>
      <section anchor="Existing_profiles" numbered="true" toc="default">
        <name>Existing CMP Profiles</name>
        <t>As already stated, <xref target="RFC4210" format="default">RFC&nbsp;4210</xref> format="default"/> contains profiles with mandatory and optional PKI management operations in Appendix D Appendices <xref target="RFC4210" sectionFormat="bare" section="D"/> and E. <xref target="RFC4210" sectionFormat="bare" section="E"/> of <xref target="RFC4210"/>. Those profiles focus on management of human user certificates and only partly address the specific needs of certificate management automation for unattended devices or machine-to-machine application scenarios.</t>
        <t>Both Appendixes D Appendices <xref target="RFC4210" sectionFormat="bare" section="D"/> and E <xref target="RFC4210" sectionFormat="bare" section="E"/> of <xref target="RFC4210"/> focus on EE-to-RA/CA PKI management operations between an EE and an RA or CA. They do not address further profiling of RA-to-CA communication as communication, which is typically needed for full backend automation.  All requirements regarding algorithm support for Appendices <xref target="RFC4210" format="default">RFC&nbsp;4210 Appendix D format="default" sectionFormat="bare" section="D"/> and E</xref> <xref target="RFC4210" sectionFormat="bare" section="E"/> of <xref target="RFC4210"/> have been updated by <xref target="I-D.ietf-lamps-cmp-algorithms" format="default">CMP Algorithms Section 7.1</xref>.</t> target="RFC9481" format="default" sectionFormat="of" section="7.1">CMP Algorithms</xref>.</t>
        <t>3GPP makes use of <xref target="RFC4210" format="default">CMP</xref> in its <xref target="ETSI-3GPP.33.310" format="default">Technical Specification 33.310</xref> for automatic management of IPsec certificates in 3G, LTE, and 5G backbone networks. Since 2010, a dedicated CMP profile for initial certificate enrollment and certificate update operations between EE EEs and RA/CA RAs/CAs is specified in that document.</t>
        <t>UNISIG has
        <t>In 2015, UNISIG included a CMP profile for enrollment of TLS certificates in the Subset-137 specifying the <xref target="UNISIG.Subset-137" format="default">ETRAM/ETCS on-line online key management for train control systems</xref> in 2015.</t> systems</xref>.</t>
        <t>Both standardization bodies tailor <xref target="RFC4210" format="default">CMP</xref>, <xref target="RFC4211" format="default">CRMF</xref>, and <xref target="RFC6712" format="default">HTTP transfer for CMP</xref> for highly automated and reliable PKI management operations for unattended devices and services.</t>
      </section>
      <section anchor="Compatibility" numbered="true" toc="default">
        <name>Compatibility with Existing CMP Profiles</name>
        <t keepWithNext="true">The profile specified in this document is compatible with Appendices <xref target="RFC4210" format="default">RFC&nbsp;4210 Appendixes D format="default" sectionFormat="bare" section="D"/> and E (PKI Management Message Profiles)</xref>, <xref target="RFC4210" format="default" sectionFormat="bare" section="E"/> of <xref target="RFC4210"/>, with the following exceptions:</t>
        <ul spacing="normal">
          <li>signature-based protection is the default protection; an initial PKI management operation may also use MAC-based protection,</li> protection based on the message authentication code (MAC),</li>
          <li>certification of a second key pair within the same PKI management operation is not supported,</li>
          <li>proof-of-possession (POPO) (POP) with the self-signature of the certReq containing the certTemplate according (according to <xref target="RFC4211" format="default">RFC&nbsp;4211 Section 4.1</xref> format="default" sectionFormat="comma" section="4.1"/>, clause 3 3) is the recommended default POPO POP method (deviations are possible for EEs when requesting central key generation, for RAs when using raVerified, and if the newly generated keypair is technically not capable to generate digital signatures),</li>
          <li>confirmation of newly enrolled certificates may be omitted, and</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>
        <t keepWithNext="true">The profile specified in this document is compatible with the CMP profile for 3G, LTE, and 5G network domain security and authentication framework <xref target="ETSI-3GPP.33.310" format="default"/>, except that:</t>
        <ul spacing="normal">
          <li>protection of initial PKI management operations may be MAC-based,</li>
          <li>the subject field is mandatory in certificate templates, and</li>
          <li>confirmation of newly enrolled certificates may be omitted.</li>
        </ul>
        <t keepWithNext="true">The profile specified in this document is compatible with the CMP profile for on-line online key management in rail networks as specified in <xref target="UNISIG.Subset-137" format="default">UNISIG Subset-137</xref>, format="default"/>, except that:</t>
        <ul spacing="normal">
          <li>A certificate enrollment request message consists of only one  certificate request (CertReqMsg).</li>
          <li>
			<t><xref target="RFC4210" format="default">RFC&nbsp;4210</xref> format="default"/> requires that the messageTime is Greenwich Mean Time coded as generalizedTime.</t>
	        <t>Note: As Table 5 of <xref target="UNISIG.Subset-137" format="default">UNISIG Subset-137 Table 5</xref> format="default"/> explicitly states that the messageTime in is required to be "UTC time", it is not clear if this means a coding as UTCTime or generalizedTime and if other time zones other than Greenwich Mean Time shall be allowed. Both time formats are described in <xref target="RFC5280" format="default">RFC&nbsp;5280 Section 4.1.2.5</xref>.</t> format="default" sectionFormat="of" section="4.1.2.5"/>.</t>
		  </li>
          <li>The same type of protection is required to be used for all messages of one PKI management operation. This means, in case the request message protection is MAC-based, also the response, certConf, and pkiConf messages must also have a MAC-based protection.</li>
          <li>
			<t>Use of caPubs is not required but is typically allowed in combination with MAC-based protected PKI management operations.  On the other hand hand, Table 12 of <xref target="UNISIG.Subset-137" format="default">UNISIG Subset-137 Table 12</xref> format="default"/> requires using caPubs.</t>
			<t>Note: It remains unclear from UNISIG Subset-137 for which certificate(s) for the caPubs field should be used. For security reasons, it cannot be used for delivering the root CA certificate needed for validating to validate the signature-based protection of the given response message (as stated indirectly also in its <xref target="UNISIG.Subset-137" format="default">UNISIG Subset-137 Section 6.3.1.5.2 b</xref>).</t> b of <xref target="UNISIG.Subset-137" format="default"/>).</t>
			</li>
          <li>
			<t>This profile requires that the certConf message has have one CertStatus element where the statusInfo field is recommended.</t>
			<t>Note: In contrast, Table 18 of <xref target="UNISIG.Subset-137" format="default">UNISIG Subset-137 Table 18</xref> format="default"/> requires that the certConf message has one CertStatus element where the statusInfo field must be absent. This precludes sending a negative certConf message in case the EE rejects the newly enrolled certificate. This results in violating the general rule that a certificate request transaction must include a certConf message (since moreover, (moreover, since using implicitConfirm is not allowed there, there either).</t>
			</li>
        </ul>
      </section>
      <section anchor="ZTO" numbered="true" toc="default">
        <name>Use of CMP in SZTP and BRSKI Environments</name>
		<t>In <xref target="RFC8572" format="default">Secure Zero Touch Provisioning (SZTP)</xref> and other environments using NETCONF/YANG Network Configuration Protocol (NETCONF) / YANG modules, <xref target="I-D.ietf-netconf-sztp-csr" format="default">SZTP-CSR</xref> format="default"/> offers a YANG module that includes several types of certificate requests to obtain a public-key public key certificate for a locally generated key pair.  Such messages are of the form ietf-ztp-types:cmp-csr from module ietf-ztp-csr and offer both proof-of-possession and proof-of-identity.  To allow PKI management entities that use the module ietf-ztp-csr and also wish to comply with this profile, the ir, cr, kur, or p10cr message MUST <bcp14>MUST</bcp14> be formatted by the EE as described in <xref target="EE_request" format="default"/>, and it MAY <bcp14>MAY</bcp14> be forwarded forwarded, as specified in <xref target="RA_forwarde_messages" format="default"/>.</t>
		<t>In <xref target="RFC8995" format="default">Bootstrapping Remote Secure Key Infrastructure (BRSKI)</xref> environments, <xref target="I-D.ietf-anima-brski-ae" format="default">BRSKI-AE: format="default">"BRSKI-AE: Alternative Enrollment Protocols in BRSKI</xref> BRSKI"</xref> describes a generalization regarding the employed enrollment protocols to allow alternatives to <xref target="RFC7030" format="default">EST</xref>. format="default">Enrollment over Secure Transport (EST)</xref>. For the use of CMP, it requires adherence to this profile.</t>
      </section>
      <section anchor="Scope" numbered="true" toc="default">
        <name>Scope of this This Document</name>
		<t>This profile on the
		<t>On one hand hand, this profile intends to reduce the flexibility of CMP to the generic needs of automated certificate management of machine end entities.  On the other hand, it offers a variety of PKI management operations and options relevant for industrial use cases.  Therefore, it is still a framework that supports further profiling by those addressing a specific use case or scenario, e.g., 3GPP/ETSI or UNISIG.  There is room for to further tailoring tailor this profile.  This enables stricter profiling to meet the needs of concrete needs in application areas.</t>
        <t>To minimize ambiguity and complexity through needless variety, this document specifies exhaustive requirements for generating PKI management messages on the sender side.  On the other hand,  However, it gives only minimal requirements on checks by the receiving side and how to handle error cases.</t>
        <t>Especially on the EE side side, this profile aims at a lightweight implementation. This means that the number of PKI management operations operation implementations are reduced to a reasonable minimum to support typical certificate management use cases in industrial machine-to-machine environments. On the EE side side, only limited resources are expected, while on the side of the PKI management entities entities, the profile accepts higher requirements.</t>
        <t>For the sake of interoperability and robustness, implementations should, as far so long as security is not affected, adhere to Postel's law: "Be conservative 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>
        <t>Fields used in ASN.1 syntax in Sections <xref target="GenericParts" format="default"/>, format="counter"/>, <xref target="EE_UseCases" format="default"/>, format="counter"/>, or <xref target="RA_UseCases" format="default"/> format="counter"/> are specified in <xref target="RFC4210" format="default">CMP</xref> <xref target="I-D.ietf-lamps-cmp-updates" target="RFC9480" format="default"/>, <xref target="RFC4211" format="default">CRMF</xref>, and <xref target="RFC5652" format="default">CMS</xref> <xref target="RFC8933" format="default"/>. When these sections do not explicitly discuss a field, then the field SHOULD NOT <bcp14>SHOULD NOT</bcp14> be used by the sending entity. The receiving entity MUST NOT <bcp14>MUST NOT</bcp14> require the absence of such a field, and field and, if the field is present, MUST <bcp14>MUST</bcp14> handle it gracefully.</t>
      </section>
      <section anchor="Structure" numbered="true" toc="default">
        <name>Structure of this 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="GenericParts" format="default"/> profiles the generic aspects of the PKI management operations specified in detail in Sections <xref target="EE_UseCases" format="counter"/> and <xref target="RA_UseCases" format="counter"/> to minimize redundancy in the description and to ease implementation. This covers the general structure and protection of messages, as well as generic prerequisites, validation, and error handling.</t>
        <t><xref target="EE_UseCases" format="default"/> profiles the exchange of CMP messages between an EE and the PKI management entity. There are various flavors of certificate enrollment requests, optionally with polling, central key generation, 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 involves polling for responses, and nesting of messages.</t>
        <t><xref target="Transfer_types" format="default"/> outlines several mechanisms for CMP message transfer, including HTTP-based transfer <xref target="RFC6712" format="default"/> optionally using TLS, and CoAP-based transfer <xref target="I-D.ietf-ace-cmpv2-coap-transport" target="RFC9482" format="default"/> optionally using DTLS, and offline file-based transport.</t>
		<t><xref target="Conformity" format="default"/> defines which parts of the profile are mandatory, recommended, optional, or not relevant to implement for which type of entity.</t>
      </section>
    </section>
    <section anchor="Architecture" numbered="true" toc="default">
      <name>Solution Architecture</name>
      <t>To facilitate secure automatic certificate enrollment, the device hosting an EE is typically equipped with a manufacturer-issued device certificate.  Such a certificate is typically installed during production and is meant to identify the device throughout its lifetime.  This certificate can be used to protect the initial enrollment of operational certificates after installation of the EE in its operational environment.  In contrast to the manufacturer-issued device 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., in a security protocol like IPsec, TLS, or SSH.  In <xref target="IEEE.802.1AR_2018" format="default">IEEE&nbsp;802.1AR</xref> format="default">IEEE&nbsp;802.1AR</xref>, a manufacturer-issued device certificate is called IDevID an Initial Device Identifier (IDevID) certificate and an operational certificate is called LDevID a Locally Significant Device Identifier (LDevID) certificate.</t>
      <t>Note: The owner or operator using the manufacturer-issued device certificate for authenticating the device during initial enrollment of operational certificates MUST <bcp14>MUST</bcp14> trust the respective trust anchor provided by the manufacturer.</t>
       <t>Note: According to <xref target="IEEE.802.1AR_2018" format="default">IEEE&nbsp;802.1AR</xref> format="default">IEEE&nbsp;802.1AR</xref>, a DevID comprises the triple of the certificate, the corresponding private key, and the certificate chain.</t>
	  <t>All certificate management operations specified in this document follow the pull model, i.e., they are initiated by an EE (or by an RA acting as an EE).  The EE creates a CMP request message, protects it using some asymmetric credential or shared secret information information, and sends it to a PKI management entity.  This PKI management entity may be a CA or more typically an RA, which checks the request, request and responds to it itself, itself or forwards the request upstream to the next PKI management entity.  In case an RA changes the CMP request message header or body or wants to demonstrate successful verification or authorization, it can apply a protection of its own.  The communication between an LRA and RA can be performed synchronously or asynchronously.  Asynchronous communication typically leads to delayed message delivery as described in <xref target="EE_Polling" format="default"/>.</t>
      <figure anchor="CertManUseCasesFigure">
        <name>Certificate Management Architecture Example</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
+-----+            +-----+                +-----+            +-----+
|     |            |     |                |     |            |     |
| EE  |<---------->| LRA |<-------------->| RA  |<---------->| CA  |
|     |            |     |                |     |            |     |
+-----+            +-----+                +-----+            +-----+

        synchronous        (a)synchronous       (a)synchronous
   +----connection----+------connection------+----connection----+

                                  operators        service partner
+---------on site---------+---back-end services--+---trust center--+

             <--- downstream <--- | ---> upstream --->
         ]]></artwork>
      </figure>
      <t>In operational environments environments, the certificate management architecture can have multiple LRAs bundling requests from multiple EEs at dedicated locations and one (or more than one) central RA aggregating the requests from the LRAs.  Every LRA in this scenario has shared secret information (one per EE) for MAC-based protection or a CMP protection key and certificate certificate, allowing it to protect CMP messages it processes using its own credentials.  The figure above shows an architectural example with one LRA, RA, and CA.  It is also possible not to have an RA or LRA or that there is no CA with a CMP interface.  Depending on the network infrastructure, the message transfer between PKI management entities may be based on synchronous online connections, asynchronous connections, or even offline (e.g., file-based) transfer.</t>
	  <t>Note: In contrast to the pull model used in this document, other specifications could use the messages specified in this document implementing to implement the push model.  In this case case, the EE is pushed (triggered) by the PKI management entity to provide the CMP request, and request; therefore, the EE acts as the receiver, not initiating the interaction with the PKI. For example, when the device itself does only act as acts (as a server as described in <xref target="I-D.ietf-anima-brski-prm" format="default">BRSKI with Pledge in Responder Mode (BRSKI-PRM)</xref>, Mode</xref>), support of certificate enrollment in a push model is needed. While BRSKI-PRM currently utilizes its own format for the exchanges, CMP in general and the messages specified in this profile offer all required capabilities. Nevertheless, the message flow and state machine as described in <xref target="EE_State_Machine" format="default"/> must be adapted to implement a push model.</t>
      <t>Note: Third-party CAs, CAs not conforming to this document, document may implement other variants of CMP, different standardized protocols, or even proprietary interfaces for certificate management.  In such cases, an RA needs to adapt the exchanged CMP messages to the flavor of certificate management interaction required by such a non-conformant nonconformant CA.</t>
    </section>
    <section anchor="GenericParts" numbered="true" toc="default">
      <name>Generic Aspects of PKI Messages and PKI Management Operations</name>
      <t>This section covers the generic aspects of the PKI management operations specified in Sections <xref target="EE_UseCases" format="counter"/> and <xref target="RA_UseCases" format="counter"/> as upfront general requirements to minimize redundancy in the description and to ease implementation.</t>
      <t keepWithNext="true">As described in <xref target="RFC4210" format="default">Section 5.1 of RFC&nbsp;4210</xref>, format="default" sectionFormat="of" section="5.1"/>, all CMP messages have the following general structure:</t>
      <figure anchor="CMP_messageStructure">
        <name>CMP Message Structure</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
+--------------------------------------------+
| PKIMessage                                 |
| +----------------------------------------+ |
| | header                                 | |
| +----------------------------------------+ |
| +----------------------------------------+ |
| | body                                   | |
| +----------------------------------------+ |
| +----------------------------------------+ |
| | protection (OPTIONAL)                  | |
| +----------------------------------------+ |
| +----------------------------------------+ |
| | extraCerts (OPTIONAL)                  | |
| +----------------------------------------+ |
+--------------------------------------------+
            ]]></artwork>
      </figure>
      <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="counter"/> and <xref target="RA_UseCases" format="counter"/>.</t>
      <t>The CMP message body contains the PKI management operation-specific information. 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 fields is stated as OPTIONAL <bcp14>OPTIONAL</bcp14> or RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.  The following text that states requirements on such a field applies only if the field is present.</t>
	  <t>The generic prerequisites needed by the PKI entities in order to be able to perform PKI management operations are described in <xref target="Prereq" format="default"/>.</t>
      <t>The generic validation steps to be performed by PKI entities on upon receiving 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>
      <section anchor="Header" numbered="true" toc="default">
        <name>General Description of the CMP Message Header</name>
        <t>This section describes the generic header fields of all CMP messages.</t>
	<t>Any PKI management operation-specific fields or variations specific to PKI management operation are described in Sections <xref target="EE_UseCases" format="counter"/> and <xref target="RA_UseCases" format="counter"/>.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
header
  pvno                        REQUIRED
    -- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData
    --   is supported and expected to be used in the current
    --   PKI management operation
    -- MUST be 3 to indicate CMP v3 in certConf messages when using
    --   the hashAlg field
    -- MUST be 2 to indicate CMP v2 in all other cases
    -- For details on version negotiation negotiation, see RFCAAAA [RFC9480]
  sender                      REQUIRED
    -- Contains a name representing the originator originator, which also
    --   protects the message
    -- For signature-based protection protection, MUST be the subject field of
    --   the CMP
    -- protection certificate
    -- For MAC-based protection protection, MUST be the subject contain a name of the PKI
    --   certificate request, if available; otherwise,   management entity can use to identify the NULL-DN shared secret
    --   (a zero-length SEQUENCE OF RelativeDistinguishedNames)   information. This name MUST
    -- be used placed in the commonName
    --   field of the directoryName choice.
    -- In a multi-hop multihop scenario, the receiving entity cannot rely
    --   on the correctness of the sender field.
  recipient                   REQUIRED
    -- SHOULD be the name of the intended recipient; otherwise, the
    --   NULL-DN MUST be used
    -- In the first message of a PKI management operation: operation, SHOULD be
    --   the subject DN of the CA the PKI management operation is
    --   requested from
    -- In all other messages: messages, SHOULD contain the value of the sender
    --   field of the previous message in the same PKI management
    --   operation
    -- The recipient field shall be handled gracefully by the
    --   receiving entity, because in a multi-hop scenario multihop scenario, its
    --   correctness cannot be guaranteed.
  messageTime                 OPTIONAL
    -- MUST be present if the confirmWaitTime field is 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
    --   time
    -- MAY be used by the end entity for time synchronization if the
    --   response was received within a short time frame
  protectionAlg               REQUIRED
    -- MUST be an algorithm identifier indicating the algorithm
    --   used for calculating the protection bits
    -- If it is a signature algorithm algorithm, its type MUST be a
    --   MSG_SIG_ALG as specified in [RFCBBBB] Section 3 of [RFC9481] and
    --   MUST be consistent with the subjectPublicKeyInfo field of
    --   the CMP protection certificate
    -- If it is a MAC algorithm algorithm, its type MUST be a MSG_MAC_ALG MSG_MAC_ALG, as
    --   specified in [RFCBBBB] [RFC9481], Section 6.1
  senderKID                   RECOMMENDED
    -- For signature-based protection protection, MUST be used and contain the
    --   value of the SubjectKeyIdentifier if present in the CMP
    --   protection certificate
    -- For MAC-based protection protection, MUST be used and contain a name the same
    --   PKI management entity can use to identify   name as in the shared secret
    --   information commonName field of the sender field
  transactionID               REQUIRED
    -- In the first message of a PKI management operation: operation, MUST be
    --   128 bits of random data, data to minimize the probability of
    --   having the transactionID already in use at the server
    -- In all other messages: messages, MUST be the value from the previous
    --   message in the same PKI management operation
  senderNonce                 REQUIRED
    -- MUST be cryptographically secure and fresh 128 random bits
  recipNonce                  RECOMMENDED
    -- If this is the first message of a transaction: transaction, MUST be absent
    -- If this is a delayed response message: message, MUST be present and
    --   contain the value of the senderNonce of the respective
    --   request message in the same transaction
    -- In all other messages: messages, MUST be present and contain the value
    --   of the senderNonce of the previous message in the same
    --   transaction
  generalInfo                 OPTIONAL
    implicitConfirm           OPTIONAL
    -- RECOMMENDED in ir/cr/kur/p10cr messages,
    -- OPTIONAL in ip/cp/kup response messages, and
    -- PROHIBITED in other types of messages
    -- Added to request messages to request omission of the certConf
    --   message
    -- Added to response messages to grant omission of the certConf
    --   message
    -- See [RFC4210] [RFC4210], Section 5.1.1.1.
      ImplicitConfirmValue   REQUIRED
    -- ImplicitConfirmValue MUST be NULL
    confirmWaitTime           OPTIONAL
    -- RECOMMENDED in ip/cp/kup messages if implicitConfirm is
    --   not included
    -- PROHIBITED if implicitConfirm is included
    -- See [RFC4210] [RFC4210], Section 5.1.1.2.
      ConfirmWaitTimeValue    REQUIRED
    -- ConfirmWaitTimeValue MUST be a GeneralizedTime value
    --   specifying the point in time up to which the PKI management
    --   entity will wait for the certConf message.  The accepted
    --   length of the waiting period will vary by use case.
    certProfile               OPTIONAL
    -- MAY be present in ir/cr/kur/p10cr and in genm messages of type
    --   id-it-certReqTemplate
    -- MUST be omitted in all other messages
    -- See [RFCAAAA] [RFC9480].
      CertProfileValue        REQUIRED
    -- MUST contain a sequence of one UTF8String element
    -- MUST contain the name of a certificate profile
                ]]></artwork>
                ]]></sourcecode>
      </section>
      <section anchor="Protection" numbered="true" toc="default">
        <name>General Description of the CMP Message Protection</name>
        <t>This section describes the generic protection field contents of all CMP messages.  For signature-based protection, which is the default protection mechanism for all CMP messages described in this profile, the CMP protection key and CMP protection certificate are used. For MAC-based protection protection, shared secret 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
    -- If present, the same kind of protection MUST be used for all
    --   messages of that PKI management operation.
    -- MUST be present, except if protection is not possible for
    --   error messages as described in Section 3.6.4. 3.6.4
    -- For signature-based protection protection, MUST contain the signature
    --   calculated using the CMP protection key of the entity
    --   protecting the message. message
    -- For MAC-based protection protection, MUST contain a MAC calculated using
    --   the shared secret information. information
    -- The protection algorithm used MUST be given in the
    --   protectionAlg field.
                ]]></artwork>
                ]]></sourcecode>
        <t>The CMP message protection provides, if available, message origin authentication and integrity protection for the header and body. The CMP message extraCerts field is not covered by this protection.</t>
        <t>Note: The extended key usages described in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 2.2</xref> target="RFC9480" format="default" sectionFormat="of" section="2.2">CMP Updates</xref> can be used for authorization of a sending PKI management entity.</t>
      </section>
      <section anchor="extraCerts" numbered="true" toc="default">
        <name>General Description of CMP Message ExtraCerts</name>
        <t>This section describes the generic extraCerts field of all CMP messages.  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
    -- MUST be present for signature-based protection and contain the
    --   CMP protection certificate together with its chain for the
    --   first request and response message of a PKI management
    --   operation.  MAY be omitted in certConf, PKIConf, pollReq, and
    --   and pollRep messages.  The first certificate in this field MUST
    --   MUST be the CMP protection certificate followed by its chain
    --   chain, where each element should directly certify the one
    --   immediately preceding it.
    -- MUST be present in ip, cp, and kup messages and contain the
    --   chain of a newly issued certificate.
    -- Self-signed certificates should be omitted from extraCerts and
    --   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 is if it is the CMP protection certificate or a successor root CA self-signed certificate as indicated in the HashOfRootKey extension of the current root CA certificate, certificate; see <xref target="RFC8649" format="default"></xref>.
   Another reason
   for including self-signed certificates in the extraCerts is, for instance
   instance, due to storage limitations, a limitations. A receiving PKI entity may not
   have the complete trust anchor as self-signed certificate information available
   but just a unique identification of it, it and thus needs the full
   trust anchor information carried in a self-signed certificate for further
   processing (see also <xref target="Security" format="default"/>).</t>
		<t>For maximum interoperability, all implementations SHOULD <bcp14>SHOULD</bcp14> be prepared to handle potentially additional certificates and arbitrary orderings of the certificates.</t>
      </section>
      <section anchor="Prereq" numbered="true" toc="default">
        <name>Generic PKI Management Operation Prerequisites</name>
        <t>This subsection describes what is generally needed by the PKI entities to be able to perform PKI management operations.</t>
        <t keepWithNext="true">Identification of PKI entities:</t>
        <ul spacing="normal">
          <li>For signature-based protection protection, each EE knows its own identity from the CMP protection certificate and certificate; for MAC-based protection protection, it MAY <bcp14>MAY</bcp14> know its identity to fill the sender field.</li>
          <li>
  	    <t>Each EE MAY <bcp14>MAY</bcp14> know the intended recipient of its requests to fill the recipient field, e.g., the name of the addressed CA.</t>
  			<t>Note: This name may be established using an enrollment voucher, e.g., voucher (as described in <xref target="RFC8366" format="default"></xref>, format="default"></xref>), the issuer field from a CertReqTemplate response message content, or by other configuration means.</t>
  			</li>
        </ul>
        <t keepWithNext="true">Routing of CMP messages:</t>
        <ul spacing="normal">
          <li>
			<t>Each PKI entity sending messages upstream MUST <bcp14>MUST</bcp14> know the address needed for transferring messages to the next PKI management entity in case online-transfer online transfer is used.</t>
			<t>Note: This address may depend on the recipient, the certificate profile, and on the used transfer mechanism.</t>
			</li>
        </ul>
        <t keepWithNext="true">Authentication of PKI entities:</t>
        <ul spacing="normal">
          <li>Each PKI entity MUST <bcp14>MUST</bcp14> have credentials to authenticate itself. For signature-based protection protection, it MUST <bcp14>MUST</bcp14> have a private key and the corresponding certificate along with its chain.</li>
          <li>
			<t>Each PKI entity MUST <bcp14>MUST</bcp14> be able to establish trust in the PKI it receives responses from. When signature-based protection is used, it MUST <bcp14>MUST</bcp14> have the trust anchor(s) and any certificate status information needed to perform path validation of CMP protection certificates used for signature-based protection.</t>
			<t>Note: A trust anchor usually is usually a root certificate of the PKI addressed by the requesting EE. It may be established by configuration or in an out-of-band manner.  For an EE EE, it may be established using an enrollment voucher <xref target="RFC8366" format="default"></xref> or in-band of CMP by the caPubs field in a certificate response message.</t>
			</li>
        </ul>
        <t keepWithNext="true">Authorization of PKI management operations:</t>
        <ul spacing="normal">
          <li>
			<t>Each EE or RA MUST <bcp14>MUST</bcp14> have sufficient information to be able to authorize the PKI management entity for performing to perform the upstream PKI management operation.</t>
			<t>Note: This may be achieved achieved, for example example, by using the cmcRA extended key usage in server certificates, by local configuration such (such as specific name patterns for subject DN Distinguished Name (DN) or SAN Subject Alternative Name (SAN) portions that may identify an RA, RA) and/or by having a dedicated root CA usable only for authenticating PKI management entities.</t>
			</li>
          <li>
			<t>Each PKI management entity MUST <bcp14>MUST</bcp14> have sufficient information to be able to authorize the downstream PKI entity requesting the PKI management operation.</t>
			<t>Note: For authorizing an RA RA, the same examples apply as above. The authorization of EEs can be very specific to the application domain based on local PKI policy.</t>
			</li>
        </ul>
      </section>
      <section anchor="Validation" numbered="true" toc="default">
        <name>Generic Validation of a PKI Message</name>
        <t>This section describes generic validation steps of each PKI entity receiving a PKI request or response message before any further processing or forwarding.  If a PKI management entity decides to terminate a PKI management operation because a check failed, it MUST <bcp14>MUST</bcp14> send a negative response or an error message as described in <xref target="Error" format="default"/>. The PKIFailureInfo bits given below in parentheses MAY <bcp14>MAY</bcp14> be used in the failInfo field of the PKIStatusInfo as described in <xref target="Error_reporting" format="default"/>, see format="default"/>; also see <xref target="RFC4210" format="default">RFC&nbsp;4210 Appendix F</xref>.</t> format="default" sectionFormat="of" section="F"/>.</t>
        <t>All PKI message header fields not mentioned in this section section, like the recipient and generalInfo fields SHOULD fields, <bcp14>SHOULD</bcp14> be handled gracefully on reception.</t> upon receipt.</t>
        <t keepWithNext="true">The following list describes the basic set of message input validation steps. Without these checks checks, the protocol becomes dysfunctional.</t>
        <ul spacing="normal">
          <li>The formal ASN.1 syntax of the whole message MUST <bcp14>MUST</bcp14> be compliant with the definitions given in <xref target="RFC4210" format="default">CMP</xref> and <xref target="I-D.ietf-lamps-cmp-updates" target="RFC9480" format="default"/>, <xref target="RFC4211" format="default">CRMF</xref>, and <xref target="RFC5652" format="default">CMS</xref> and <xref target="RFC8933" format="default"/>. (failInfo: badDataFormat)</li>
          <li>The pvno MUST <bcp14>MUST</bcp14> be cmp2000(2) or cmp2021(3). (failInfo bit: unsupportedVersion)</li>
          <li>The transactionID MUST <bcp14>MUST</bcp14> be present. (failInfo bit: badDataFormat)</li>
          <li>The PKI message body type MUST <bcp14>MUST</bcp14> be one of the message types supported by the receiving PKI entity and MUST <bcp14>MUST</bcp14> be allowed in the current state of the PKI management operation identified by the given transactionID. (failInfo bit: badRequest)</li>
        </ul>
        <t keepWithNext="true">The following list describes the set of message input validation steps required to ensure secure protocol operation:</t>
        <ul spacing="normal">
          <li>The senderNonce MUST <bcp14>MUST</bcp14> be present and MUST <bcp14>MUST</bcp14> contain at least 128 bits of data. (failInfo bit: badSenderNonce)</li>
          <li>
            <t>Unless the PKI message is the first message of a PKI management operation,</t>
            <ul spacing="normal">
              <li>the recipNonce MUST <bcp14>MUST</bcp14> be present and MUST <bcp14>MUST</bcp14> equal the senderNonce of the previous message or equal the senderNonce of 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>
			</li>
		  <li>Messages without protection MUST <bcp14>MUST</bcp14> be rejected except for error messages as described in <xref target="Error_reporting" format="default"/>.</li>
          <li>
            <t>The message protection MUST <bcp14>MUST</bcp14> be validated when present present, and messages with an invalid protection MUST <bcp14>MUST</bcp14> be rejected.</t>
            <ul spacing="normal">
              <li>The protection MUST <bcp14>MUST</bcp14> be signature-based except if MAC-based protection is used as described in Sections <xref target="EE_MAC" format="default"/> format="counter"/> and <xref target="EE_KGPB" format="default"/>. format="counter"/>.  (failInfo bit: wrongIntegrity)</li>
              <li>If present, the senderKID MUST <bcp14>MUST</bcp14> identify the key material needed for verifying the message protection. (failInfo bit: badMessageCheck)</li>
              <li>If signature-based protection is used, the CMP protection certificate MUST <bcp14>MUST</bcp14> be successfully validated validated, including path validation using a trust anchor anchor, and MUST <bcp14>MUST</bcp14> be authorized according to local policies. If the keyUsage extension is present in the CMP protection certificate certificate, the digitalSignature bit MUST <bcp14>MUST</bcp14> be set. (failInfo bit: badAlg, badMessageCheck, or signerNotTrusted)</li>
			  <li>The sender of a request message MUST <bcp14>MUST</bcp14> be authorized for requesting to request the operation according to PKI policies. (failInfo bit: notAuthorized)</li>
              </ul>
			</li>
          <li></li>

        </ul>
		<t>Note: The requirements for checking certificates given in <xref target="RFC5280" format="default">RFC&nbsp;5280</xref> MUST format="default"/> <bcp14>MUST</bcp14> be followed for signature-based CMP message protection.  Unless the message is a positive ip/cp/kup ip/cp/kup, 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 <bcp14>SHOULD</bcp14> be performed on the CMP protection certificates.  If the response message contains the caPubs field to transfer new trust anchor information, the CMP protection is crucial and certificate status checking is REQUIRED. <bcp14>REQUIRED</bcp14>.  For other cases cases, it MAY <bcp14>MAY</bcp14> be acceptable to omit certificate status checking when respective information is not available.</t>
        <t keepWithNext="true">Depending on local policies, one or more of the input validation checks described below need to be implemented:</t>
        <ul spacing="normal">
          <li>If signature-based protection is used, the sender field MUST <bcp14>MUST</bcp14> match the subject of the CMP protection certificate. (failInfo bit: badMessageCheck)</li>
          <li>
		    <t>If the messageTime is present and</t>
            <ul spacing="normal">
              <li>the receiving system has a reliable system time, the messageTime MUST <bcp14>MUST</bcp14> be close to the current time of the receiving system, where the threshold will vary by use case. (failInfo bit: badTime)</li>
              <li>the receiving system does not have a reliable system time, the messageTime MAY <bcp14>MAY</bcp14> be used for time synchronization.</li>
              </ul>
			</li>
        </ul>
      </section>
      <section anchor="Error" numbered="true" toc="default">
        <name>Error Handling</name>
        <t>This section describes how a PKI entity handles error conditions on messages it receives. Each error condition should be logged appropriately to allow root-cause analysis of failure cases.</t>
        <section anchor="Error_upstream" numbered="true" toc="default">
          <name>Reporting Error Conditions Upstream</name>
		  <t>An EE SHALL NOT <bcp14>SHALL NOT</bcp14> send error messages.  PKI management entities SHALL NOT <bcp14>SHALL NOT</bcp14> send error messages in the upstream direction, direction either.</t>
		  <t>In case an EE rejects a newly issued certificate contained in an ip, cp, or kup message and implicit confirmation has not been granted, the EE MUST <bcp14>MUST</bcp14> report this using a certConf message with "rejection" status and await the pkiConf response as described in <xref target="EE_newPKI" format="default"/>.</t>
		  <t>On all other error conditions regarding response messages, the EE or PKI management entity MUST <bcp14>MUST</bcp14> regard the current PKI management operation as terminated with failure. The error conditions include</t> include:</t>
          <ul spacing="normal">
            <li>invalid response message header, body type, protection, or extraCerts extraCerts, according to the checks described in <xref target="Validation" format="default"/>,</li>
            <li>any issue detected with response message contents,</li>
            <li>receipt of an error message from upstream,</li>
            <li>timeout occurred while waiting for a response,</li> response, and</li>
            <li>rejection of a newly issued certificate while implicit confirmation has been granted.</li>
          </ul>
		  <t>Upstream PKI management entities will not receive any CMP message to learn that the PKI management operation has been terminated.  In case they expect a further message from the EE, a connection interruption or timeout will occur.  The value set for such timeouts will vary by use case. Then they <bcp14>MUST</bcp14> also MUST regard the current PKI management operation as terminated with failure and MUST NOT <bcp14>MUST NOT</bcp14> attempt to send an error message downstream.</t>
        </section>
        <section anchor="Error_downstream" numbered="true" toc="default">
          <name>Reporting Error Conditions Downstream</name>
		  <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, p10cr, kur, or rr message received from downstream, it MUST <bcp14>MUST</bcp14> report the error in the specific response message, i.e., an ip, cp, kup, or rp with "rejection" status, as described in Sections <xref target="EE_newPKI" format="default"/> format="counter"/> and <xref target="EE_Revoke" format="default"/>. format="counter"/>. This can also happen in case of polling.</t>
		  <t>In case the PKI management entity detects any other error condition on requests, including requests (including pollReq, certConf, genm, and nested messages, messages) received from downstream and on responses received from upstream, such upstream (such as invalid message header, body type, protection, or extraCerts extraCerts, according to the checks described in <xref target="Validation" format="default"/> format="default"/>), it MUST <bcp14>MUST</bcp14> report them downstream in the form of an error message as described in <xref target="Error_reporting" format="default"/>.</t>
        </section>
        <section anchor="Error_nested" numbered="true" toc="default">
          <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>If the error condition is on an upstream nested message containing batched requests, it MUST NOT <bcp14>MUST NOT</bcp14> attempt to respond to the individual requests included in it, 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 detects an error condition on the downstream nested message received in response to a nested message sent before and the body of the received nested message still parses, it MAY <bcp14>MAY</bcp14> ignore this error condition and handle the included responses as described in <xref target="RA_AddBatch" format="default"/>. Otherwise, it MUST <bcp14>MUST</bcp14> propagate the error by responding with an error message to each of the requests contained in the nested message it sent originally.</t>
        </section>
        <section anchor="Error_reporting" numbered="true" toc="default">
          <name>PKIStatusInfo and Error Messages</name>
		  <t>When sending any kind of negative response, including error messages, a PKI entity MUST <bcp14>MUST</bcp14> indicate the error condition in the PKIStatusInfo structure of the respective message as described below.  It then MUST  Then it <bcp14>MUST</bcp14> regard the current PKI management operation as terminated with failure.</t>
		  <t keepWithNext="true">The PKIStatusInfo structure is used to report errors.  It may be part of various message types, in particular: particular, ip, cp, kup, certConf, and error. The PKIStatusInfo structure consists of the following fields:</t>
          <ul

          <dl spacing="normal">
            <li>status: Here
            <dt>status:</dt>
	    <dd>Here, the PKIStatus value "rejection" MUST <bcp14>MUST</bcp14> be used in case an error was detected.  When a PKI management entity indicates delayed delivery of a CMP response message to the EE with an error message as described in <xref target="EE_Polling" format="default"/>, the status "waiting" MUST <bcp14>MUST</bcp14> be used there.</li>
            <li>statusString: Here there.</dd>
            <dt>statusString:</dt>
	    <dd>Here, any human-readable valid value for logging or to display via a user interface should be added.</li>
            <li>
              <t>failInfo: Here added.</dd>

            <dt>failInfo:</dt>
	    <dd>
	      <t>Here, the PKIFailureInfo bits MAY <bcp14>MAY</bcp14> be used in the way explained in <xref target="RFC4210" format="default">Appendix F of RFC&nbsp;4210</xref>. format="default" sectionFormat="of" section="F"/>.  PKIFailureInfo bits regarding the validation described in <xref target="Validation" format="default"/> are referenced there. The PKIFailureInfo bits referenced in Sections <xref target="RA_response" format="counter"/> and <xref target="Transfer_types" format="counter"/> are described here:</t>
              <ul

              <dl spacing="normal">
                <li>badCertId: A
                <dt>badCertId:</dt><dd>A kur, certConf, or rr message references an unknown certificate</li>
                <li>badPOP: An certificate.</dd>
                <dt>badPOP:</dt><dd>An ir/cr/kur/p10cr contains an invalid proof-of-possession</li>
                <li>certRevoked: Revocation proof-of-possession.</dd>
                <dt>certRevoked:</dt><dd>Revocation is requested for a certificate that is already revoked</li>
                <li>badCertTemplate: The revoked.</dd>
                <dt>badCertTemplate:</dt><dd>The contents of a certificate request are not accepted, e.g., a field is missing or has a non-acceptable an unacceptable value or the given public key is already in use in some other certificate (depending on policy).</li>
                <li>transactionIdInUse: policy).</dd>
                <dt>transactionIdInUse:</dt><dd> This is sent by a PKI management entity in case the received request contains a transactionID that is currently in use for another transaction.  An EE receiving such an error message should resend the request in a new transaction using a different transactionID.</li>
				<li>notAuthorized: transactionID.</dd>
				<dt>notAuthorized:</dt><dd> The sender of a request message is not authorized for requesting the operation.</li>
                <li>systemUnavail: This operation.</dd>
                <dt>systemUnavail:</dt><dd>This is sent by a PKI management entity in case a back-end system is not available.</li>
                <li>systemFailure: This available.</dd>
                <dt>systemFailure:</dt><dd>This is sent by a PKI management entity in case a back-end system is currently not functioning correctly.</li>
              </ul>
            </li>
          </ul> correctly.</dd>
              </dl>
            </dd>
          </dl>
		  <t>An EE receiving a systemUnavail or systemFailure failInfo should resend the request in a new transaction after some time.</t>
        <t keepWithNext="true">Detailed Message Description:</t>
        <artwork align="left" name="" type="" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
Error Message -- error

Field                         Value

header
    -- As described in Section 3.1

body
    -- The message indicating the error that occurred
  error                       REQUIRED
    pKIStatusInfo             REQUIRED
      status                  REQUIRED
    -- MUST have the value "rejection"
      statusString            OPTIONAL
    -- This field should contain any human-readable text for
    --   debugging, logging for logging, or to display in a GUI
      failInfo                OPTIONAL
    -- MAY be present and contain the relevant PKIFailureInfo bits

protection                    RECOMMENDED
    -- As described in Section 3.2

extraCerts                    RECOMMENDED
    -- As described in Section 3.3
              ]]></artwork>
              ]]></sourcecode>
			<t>Protecting the error message may not be technically feasible if it is not clear which credential the recipient will be able to use when validating this protection, e.g., in case the request message was fundamentally broken.  In these exceptional cases cases, the protection of the error message MAY <bcp14>MAY</bcp14> be omitted.</t>
        </section>
      </section>
    </section>
    <section anchor="EE_UseCases" numbered="true" toc="default">
      <name>PKI Management Operations</name>
      <t>This chapter section focuses on the communication of an EE with the PKI management entity it directly talks to.  Depending on the network and PKI solution, this can be an RA or directly a CA. Handling of a message by a PKI management entity is described in <xref target="RA_UseCases" format="default"/>.</t>
      <t keepWithNext="true">The PKI management operations specified in this section cover the following:</t>
      <ul spacing="normal">
        <li>Requesting
        <li>requesting a certificate with variations like initial enrollment, certificate updates, central key generation, and MAC-based protection</li>
        <li>Revoking
        <li>revoking a certificate</li>
        <li>Support
        <li>support messages</li>
        <li>Polling
        <li>polling for delayed response messages</li>
      </ul>
      <t>These operations mainly specify the message body of the CMP messages and utilize the specification of the message header, protection protection, and extraCerts extraCerts, as specified in <xref target="GenericParts" format="default"/>. The messages are named by the respective field names in PKIBody PKIBody, like ir, ip, cr, cp, etc., etc.; see <xref target="RFC4210" format="default">RFC&nbsp;4210 Section 5.1.2</xref>.</t> format="default" sectionFormat="of" section="5.1.2"/>.</t>
      <t>The following diagram shows the EE state machine covering all PKI management operations described in this section, including negative responses, error messages described in <xref target="Error_reporting" format="default"/>, as well as ip/cp/kup/error messages with status "waiting", pollReq, and pollReq and pollRep messages as described in <xref target="EE_Polling" format="default"/>.</t>
      <t>On receiving messages from upstream, the EE MUST <bcp14>MUST</bcp14> perform the general validation checks described in <xref target="Validation" format="default"/>. The behavior in In case an error occurs occurs, the behavior is described in <xref target="Error" format="default"/>.</t>
      <t keepWithNext="true">End Entity State Machine:</t>
      <artwork anchor="EE_State_Machine" align="left" name="" type="" alt=""><![CDATA[
End Entity State Machine:
                         start
                           |
                           | send ir/cr/kur/p10cr/rr/genm
                           v
                 waiting for response
                           v
+--------------------------+--------------------------+
|                          |                          |
| receives ip/cp/kup with  | received ip/cp/kup/error | received
| status "accepted" or     | with status "waiting"    | rp/genp or
| "grantedWithMods"        |                          | ip/cp/kup/
|                          v                          | error
|             +-------> polling                       | with status
|             |            |                          | "rejection"
|             | received   | send                     |
|             | pollRep    | pollReq                  |
|             |            v                          |
|             |   waiting for response                |
|             |            v                          |
|             +------------+--------+                 |
|                          |        |                 |
|       received ip/cp/kup |        | received        |
|   with status "accepted" |        | rp/genp or      |
|     or "grantedWithMods" |        | ip/cp/kup/error |
|                          |        | with status     |
+---------->+<-------------+        | "rejection"     |
            v                       |                 |
+-----------+-----+                 |                 |
|                 |                 |                 |
| implicitConfirm | implicitConfirm |                 |
| granted         | not granted     |                 |
|                 |                 |                 |
|                 | send certConf   |                 |
|                 v                 |                 |
|        waiting for pkiConf*)      |                 |
|                 |                 |                 |
|                 | received        |                 |
|                 v pkiConf         v                 |
+---------------->+------->+<-------+<----------------+
                           |
                           v
                          end

*) In
			  ]]></artwork>
      <dl newline="false" spacing="normal">
	<dt>*)</dt>
	<dd>In case of a delayed delivery of pkiConf responses responses, the same
   polling mechanism is initiated as for rp or genp messages, messages by
   sending an error message with status "waiting".
           ]]></artwork> "waiting".</dd>
      </dl>
      <t>Note: All CMP messages belonging to the same PKI management operation MUST <bcp14>MUST</bcp14> have the same transactionID because the message receiver identifies the elements of the operation in this way.</t>
      <t>This section is aligned with <xref target="RFC4210" format="default">CMP</xref>, <xref target="I-D.ietf-lamps-cmp-updates" target="RFC9480" format="default">CMP Updates</xref>, and <xref target="I-D.ietf-lamps-cmp-algorithms" target="RFC9481" format="default">CMP Algorithms</xref>.</t>
      <t>Guidelines as well as an algorithm use profile for this document are available in <xref target="I-D.ietf-lamps-cmp-algorithms" target="RFC9481" format="default">CMP Algorithms</xref>.</t>
      <section anchor="EE_request" numbered="true" toc="default">
        <name>Enrolling End Entities</name>
        <t>There are various approaches for requesting a certificate from a PKI.</t>
        <t keepWithNext="true">These approaches differ in the way the EE authenticates 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 follows:</t>
        <ul spacing="normal">
          <li>Using
          <li>using a certificate from an external PKI, e.g., a manufacturer-issued device certificate, and the corresponding private key</li>
		  <li>Using
	  <li>using a private key and certificate issued from the same PKI that is addressed for requesting a certificate</li>
          <li>Using
          <li>using the certificate to be updated and the corresponding private key</li>
          <li>Using
          <li>using shared secret information known to the EE and the PKI management entity</li>
        </ul>
        <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_response_enrollment" format="default"/> and responds with a message containing the requested certificate, the EE MUST <bcp14>MUST</bcp14> reply with a confirmation message unless implicitConfirm was granted. The PKI management entity <bcp14>MUST</bcp14>  then MUST handle it as described in <xref target="RA_response_confirmation" format="default"/> and respond with a confirmation, closing the PKI management operation.</t>
        <t>The message sequences described in this section allow the EE to request certification of a locally or centrally generated public-private key pair. Typically,
		The public key and the subject name identifying the EE <bcp14>MUST</bcp14> be present in the certTemplate of the certificate request message.</t>
		<t>Note: If the EE does not know for which subject name to request the certificate, it can use the subject name from the CMP protection certificate in case of signature-based protection or the identifier of the shared secret in case of MAC-based protection.</t>
		<t>Typically, the EE  provides a signature-based proof-of-possession of the private key associated with the public key contained in the certificate request request, as defined by <xref target="RFC4211" format="default">RFC&nbsp;4211 Section 4.1</xref> case format="default" sectionFormat="comma" section="4.1"/>, clause 3. To this end end, it is assumed that the private key can technically be used for signing.  This is the case for the most common algorithms RSA, ECDSA, and EdDSA EdDSA, regardless of potentially intended restrictions of the key usage.</t>
        <t>Note: <xref target="RFC4211" format="default">RFC&nbsp;4211 Section 4</xref> format="default" sectionFormat="of" section="4"/> allows for providing proof-of-possession using any method that a key can be used for. In conformance with Section 8.1.5.1.1.2 of <xref target="NIST.SP.800-57p1r5" format="default">NIST&nbsp;SP&nbsp;800-57 Part&nbsp;1 Section 8.1.5.1.1.2</xref> format="default"/>, the newly generated private key may be used for self-signature, if technically possible, even if the keyUsage extension requested 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 message containing that POP. An upstream PKI management entity should verify whether this EE is authorized to obtain a certificate with the requested subject and other fields and extensions.</t>
		<t>The proof-of-possession is provided by signing the certReq containing the certTemplate with the subject name and public key.  To bind this proof-of-possession to the proof-of-identity of the requesting EE, the subject name in the certTemplate needs to identify the same entity as the subject name in the CMP protection certificate or match the identifier used with MAC-based protection.</t>
		<t>Note: This binding may be lost if a PKI management entity reprotects this request message.</t>
		<t>The EE MAY <bcp14>MAY</bcp14> indicate the certificate profile to use in the certProfile extension of the generalInfo field in the PKIHeader of the certificate request message as described in <xref target="Header" format="default"/>.</t>
		<t>In case the EE receives a CA certificate in the caPubs field for installation as a new trust anchor, it MUST <bcp14>MUST</bcp14> properly authenticate the message and authorize the sender as a trusted source of the new trust anchor.
		This authorization is typically indicated using shared secret information for protecting an initialization response (ir) Initialization Response (ip) message. Authorization can also be signature-based signature-based, using a certificate issued by another PKI that is explicitly authorized for this purpose.  A certificate received in caPubs MUST NOT <bcp14>MUST NOT</bcp14> be accepted as a trust anchor if it is the root CA certificate of the certificate used for protecting the message.</t>
        <section anchor="EE_newPKI" numbered="true" toc="default">
          <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" format="default"/>, to authenticate itself to the new PKI.</t>
		  <t>Note: In <xref target="RFC8995" format="default">Bootstrapping Remote Secure Key Infrastructure (BRSKI)</xref> environments, <xref target="I-D.ietf-anima-brski-ae" format="default">BRSKI-AE: format="default">"BRSKI-AE: Alternative Enrollment Protocols in BRSKI</xref> BRSKI"</xref> describes a generalization regarding enrollment protocols alternative to <xref target="RFC7030" format="default">EST</xref>.  As replacement of EST simpleenroll, BRSKI-AE uses this PKI management operation for bootstrapping LDevID certificates.</t>
          <t keepWithNext="true">Specific prerequisites augmenting the prerequisites in <xref target="Prereq" format="default"/>:</t> format="default"/> are as follows:</t>
          <ul spacing="normal">
		    <li>The certificate of the EE MUST <bcp14>MUST</bcp14> have been enrolled by an external PKI, e.g., a manufacturer-issued device certificate.</li>
            <li>The PKI management entity MUST <bcp14>MUST</bcp14> have the trust anchor of the external PKI.</li>
            <li>When using the generalInfo field certProfile, the EE MUST <bcp14>MUST</bcp14> know the identifier needed to indicate the requested certificate profile.</li>
          </ul>
          <t keepWithNext="true">Message Flow:</t>
          <artwork align="left" name="" type="" alt=""><![CDATA[
Step# EE                                  PKI management entity
  1   format ir
  2                      ->   ir      ->
  3                                        handle or
                                             forward ir
  4                                        format or receive ip
  5                                        possibly grant
                                             implicitConfirm
  6                      <-   ip      <-
  7   handle ip

-----------------  if implicitConfirm not granted  -----------------

  8   format certConf
  9                      ->   certConf ->
 10                                        handle or
                                             forward certConf
 11                                        format or receive pkiConf
 12                      <-   pkiConf  <-
 13   handle pkiConf
                    ]]></artwork>
          <t>For this PKI management operation, the EE MUST <bcp14>MUST</bcp14> include a sequence of one CertReqMsg in the ir.  If more certificates are required, further requests MUST <bcp14>MUST</bcp14> be sent using separate PKI management operations.</t>
	  <t>The EE MUST <bcp14>MUST</bcp14> include the generalInfo field implicitConfirm in the header of the ir message as described in <xref target="Header" format="default"/>, unless it requires certificate confirmation.
	  This leaves the choice to the PKI management entities the choice of whether or not the EE must send a certConf message on upon receiving a new certificate.  Depending on the PKI policy and requirements for managing EE certificates, it can be important for PKI management entities to learn if the EE accepted the new certificate.  In such cases, when responding with an ip message, the PKI management entity MUST NOT <bcp14>MUST NOT</bcp14> include the implicitConfirm extension.  In case the EE included the generalInfo field implicitConfirm in the request message and the PKI management entity does not need any explicit confirmation from the EE, the PKI management entity MUST <bcp14>MUST</bcp14> include the generalInfo field implicitConfirm in the response message.  This prevents explicit certificate confirmation and saves the overhead of a further message round-trip. round trip.  Otherwise, the PKI management entity SHOULD <bcp14>SHOULD</bcp14> include confirmWaitTime as described in <xref target="Header" format="default"/>.</t>
          <t>If the EE did not request implicit confirmation or implicit confirmation was not granted by the PKI management entity, certificate confirmation MUST <bcp14>MUST</bcp14> be performed as follows.  If the EE successfully received the certificate, it MUST <bcp14>MUST</bcp14> send a certConf message in due time. On receiving a valid certConf message, the PKI management entity MUST <bcp14>MUST</bcp14> respond with a pkiConf message. If the PKI management entity does not receive the expected certConf message in time time, it MUST <bcp14>MUST</bcp14> handle this like a rejection by the EE.  In case of rejection, depending on its policy policy, the PKI management entity MAY <bcp14>MAY</bcp14> revoke the newly issued certificate, notify a monitoring system, or log the event internally.</t>
		  <t>Note: Depending on PKI policy, a new certificate may be published by a PKI management entity, and explicit confirmation may be required. In this case case, it is advisable not to do the publication until a positive certificate confirmation has been received.  This way way, the need to revoke the certificate on negative confirmation can be avoided.</t>
          <t>If the certificate request was rejected by the CA, the PKI management entity MUST <bcp14>MUST</bcp14> return an ip message containing the status code "rejection" as described in <xref target="Error" format="default"/> format="default"/>, and the certifiedKeyPair field SHALL <bcp14>SHALL</bcp14> be omitted.  The EE MUST NOT <bcp14>MUST NOT</bcp14> react to such an ip message with a certConf message message, and the PKI management operation MUST <bcp14>MUST</bcp14> be terminated.</t>
          <t keepWithNext="true">Detailed Message Description:</t>
          <artwork align="left" name="" type="" alt=""><![CDATA[
          <sourcecode type="pseudocode"><![CDATA[
Initialization Request -- ir

Field                         Value

header
    -- As described in Section 3.1

body
    -- The request of the EE for a new certificate
  ir                          REQUIRED
    -- MUST contain a sequence of one CertReqMsg
    -- If more certificates are required, further PKI management
    --   operations needs to be initiated
    certReq                   REQUIRED
      certReqId               REQUIRED
    -- MUST be 0
      certTemplate            REQUIRED
        version               OPTIONAL
    -- MUST be 2 if supplied
        subject               REQUIRED
    -- The EE subject name EE's identity MUST be carried in the subject field
    --   and/or the subjectAltName extension.
    -- If subject name is present only in the subjectAltName
    --   extension, then the subject field MUST be a NULL-DN
        publicKey             OPTIONAL
    -- MUST be present if local key generation is used
    -- MAY be absent if central key generation is requested
          algorithm           OPTIONAL
    -- MUST be present if local key generation is used and MUST
    --   include the subject public key algorithm identifier
    -- MAY be present if central key generation is requested and and,
    --   if present, informs the KGA of algorithm and parameter
    --   preferences regarding the to-be-generated key pair
          subjectPublicKey    REQUIRED
    -- MUST contain the public key to be certified in case of local
    --   key generation
    -- MUST be a zero-length BIT STRING if central key generation
    --   is requested
        extensions            OPTIONAL
    -- MAY include end-entity-specific X.509 extensions of the
    --   requested certificate certificate, like subject alternative name, key
    --   usage, and extended key usage
    -- The subjectAltName extension MUST be present if the EE subject
    --   name includes a subject alternative name.
    popo                      OPTIONAL
    -- MUST be present if local key generation is used
    -- MUST be absent if central key generation is requested
      signature               OPTIONAL
    -- MUST be used by an EE if the key can be used for signing signing, and
    --   if used used, it MUST have the type POPOSigningKey
        poposkInput           PROHIBITED
    -- MUST NOT be used; it is not needed because subject and
    --   publicKey are both present in the certTemplate
        algorithmIdentifier   REQUIRED
    -- The signature algorithm MUST be consistent with the publicKey
    --   algorithm field of the certTemplate
        signature             REQUIRED
    -- MUST contain the signature value computed over the DER-encoded
    --   certTemplate   certReq
      raVerified              OPTIONAL
    -- MAY be used by an RA after verifying the proof-of-possession
    --   provided by the EE

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    REQUIRED
    -- As described in Section 3.3

Initialization Response -- ip

Field                         Value

header
    -- As described in Section 3.1

body
    -- The response of the CA to the request as appropriate
  ip                          REQUIRED
    caPubs                    OPTIONAL
    -- MAY be used if the certifiedKeyPair field is present
    -- If used used, it MUST contain only a trust anchor, e.g., root
    --   certificate, of the certificate contained in certOrEncCert
    response                  REQUIRED
    -- MUST contain a sequence of one CertResponse
      certReqId              REQUIRED
    -- MUST be 0
      status                  REQUIRED
    -- PKIStatusInfo structure MUST be present
        status                REQUIRED
    -- positive values allowed: "accepted", "grantedWithMods"
    -- negative values allowed: "rejection"
    -- "waiting" only allowed with a polling use case as described in
    --   in Section 4.4
        statusString          OPTIONAL
    -- MAY be any human-readable text for debugging, logging for logging, or to
    --   to display in a GUI
        failInfo              OPTIONAL
    -- MAY be present if status is "rejection"
    -- MUST be absent if status is "accepted" or "grantedWithMods"
      certifiedKeyPair        OPTIONAL
    -- MUST be present if status is "accepted" or "grantedWithMods"
    -- MUST be absent if status is "rejection"
        certOrEncCert         REQUIRED
    -- MUST be present if status is "accepted" or "grantedWithMods"
          certificate         REQUIRED
    -- MUST be present when certifiedKeyPair is present
    -- MUST contain the newly enrolled X.509 certificate
        privateKey            OPTIONAL
    -- MUST be absent in case of local key generation or "rejection"
    -- MUST contain the encrypted private key in an EnvelopedData
    --   structure as specified in Section 4.1.6 in case the private
    --   private key was generated centrally

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    REQUIRED
    -- As described in Section 3.3
    -- MUST contain the chain of the certificate present in
    --   certOrEncCert
    -- Duplicate certificates MAY be omitted

Certificate Confirmation -- certConf

Field                         Value

header
    -- As described in Section 3.1

body
    -- The message of the EE sends as a confirmation to the PKI
    --   management entity to accept or reject the issued
    --   certificates
  certConf                    REQUIRED
    -- MUST contain a sequence of one CertStatus
    CertStatus                REQUIRED
      certHash                REQUIRED
    -- MUST be the hash value of the certificate.
    -- The hash algorithm to use MUST be the hash algorithm indicated
    --   in the below hashAlg field.  If the hashAlg field is not
    --   set, it MUST be the hash algorithm defined by the algorithm
    --   identifier of the certificate signature or the dedicated
    --   hash algorithm defined in RFCBBBB [RFC9481] for the used certificate
    --   signature algorithm.
      certReqId               REQUIRED
    -- MUST be 0
      statusInfo              OPTIONAL
    -- PKIStatusInfo structure should be present
    -- Omission indicates acceptance of the indicated certificate
        status                REQUIRED
    -- positive values allowed: "accepted"
    -- negative values allowed: "rejection"
        statusString          OPTIONAL
    -- MAY be any human-readable text for debugging, for logging, or to
    --   to display in a GUI
        failInfo              OPTIONAL
    -- MAY be present if status is "rejection"
    -- MUST be absent if status is "accepted"
      hashAlg                 OPTIONAL
    -- The hash algorithm to use for calculating the above certHash
    -- If used, the pvno field in the header MUST be cmp2021 (3). For
    --   For backward compatibility it is NOT RECOMMENDED to compatibility, use of this field is
    --   field,   NOT RECOMMENDED if the hash algorithm to use can be
    --   identified by
    -- other means, means; see above.

protection                    REQUIRED
    -- As described in Section 3.2
    -- MUST use the same credentials as in the first request message
    --   of this PKI management operation

extraCerts                    RECOMMENDED
    -- As described in Section 3.3
    -- MAY be omitted if the message size is critical and the PKI
    --   management entity caches the CMP protection certificate from
    --   the first request message of this PKI management operation

PKI Confirmation -- pkiConf

Field                         Value

header
    -- As described in Section 3.1

body
  pkiconf                     REQUIRED
    -- The content of this field MUST be NULL

protection                    REQUIRED
    -- As described in Section 3.2
    -- MUST use the same credentials as in the first response
    --   message of this PKI management operation

extraCerts                    RECOMMENDED
    -- As described in Section 3.3
    -- MAY be omitted if the message size is critical and the EE has
    --   cached the CMP protection certificate from the first
    --   response message of this PKI management operation
                    ]]></artwork>
                    ]]></sourcecode>
        </section>
        <section anchor="EE_trustedPKI" numbered="true" toc="default">
          <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 EE 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 prerequisites in <xref target="Prereq" format="default"/>:</t> format="default"/> are as follows:</t>

          <ul spacing="normal">
	    <li>The certificate used by the EE MUST <bcp14>MUST</bcp14> have been enrolled by the PKI it requests another certificate from.</li>
            <li>When using the generalInfo field certProfile, the EE MUST <bcp14>MUST</bcp14> know the identifier needed to indicate the requested certificate profile.</li>
          </ul>
          <t keepWithNext="true">The message sequence for this PKI management operation is identical to that given in <xref target="EE_newPKI" format="default"/>, with the following changes:</t>
          <ol spacing="normal" type="%d"> type="1">
	    <li>
	      <t>The body of the first request and response SHOULD <bcp14>SHOULD</bcp14> be cr and cp. Otherwise Otherwise, ir and ip MUST <bcp14>MUST</bcp14> be used.</t>
	      <t>Note: Since the difference between ir/ip and cr/cp is syntactically not essential, an ir/ip may be used in this PKI management operation.</t>
	    </li>
            <li>The caPubs field in the certificate response message MUST <bcp14>MUST</bcp14> be absent.</li>
          </ol>
        </section>
        <section anchor="EE_Update" numbered="true" toc="default">
          <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 certificate it wishes to update as the CMP protection certificate. Both for authenticating 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 prerequisites in <xref target="Prereq" format="default"/>:</t> format="default"/> are as follows:</t>
          <ul spacing="normal">
		    <li>The certificate the EE wishes to update MUST NOT <bcp14>MUST NOT</bcp14> be expired or revoked and MUST <bcp14>MUST</bcp14> have been issued by the addressed CA.</li>
            <li>A new public-private key pair should be used.</li>
            <li>When using the generalInfo field certProfile, the EE MUST <bcp14>MUST</bcp14> know the identifier needed to indicate the requested certificate profile.</li>
          </ul>
          <t keepWithNext="true">The message sequence for this PKI management operation is identical to that given in <xref target="EE_newPKI" format="default"/>, with the following changes:</t>
          <ol spacing="normal" type="%d"> type="1">
		    <li>The body of the first request and response MUST <bcp14>MUST</bcp14> be kur and kup, respectively.</li>
            <li>Protection of the kur MUST <bcp14>MUST</bcp14> be performed using the certificate to be updated.</li>
            <li>The subject field and/or the subjectAltName extension of the certTemplate MUST <bcp14>MUST</bcp14> contain the EE subject name of the existing certificate to be updated, without modifications.</li>
            <li>The certTemplate SHOULD <bcp14>SHOULD</bcp14> contain the subject and/or subjectAltName extension and publicKey of the EE only.</li>
            <li>The oldCertId control MAY <bcp14>MAY</bcp14> be used to make clear which certificate is to be updated.</li>
            <li>The caPubs field in the kup message MUST <bcp14>MUST</bcp14> be absent.</li>
          </ol>
          <t keepWithNext="true">As part of the certReq structure of the kur kur, the oldCertId control is added after the certTemplate field.</t>
          <artwork align="left" name="" type="" alt=""><![CDATA[
          <sourcecode type="pseudocode"><![CDATA[
    controls
      type                    RECOMMENDED
    -- MUST be the value id-regCtrl-oldCertID, if present
      value
        issuer                REQUIRED
        serialNumber          REQUIRED
    -- MUST contain the issuer and serialNumber of the certificate
    --   to be updated
                    ]]></artwork>
                    ]]></sourcecode>
        </section>
        <section anchor="EE_P10" numbered="true" toc="default">
          <name>Enrolling an End Entity Using a PKCS#10 PKCS #10 Request</name>
		  <t>This PKI management operation can be used by an EE to request a certificate using the <xref target="RFC2986" format="default">PKCS#10</xref> format="default">PKCS #10</xref> format to interoperate with CAs not supporting <xref target="RFC4211" format="default">CRMF</xref>. This offers a variation of the PKI management operations specified in Sections <xref target="EE_newPKI" format="counter"/> to <xref target="EE_Update" format="counter"/>.</t>
          <t>In this PKI management operation, the public key and all further certificate template data MUST <bcp14>MUST</bcp14> be contained in the subjectPKInfo and other certificationRequestInfo fields of the PKCS#10 PKCS #10 structure.</t>
          <t>The prerequisites are the same as given in <xref target="EE_trustedPKI" format="default"/>.</t>
          <t keepWithNext="true">The message sequence for this PKI management operation is identical to that given in Sections <xref target="EE_newPKI" format="counter"/> to <xref target="EE_Update" format="counter"/>, with the following changes:</t>
          <ol spacing="normal" type="%d"> type="1">
			<li>The body of the first request and response MUST <bcp14>MUST</bcp14> be p10cr and cp, respectively.</li>
            <li>The certReqId in the cp message MUST <bcp14>MUST</bcp14> be -1.</li>
          </ol>
          <t keepWithNext="true">Detailed Message Description:</t>
          <artwork align="left" name="" type="" alt=""><![CDATA[
          <sourcecode type="pseudocode"><![CDATA[
Certification Request -- p10cr

Field                         Value

header
    -- As described in Section 3.1

body
    -- The request of the EE for a new certificate using a PKCS#10 PKCS #10
    --   certificate request
  p10cr                       REQUIRED
    certificationRequestInfo  REQUIRED
      version                 REQUIRED
    -- MUST be 0 to indicate PKCS#10 V1.7 PKCS #10 v1.7
      subject                 REQUIRED
    -- The EE subject name MUST be carried in the subject field
    --   and/or the subjectAltName extension.
    -- If subject name is present only in the subjectAltName
    --   extension, then the subject field MUST be a NULL-DN
      subjectPKInfo           REQUIRED
        algorithm             REQUIRED
    -- MUST include the subject public key algorithm identifier
        subjectPublicKey      REQUIRED
    -- MUST include the public key to be certified
      attributes              OPTIONAL
    -- MAY include end-entity-specific X.509 extensions of the
    --   requested certificate like subject alternative name,
    --   key usage, and extended key usage
    -- The subjectAltName extension MUST be present if the EE
    --   subject name includes a subject alternative name.
    signatureAlgorithm        REQUIRED
    -- The signature algorithm MUST be consistent with the
    --   subjectPKInfo field.
    signature                 REQUIRED
    -- MUST contain the self-signature for proof-of-possession

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    REQUIRED
    -- As described for the underlying PKI management operation
                    ]]></artwork>
                    ]]></sourcecode>
        </section>
        <section anchor="EE_MAC" numbered="true" toc="default">
          <name>Using MAC-Based Protection for Enrollment</name>
		  <t>This is a variant of the PKI management operations described in Sections <xref target="EE_newPKI" format="counter"/>, <xref target="EE_trustedPKI" format="counter"/> format="counter"/>, and <xref target="EE_P10" format="counter"/>.  It should be used by an EE to request a certificate of a new PKI in case it does not have a certificate to prove its identity to the target PKI, PKI but has some secret information shared with the PKI management entity.  Therefore, the request and response messages are MAC-protected using this shared secret information.  The distribution of this shared secret is out of scope for this document. The PKI management entity checking the MAC-based protection MUST <bcp14>MUST</bcp14> replace this protection according to <xref target="RA_Replace" format="default"/> format="default"/>, as the next hop may not know the shared secret information.</t>
		  <t>Note: The entropy of the shared secret information is crucial 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.ietf-lamps-cmp-updates" format="default"/>.</t> target="RFC9480" format="default">CMP Updates</xref>.</t>
          <t keepWithNext="true">Specific prerequisites augmenting the prerequisites in <xref target="Prereq" format="default"/>:</t> format="default"/> are as follows:</t>
          <ul spacing="normal">
		    <li>
			  <t>Rather than using private keys, certificates, and trust anchors, the EE and the PKI management entity MUST <bcp14>MUST</bcp14> share secret information.</t>
			  <t>Note: The shared secret information MUST <bcp14>MUST</bcp14> be established out-of-band, out of band, e.g., by a service technician during initial local configuration.</t>
			</li>
            <li>When using the generalInfo field certProfile, the EE MUST <bcp14>MUST</bcp14> know the identifier needed to indicate the requested certificate profile.</li>
          </ul>
          <t keepWithNext="true">The message sequence for this PKI management operation is identical to that given in Sections <xref target="EE_newPKI" format="counter"/>, <xref target="EE_trustedPKI" format="counter"/> format="counter"/>, and <xref target="EE_P10" format="counter"/>, with the following changes:</t>
          <ol spacing="normal" type="%d"> type="1">
		    <li>The protection of all messages MUST <bcp14>MUST</bcp14> be MAC-based. Therefore, extraCerts fields of all messages do not contain CMP protection certificates and associated chains.</li>
            <li>In case the sending entity does not know its own name by now, it MUST put the NULL-DN into the
            <li>The sender field. The senderKID MUST field <bcp14>MUST</bcp14> contain a reference name the recipient PKI management entity can use to identify the shared secret information used for message protection. This name <bcp14>MUST</bcp14> be placed in the protection, e.g., commonName field of the username directoryName choice. The senderKID <bcp14>MUST</bcp14> contain the same name as in the commonName field of the EE.</li> sender field. In case the sending entity does not yet know for which name to request the certificate, it can use this commonName in the subject field of the certTemplate.</li>
          </ol>
          <t>See <xref target="Transfer_types" format="default"/> of <xref target="I-D.ietf-lamps-cmp-algorithms" format="default"> CMP target="RFC9481" format="default" sectionFormat="of" section="6">CMP Algorithms</xref> for details 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 computational overhead.</t>
        </section>
        <section anchor="EE_centralKeyGeneration" numbered="true" toc="default">
          <name>Adding Central Key Pair Generation to Enrollment</name>
          <t>This is a variant of the PKI management operations described in Sections <xref target="EE_newPKI" format="default"/> format="counter"/> to <xref target="EE_P10" format="default"/> format="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-private key pair itself or central generation of the EE key material is preferred.  It is a matter of the local implementation which Which PKI management entity will act as Key Generation Authority (KGA) and performs perform the key generation. generation is a matter of the local implementation.  This PKI management entity MUST <bcp14>MUST</bcp14> use a certificate containing the additional extended key usage extension id-kp-cmKGA in order to be accepted by the EE as a legitimate key generation authority.</t>
		  <t>Note: As described in <xref target="RA_on-behalf_request" format="default"/>, the KGA can use the PKI management operation described in <xref 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 certificate on behalf of the EE EE, as the old EE credential is not available to the KGA for protecting this message.  Therefore, if the EE uses the PKI management operation described in <xref target="EE_Update" format="default"/>, the KGA MUST <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 EE from the CA.</t>
          <t>Generally speaking, it is strongly preferable to generate public-private key pairs locally at the EE.  This is advisable to make sure that the entity 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>
          <ul spacing="normal">
            <li>
			  <t>Lack
			  <t>lack of sufficient initial entropy.</t> entropy</t>
			  <t>Note: Good random numbers are needed not only needed for key generation but also for session keys and nonces in any security protocol. Therefore, a decent security architecture should anyways support good random number generation on the EE side or provide enough initial entropy for the RNG random number generator seed to guarantee good pseudo-random pseudorandom number generation.  Yet maybe this is not the case at the time of requesting an initial certificate during manufacturing.</t>
			  </li>
            <li>
			  <t>Lack
			  <t>lack of computational resources, in particular particular, for RSA key generation.</t> generation</t>
			  <t>Note: Since key generation could be performed in advance to the certificate enrollment communication, it is often not time critical.</t>
			  </li>
          </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>The EE requesting central key generation MUST <bcp14>MUST</bcp14> omit the publicKey field from the certTemplate or, in case it has a preference on the key type to be generated, provide this preference in the algorithm sub-field and fill the subjectPublicKey sub-field with a zero-length BIT STRING.  Both variants indicate to the PKI management entity that a new key pair shall be generated centrally on behalf of the EE.</t>
	  <t>Note: As the protection of centrally generated keys in the response message has been extended to EncryptedKey by <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 2.7</xref>, target="RFC9480" format="default" sectionFormat="of" section="2.7">CMP Updates</xref>, EnvelopedData is the preferred alternative to EncryptedValue.
	  In <xref target="RFC4211" format="default">CRMF Section 2.1.9</xref> format="default" sectionFormat="comma" section="2.1">CRMF</xref>, point 9, the use of EncryptedValue has been deprecated in favor of the EnvelopedData structure.  Therefore, this profile requires using EnvelopedData EnvelopedData, as specified in <xref target="RFC5652" format="default">CMS Section 6</xref>. format="default" sectionFormat="of" section="6">CMS</xref>.  When EnvelopedData is to be used in a PKI management operation, CMP v3 MUST <bcp14>MUST</bcp14> be indicated in the message header already for the initial request message, message; see <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 2.20</xref>.</t> target="RFC9480" format="default" sectionFormat="of" section="2.20">CMP Updates</xref>.</t>
          <figure anchor="CMP_envelop">
            <name>Encrypted Private Key Container</name>
            <artwork align="center" name="" type="" alt=""><![CDATA[
+----------------------------------+
| EnvelopedData                    |
| [RFC5652] [RFC5652], Section 6             |
| +------------------------------+ |
| | SignedData                   | |
| | [RFC5652] [RFC5652], Section 5         | |
| | +--------------------------+ | |
| | | AsymmetricKeyPackage     | | |
| | | [RFC5958]                | | |
| | | +----------------------+ | | |
| | | | private key          | | | |
| | | +----------------------+ | | |
| | +--------------------------+ | |
| +------------------------------+ |
+----------------------------------+
                   ]]></artwork>
          </figure>
          <t>The PKI management entity delivers the private key in the privateKey field in the certifiedKeyPair structure of the response message also containing the newly issued certificate.</t>
          <t>The private key MUST <bcp14>MUST</bcp14> be provided as an AsymmetricKeyPackage structure as defined in <xref target="RFC5958" format="default">RFC&nbsp;5958</xref>.</t> format="default"/>.</t>
          <t>This AsymmetricKeyPackage structure MUST <bcp14>MUST</bcp14> be wrapped in a SignedData structure, as specified in <xref target="RFC5652" format="default">CMS Section 5</xref> format="default" sectionFormat="of" section="5">CMS</xref> and <xref target="RFC8933" format="default"/>, and signed by the KGA generating the key pair. The signature MUST <bcp14>MUST</bcp14> be performed using a private key related to a certificate asserting the extended key usage id-kp-cmKGA id-kp-cmKGA, as described in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 2.2</xref> target="RFC9480" format="default" sectionFormat="of" section="2.2">CMP Updates</xref>, to demonstrate authorization to generate key pairs on behalf of an EE.  For response messages using signature-based protection, the EE MUST <bcp14>MUST</bcp14> validate the signer certificate contained in the SignedData structure and SHOULD <bcp14>SHOULD</bcp14> authorize the KGA considering any given id-kp-cmKGA extended key usage in the signer certificate.  For response messages using MAC-based protection protection, the EE MAY <bcp14>MAY</bcp14> omit the validation as it may not be possible or meaningful to the EE.  In this case case, the EE authorizes the KGA using the shard secret information.</t>
          <t>The SignedData structure MUST <bcp14>MUST</bcp14> be wrapped in an EnvelopedData structure, as specified in <xref target="RFC5652" format="default">CMS Section 6</xref>, format="default" sectionFormat="of" section="6">CMS</xref>, encrypting it using a newly generated symmetric content-encryption key.</t>
          <t>This content-encryption key MUST <bcp14>MUST</bcp14> be securely provided as part of the EnvelopedData structure to the EE using one of three key management techniques. The choice of the key management technique to be used by the PKI management entity depends on the authentication mechanism the EE chose to protect the request message. See <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 2.7</xref> target="RFC9480" format="default" sectionFormat="of" section="2.7">CMP Updates</xref> for details on which key management technique to use.</t>
          <ul spacing="normal">
            <li>
              <t>Signature-based protection of the request message:</t>
			  <t>In this case case, the choice depends on the type of the public key in the CMP protection certificate used by the EE in its request.</t>
              <ul spacing="normal">
                <li>The content-encryption key SHALL <bcp14>SHALL</bcp14> be protected using the key transport key management technique, see technique (see <xref target="EE_KGTrans" format="default"/>, format="default"/>) if the key type supports this.</li>
                <li>The content-encryption key SHALL <bcp14>SHALL</bcp14> be protected using the key agreement key management technique, see technique (see <xref target="EE_KGAgree" format="default"/>, format="default"/>) if the key type supports this.</li>
              </ul>
            </li>
            <li>
			  <t>MAC-based protected protection of the request message:</t>
              <ul spacing="normal">
                <li>The content-encryption key SHALL <bcp14>SHALL</bcp14> be protected using the password-based key management technique, see technique (see <xref target="EE_KGPB" format="default"/>, format="default"/>) if and only if the EE used MAC-based protection for the request message.</li>
              </ul>
			</li>
          </ul>
          <t keepWithNext="true">Specific prerequisites augmenting those of the respective certificate enrollment PKI management operations:</t> operations are as follows:</t>
          <ul spacing="normal">
		    <li>If signature-based protection is used, the EE MUST <bcp14>MUST</bcp14> be able to authenticate and authorize the KGA, KGA using suitable information, which includes a trust anchor.</li>
			<li>If MAC-based protection is used, the KGA MUST <bcp14>MUST</bcp14> also know the shared secret information to protect the encrypted transport of the newly generated key pair. Consequently, the EE can also authorize the KGA.</li>
            <li>The PKI management entity MUST <bcp14>MUST</bcp14> have a certificate containing the additional extended key usage extension id-kp-cmKGA for signing the SignedData structure containing the private key package.</li>
            <li>
			  <t>For encrypting the SignedData structure structure, a fresh content-encryption key to be used by the symmetric encryption algorithm MUST <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>
			</li>
          </ul>
          <t keepWithNext="true">Detailed Description of the privateKey Field:</t>
          <artwork align="left" name="" type="" alt=""><![CDATA[
          <sourcecode type="pseudocode"><![CDATA[
        privateKey            REQUIRED
    -- MUST be an EnvelopedData structure structure, as specified in CMS
    --   Section 6 of CMS [RFC5652]
          version             REQUIRED
    -- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and
    --   KeyTransRecipientInfo
    -- MUST be 0 for recipientInfo type PasswordRecipientInfo
          recipientInfos      REQUIRED
    -- MUST contain a sequence of one RecipientInfo, which MUST be
    --   kari   ktri of type KeyAgreeRecipientInfo KeyTransRecipientInfo (see section Section 4.1.6.1),
    --   ktri   kari of type KeyTransRecipientInfo KeyAgreeRecipientInfo (see section Section 4.1.6.2), or
    --   pwri of type PasswordRecipientInfo (see section Section 4.1.6.3)
          encryptedContentInfo
                              REQUIRED
            contentType       REQUIRED
    -- MUST be id-signedData
            contentEncryptionAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the algorithm used for
    --   content encryption
    -- The algorithm type MUST be a PROT_SYM_ALG as specified in
    --   RFCBBBB   [RFC9481], Section 5
            encryptedContent  REQUIRED
    -- MUST be the SignedData structure structure, as specified in CMS
    -- Section 5
    -- of CMS [RFC5652] and [RFC8933] [RFC8933], in encrypted form
              version         REQUIRED
    -- MUST be 3
              digestAlgorithms
                              REQUIRED
    -- MUST contain a sequence of one AlgorithmIdentifier element
    -- MUST be the algorithm identifier of the digest algorithm
    --   used for generating the signature and match the signature
    --   algorithm specified in signatureAlgorithm, signatureAlgorithm; see [RFC8933]
              encapContentInfo
                              REQUIRED
    -- MUST contain the content that is to be signed
                eContentType  REQUIRED
    -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958]
                eContent      REQUIRED
    -- MUST be of type AsymmetricKeyPackage and
    -- MUST contain a sequence of one OneAsymmetricKey element
                  version     REQUIRED
    -- MUST be 1 (indicating v2)
                  privateKeyAlgorithm
                              REQUIRED
    -- The privateKeyAlgorithm field MUST contain the algorithm
    --   identifier of the asymmetric key pair algorithm
                  privateKey  REQUIRED
                  publicKey   REQUIRED
    -- MUST contain the public key corresponding to the private key
    --   for simplicity and consistency with v2 of OneAsymmetricKey
              certificates    REQUIRED
    -- MUST contain the certificate for the private key used to sign
    --   the signedData content, together with its chain
    -- The first certificate in this field MUST be the KGA
    --   certificate used for protecting this content
    -- Self-signed certificates should not be included and MUST NOT
    --   be trusted based on their inclusion in any case
                signerInfos   REQUIRED
    -- MUST contain a sequence of one SignerInfo element
                version       REQUIRED
    -- MUST be 3
                sid           REQUIRED
                  subjectKeyIdentifier
                              REQUIRED
    -- MUST be the subjectKeyIdentifier of the KGA certificate
                digestAlgorithm
                              REQUIRED
    -- MUST be the same as in the digestAlgorithms field of
    --   encryptedContent
                signedAttrs   REQUIRED
    -- MUST contain an id-contentType attribute containing the value
    --   id-ct-KP-aKeyPackage
    -- MUST contain an id-messageDigest attribute containing the
    --   message digest of eContent
    -- MAY contain an id-signingTime attribute containing the time
    --   of a signature.  It SHOULD be omitted if the transactionTime
    --   field is not present in the PKIHeader.
    -- For details on the signed attributes attributes, see CMS Section Sections 5.3 and
    --   Section   11 of CMS [RFC5652] and [RFC8933]
                signatureAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the signature algorithm
    --   used for calculation of the signature bits
    -- The signature algorithm type MUST be a MSG_SIG_ALG MSG_SIG_ALG, as
    --   specified in RFCBBBB [RFC9481], Section 3 3, and MUST be consistent
    --   with the subjectPublicKeyInfo field of the KGA certificate
                signature     REQUIRED
    -- MUST be the digital signature of the encapContentInfo
                    ]]></artwork>
    ]]></sourcecode>
		  <t>As stated in Section 1.5, <xref target="Scope"/>, all fields of the ASN.1 syntax that are defined in RFC 5652 [RFC5652] <xref target="RFC5652"/> but are not explicitly specified here SHOULD NOT <bcp14>SHOULD NOT</bcp14> be used.</t>
          <section anchor="EE_KGTrans" numbered="true" toc="default">
            <name>Using  the Key Transport Key Management Technique</name>
            <t>This variant can be applied in combination with the PKI management operations specified in Sections <xref target="EE_newPKI" format="default"/> format="counter"/> to <xref target="EE_Update" format="default"/> format="counter"/> using signature-based protection of CMP messages.  The EE certificate used for the signature-based protection of the request message MUST <bcp14>MUST</bcp14> contain a public key supporting key transport and allow for the key usage "keyEncipherment".  The related key pair MUST <bcp14>MUST</bcp14> be used for encipherment of the content-encryption key.  For this key management technique, the KeyTransRecipientInfo structure MUST <bcp14>MUST</bcp14> be used in the contentInfo field.</t>
            <t>The KeyTransRecipientInfo structure included into the EnvelopedData structure is specified in <xref target="RFC5652" format="default">CMS Section 6.2.1</xref>.</t> format="default" sectionFormat="of" section="6.2.1">CMS</xref>.</t>
            <t keepWithNext="true">Detailed Description of the KeyTransRecipientInfo Structure:</t>
            <artwork align="left" name="" type="" alt=""><![CDATA[
            <sourcecode type="pseudocode"><![CDATA[
            ktri              REQUIRED
    -- MUST be a KeyTransRecipientInfo as specified in CMS
    -- Section 6.2.1
    --   of CMS [RFC5652]
              version         REQUIRED
    -- MUST be 2
              rid             REQUIRED
    -- MUST contain the subjectKeyIdentifier of the CMP protection
    --   certificate, if available, in the rKeyId choice choice, and the
    --   subjectKeyIdentifier MUST equal the senderKID in the
    --   PKIHeader.
    -- If the CMP protection certificate does not contain a
    --   subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
    --   be used.
              keyEncryptionAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the key transport
    --   algorithm.  The algorithm type MUST be a KM_KT_ALG as
    --   specified in RFCBBBB [RFC9481], Section 4.2
              encryptedKey    REQUIRED
    -- MUST be the encrypted content-encryption key
                        ]]></artwork>
                        ]]></sourcecode>
          </section>
          <section anchor="EE_KGAgree" numbered="true" toc="default">
            <name>Using the Key Agreement Key Management Technique</name>
            <t>This variant can be applied in combination with the PKI management operations specified in Sections <xref target="EE_newPKI" format="default"/> format="counter"/> to <xref target="EE_Update" format="default"/> format="counter"/>, using signature-based protection of CMP messages.  The EE certificate used for the signature-based protection of the request message MUST <bcp14>MUST</bcp14> contain a public key supporting key agreement and allow for the key usage "keyAgreement". The related key pair MUST <bcp14>MUST</bcp14> be used for establishment of the content-encryption key.  For this key management technique technique, the KeyAgreeRecipientInfo structure MUST <bcp14>MUST</bcp14> be used in the contentInfo field.</t>
            <t>The KeyAgreeRecipientInfo structure included into the EnvelopedData structure is specified in <xref target="RFC5652" format="default">CMS Section 6.2.2</xref>.</t> format="default" sectionFormat="of" section="6.2.2">CMS</xref>.</t>

<t keepWithNext="true">Detailed Description of the KeyAgreeRecipientInfo Structure:</t>
            <artwork align="left" name="" type="" alt=""><![CDATA[
            <sourcecode type="pseudocode"><![CDATA[
            kari              REQUIRED
    -- MUST be a KeyAgreeRecipientInfo as specified in CMS Section
    --   6.2.2 of CMS [RFC5652]
              version         REQUIRED
    -- MUST be 3
              originator      REQUIRED
    -- MUST contain the subjectKeyIdentifier of the CMP protection
    --   certificate, if available, in the subjectKeyIdentifier
    --   choice   choice, and the subjectKeyIdentifier MUST equal the senderKID
    --   senderKID in the PKIHeader.
    -- If the CMP protection certificate does not contain a
    --   subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
    --   be used.
              ukm             RECOMMENDED
    -- MUST be used when 1-pass ECMQV 1-Pass Elliptic Curve Menezes-Qu-Vanstone
    --   (ECMQV) is used, used; see [RFC5753]
    -- SHOULD be present to ensure uniqueness of the key
    --   encryption key
              keyEncryptionAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the key agreement
    --   algorithm
    -- The algorithm type MUST be a KM_KA_ALG as specified in
    --   RFCBBBB   [RFC9481], Section 4.1
    -- The parameters field of the key agreement algorithm MUST
    --   contain the key wrap algorithm.  The algorithm type
    --   MUST be a KM_KW_ALG as specified in RFCBBBB [RFC9481], Section 4.3
              recipientEncryptedKeys
                              REQUIRED
    -- MUST contain a sequence of one RecipientEncryptedKey
                rid           REQUIRED
    -- MUST contain the subjectKeyIdentifier of the CMP protection
    --   certificate, if available, in the rKeyId choice choice, and the
    --   subjectKeyIdentifier MUST equal the senderKID in the
    --   PKIHeader.
    -- If the CMP protection certificate does not contain a
    --   subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
    --   be used
                  encryptedKey
                              REQUIRED
    -- MUST be the encrypted content-encryption key
                        ]]></artwork>
                        ]]></sourcecode>
          </section>
          <section anchor="EE_KGPB" numbered="true" toc="default">
            <name>Using the Password-Based Key Management Technique</name>
            <t>This variant can be applied in combination with the PKI management operation specified in <xref target="EE_MAC" format="default"/> format="default"/>, using MAC-based protection of CMP messages.  The shared secret information used for the MAC-based protection MUST <bcp14>MUST</bcp14> also be used for the encryption of the content-encryption key but with a different salt value applied in the key derivation algorithm.  For this key management technique, the PasswordRecipientInfo structure MUST <bcp14>MUST</bcp14> be used in the contentInfo field.</t>
			<t>Note: The entropy of the shared secret information is crucial for the level of protection when using a password-based key management technique.  For centrally generated key pairs, the entropy of the shared secret information SHALL NOT <bcp14>SHALL NOT</bcp14> be less than the security strength of the centrally generated key pair.  Further guidance is available in <xref target="Security" format="default"/>.</t>
            <t>The PasswordRecipientInfo structure included into the EnvelopedData structure is specified in <xref target="RFC5652" format="default">CMS Section 6.2.4</xref>.</t> format="default" sectionFormat="of" section="6.2.4">CMS</xref>.</t>
            <t keepWithNext="true">Detailed Description of the PasswordRecipientInfo Structure:</t>
            <artwork align="left" name="" type="" alt=""><![CDATA[
            <sourcecode type="pseudocode"><![CDATA[
            pwri              REQUIRED
    -- MUST be a PasswordRecipientInfo as specified in CMS
    --   Section 6.2.4 of CMS [RFC5652]
              version         REQUIRED
    -- MUST be 0
              keyDerivationAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the key derivation
    --   algorithm
    -- The algorithm type MUST be a KM_KD_ALG as specified in
    --   RFCBBBB   [RFC9481], Section 4.4
              keyEncryptionAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the key wrap algorithm
    -- The algorithm type MUST be a KM_KW_ALG as specified in
    --   RFCBBBB   [RFC9481], Section 4.3
              encryptedKey    REQUIRED
    -- MUST be the encrypted content-encryption key
                        ]]></artwork>
                        ]]></sourcecode>
          </section>
        </section>
      </section>
      <section anchor="EE_Revoke" numbered="true" toc="default">
        <name>Revoking a Certificate</name>
        <t>This PKI management operation should be used by an entity to request revocation of a certificate. Here Here, the revocation request is used by an EE to revoke one of its own certificates.</t>
        <t>The revocation request message MUST <bcp14>MUST</bcp14> be signed using the certificate that is to be revoked to prove the authorization to revoke. The revocation request message is signature-protected using this certificate. This requires, requires that the EE still possesses the private key. If this is not the case case, the revocation has to be initiated by other means, e.g., revocation by the RA RA, as specified in <xref target="RA_on-behalf_revoke" format="default"/>.</t>
        <t>An EE requests revoking a certificate of its own at the CA that issued this certificate. The PKI management entity handles the request as described in <xref target="RA_response_revocation" format="default"/> format="default"/>, and responds with a message that contains the status of the revocation from the CA.</t>
        <t keepWithNext="true">Specific prerequisites keepWithNext="true">The specific prerequisite augmenting the prerequisites in <xref target="Prereq" format="default"/>:</t> format="default"/> is as follows:</t>
        <ul spacing="normal">
		  <li>The certificate the EE wishes to revoke is not yet expired or revoked.</li>
        </ul>
        <t keepWithNext="true">Message Flow:</t>
        <artwork align="left" name="" type="" alt=""><![CDATA[
Step# EE                                  PKI management entity
 1   format rr
 2                      ->   rr      ->
 3                                        handle or forward rr
 4                                        format or receive rp
 5                      <-   rp      <-
 6   handle rp
                ]]></artwork>
        <t>For this PKI management operation, the EE MUST <bcp14>MUST</bcp14> include a sequence of one RevDetails structure in the rr message body. In the case no generic error occurred, the response to the rr MUST <bcp14>MUST</bcp14> be an rp message containing a single status field.</t>
        <t keepWithNext="true">Detailed Message Description:</t>
        <artwork align="left" name="" type="" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
Revocation Request -- rr

Field                         Value

header
    -- As described in Section 3.1

body
    -- The request of the EE to revoke its certificate
  rr                          REQUIRED
    -- MUST contain a sequence of one element of type RevDetails
    -- If more revocations are desired, further PKI management
    --   operations need to be initiated
    certDetails               REQUIRED
    -- MUST be present and is of type CertTemplate
      serialNumber            REQUIRED
    -- MUST contain the certificate serialNumber attribute of the
    --   certificate to be revoked
      issuer                  REQUIRED
    -- MUST contain the issuer attribute of the certificate to be
    --   revoked
    crlEntryDetails           REQUIRED
    -- MUST contain a sequence of one reasonCode of type CRLReason
    --   (see [RFC5280] section [RFC5280], Section 5.3.1)
    -- If the reason for this revocation is not known or shall not
    --   be published published, the reasonCode MUST be 0 (unspecified)
protection                    REQUIRED
    -- As described in Section 3.2 and using the private key related
    --   to the certificate to be revoked

extraCerts                    REQUIRED
    -- As described in Section 3.3

Revocation Response -- rp

Field                         Value

header
    -- As described in Section 3.1

body
    -- The responds response of the PKI management entity to the request as
    --   appropriate
  rp                          REQUIRED
    status                    REQUIRED
    -- MUST contain a sequence of one element of type PKIStatusInfo
      status                  REQUIRED
    -- positive value allowed: "accepted"
    -- negative value allowed: "rejection"
      statusString            OPTIONAL
    -- MAY be any human-readable text for debugging, logging for logging, or to
    --   to display in a GUI
      failInfo                OPTIONAL
    -- MAY be present if the status is "rejection"
    -- MUST be absent if the status is "accepted"

protection                    REQUIRED
    -- As described in section Section 3.2

extraCerts                    REQUIRED
    -- As described in section Section 3.3
                ]]></artwork>
                ]]></sourcecode>
      </section>
      <section anchor="EE_GeneralMessage" numbered="true" toc="default">
        <name>Support Messages</name>
        <t>The following support messages offer on demand on-demand, in-band delivery of content relevant to the EE provided by a PKI management entity.  CMP general messages and general response are used for this purpose.  Depending on the environment, these requests may be answered by an RA or CA (see also <xref target="RA_response_support" format="default"/>).</t>
        <t>The general messages and general response messages contain InfoTypeAndValue structures. In addition to those infoType values defined in <xref target="RFC4210" format="default">RFC&nbsp;4210</xref> format="default"/> and <xref target="I-D.ietf-lamps-cmp-updates" target="RFC9480" format="default">CMP Updates</xref> Updates</xref>, further OIDs MAY <bcp14>MAY</bcp14> be used to define new PKI management operations or new general-purpose support messages as needed in specific environments.</t>
        <t keepWithNext="true">The following contents are specified in this document:</t>
        <ul spacing="normal">
          <li>Get CA certificates</li> certificates.</li>
          <li>Get root CA certificate update</li> update.</li>
          <li>Get certificate request template</li> template.</li>
          <li>Get new CRLs</li> Certificate Revocation Lists (CRLs).</li>
        </ul>
        <t>The following message flow and contents are common to all general message (genm) and general response (genp) messages.</t>
        <t keepWithNext="true">Message Flow:</t>
        <artwork align="left" name="" type="" alt=""><![CDATA[
Step# EE                                   PKI management entity
 1   format genm
 2                      ->   genm    ->
 3                                        handle or forward genm
 4                                        format or receive genp
 5                      <-   genp    <-
 6   handle genp
           ]]></artwork>
        <t keepWithNext="true">Detailed Message Description:</t>
        <artwork align="left" name="" type="" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
General Message -- genm

Field                         Value

header
    -- As described in Section 3.1

body
    -- A request by the EE for information
  genm                        REQUIRED
    -- MUST contain a sequence of one element of type
    --   InfoTypeAndValue
    infoType                  REQUIRED
    -- MUST be the OID identifying one of the specific PKI
    --   management operations described below
    infoValue                 OPTIONAL
    -- MUST be as specified for the specific PKI management operation

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    REQUIRED
    -- As described in Section 3.3

General Response -- genp

Field                         Value

header
    -- As described in Section 3.1

body
    -- The response of the PKI management entity providing
    --   information
  genp                        REQUIRED
    -- MUST contain a sequence of one element of type
    --   InfoTypeAndValue
    infoType                  REQUIRED
    -- MUST be the OID identifying the specific PKI management
    --   operation described below
    infoValue                 OPTIONAL
    -- MUST be as specified for the specific PKI management operation

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    REQUIRED
    -- As described in Section 3.3
           ]]></artwork>
           ]]></sourcecode>
        <section anchor="EE_CACerts" numbered="true" toc="default">
          <name>Get CA Certificates</name>
          <t>This PKI management operation can be used by an EE to request CA certificates from the PKI management entity.</t>
          <t>An EE requests CA certificates, e.g., for chain construction, from an a PKI management entity by sending a general message with OID id-it-caCerts id-it-caCerts, as specified in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 2.14</xref>. target="RFC9480" format="default" sectionFormat="of" section="2.14">CMP Updates</xref>. The PKI management entity responds with a general response with the same OID that either contains a SEQUENCE of certificates populated with the available intermediate and issuing CA certificates or with no content in case no CA certificate is available.</t>
		  <t>No specific prerequisites apply in addition to those specified in <xref target="Prereq" format="default"/>.</t>
          <t keepWithNext="true">The message sequence for this PKI management operation is as given above, with the following specific content:</t>
          <ol spacing="normal" type="%d"> type="1">
	    <li>the infoType OID to use is id-it-caCerts</li>
            <li>the infoValue of the request MUST <bcp14>MUST</bcp14> be absent</li>
            <li>if present, the infoValue of the response MUST <bcp14>MUST</bcp14> contain a sequence of certificates</li>
          </ol>
          <t keepWithNext="true">Detailed Description of the infoValue Field of genp:</t>
          <artwork align="left" name="" type="" alt=""><![CDATA[
          <sourcecode type="pseudocode"><![CDATA[
      infoValue               OPTIONAL
    -- MUST be absent if no CA certificate is available
    -- MUST be present if CA certificates are available
    --   if present, MUST be a sequence of CMPCertificate
                ]]></artwork>
                ]]></sourcecode>
        </section>
        <section anchor="EE_RootCAUpdate" numbered="true" toc="default">
          <name>Get Root CA Certificate Update</name>
          <t>This PKI management operation can be used by an EE to request an updated root CA Certificate certificate as described in <xref target="RFC4210" format="default">Section 4.4 of RFC&nbsp;4210</xref>.</t> format="default" sectionFormat="of" section="4.4"/>.</t>
	  <t>An EE requests an update of a root CA certificate from the PKI management entity by sending a general message with OID id-it-rootCaCert. If needed for unique identification, the EE MUST <bcp14>MUST</bcp14> include the old root CA certificate in the message body, body as specified in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 2.15</xref>. target="RFC9480" format="default" sectionFormat="of" section="2.15">CMP Updates</xref>.  The PKI management entity responds with a general response with OID id-it-rootCaKeyUpdate that either contains the update of the root CA certificate consisting of up to three certificates, certificates or with no content in case no update is available.</t>
		  <t>Note: This mechanism may also be used to update trusted non-root certificates, i.e., e.g., directly trusted intermediate CA or issuing CA certificates.</t>
          <t>The newWithNew certificate is the new root CA certificate and is REQUIRED <bcp14>REQUIRED</bcp14> to be present if available.  The newWithOld certificate is REQUIRED <bcp14>REQUIRED</bcp14> to be present in the response message because it is needed for the receiving entity trusting the old root CA certificate to gain trust in the new root CA certificate.  The oldWithNew certificate is OPTIONAL <bcp14>OPTIONAL</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 specified in <xref target="Prereq" format="default"/>.</t>
          <t keepWithNext="true">The message sequence for this PKI management operation is as given above, with the following specific content:</t>
          <ol spacing="normal" type="%d"> type="1">
	    <li>the infoType OID to use is id-it-rootCaCert in the request and id-it-rootCaKeyUpdate in the response</li>
            <li>the infoValue of the request SHOULD <bcp14>SHOULD</bcp14> contain the root CA certificate the update is requested for</li>
            <li>if present, the infoValue of the response MUST <bcp14>MUST</bcp14> be a RootCaKeyUpdateContent structure</li>
          </ol>
          <t keepWithNext="true">Detailed Description of the infoValue Field of genm:</t>
          <artwork align="left" name="" type="" alt=""><![CDATA[
          <sourcecode type="pseudocode"><![CDATA[
      infoValue               RECOMMENDED
    -- MUST contain the root CA certificate to be updated if needed
    --   for unique identification
                 ]]></artwork>
                 ]]></sourcecode>
          <t keepWithNext="true">Detailed Description of the infoValue Field of genp:</t>
          <artwork align="left" name="" type="" alt=""><![CDATA[
          <sourcecode type="pseudocode"><![CDATA[
      infoValue               OPTIONAL
    -- MUST be absent if no update of the root CA certificate is
    --   available
    -- MUST be present if an update of the root CA certificate
    --   is available and MUST be of type RootCaKeyUpdateContent
        newWithNew            REQUIRED
    -- MUST be present if infoValue is present
    -- MUST contain the new root CA certificate
        newWithOld            REQUIRED
    -- MUST be present if infoValue is present
    -- MUST contain a certificate containing the new public
    --   root CA key signed with the old private root CA key
        oldWithNew            OPTIONAL
    -- MAY be present if infoValue is present
    -- MUST contain a certificate containing the old public
    --   root CA key signed with the new private root CA key
                 ]]></artwork>
                 ]]></sourcecode>
        </section>
        <section anchor="EE_Temp" numbered="true" toc="default">
          <name>Get Certificate Request Template</name>
          <t>This PKI management operation can be used by an EE to request a template with parameters for future certificate requests.</t>
		  <t>An EE requests certificate request parameters from the PKI management 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 Updates Section 2.16</xref>. target="RFC9480" format="default" sectionFormat="of" section="2.16">CMP Updates</xref>.  The EE MAY <bcp14>MAY</bcp14> indicate the certificate profile to use in the id-it-certProfile extension of the generalInfo field in the PKIHeader of the general message as described in <xref target="Header" format="default"/>.  The PKI management entity responds with a general response with the same OID that either contains requirements on the certificate request template, template or with no content in case no specific requirements are imposed by the PKI. The CertReqTemplateValue contains requirements on certificate fields and extensions in a certTemplate. Optionally Optionally, it contains a keySpec field containing requirements on algorithms acceptable for key pair generation.</t>
          <t>The EE SHOULD <bcp14>SHOULD</bcp14> follow the requirements from the received CertTemplate, CertTemplate by including in the certificate requests all the fields requested, taking over all the field values provided and filling in any remaining fields values. The EE SHOULD NOT <bcp14>SHOULD NOT</bcp14> add further fields, name components, and extensions or their (sub-)components. (sub)components.  If deviating from the recommendations of the template, the certificate request might be rejected.</t>
          <t>Note: We deliberately do not use "MUST" "<bcp14>MUST</bcp14>" or "MUST NOT" "<bcp14>MUST NOT</bcp14>" here in order to allow more flexibility in case the rules given here are not sufficient for specific scenarios. The EE can populate the certificate request as wanted and ignore any of the requirements contained in the CertReqTemplateValue. On the other hand, a PKI management entity is free to ignore or replace any parts of the content of the certificate request provided by the EE. The CertReqTemplate PKI management operation offers means to ease a joint understanding of which fields and/or which field values should be used. An example is provided in <xref target="Param_Example" format="default"/>.</t>
          <t>In case a field of type Name, e.g., subject, is present in the CertTemplate but has the value NULL-DN (i.e., has an empty list of RDN relative distinguished name (RDN) components), the field SHOULD <bcp14>SHOULD</bcp14> be included in the certificate request and filled with content provided by the EE. Similarly, in case an X.509v3 extension is present but its extnValue is empty, this means that the extension SHOULD <bcp14>SHOULD</bcp14> be included and filled with content provided by the EE. In case a Name component, for instance instance, a common name or serial number, is given but has an empty string value, the EE SHOULD <bcp14>SHOULD</bcp14> fill in a value. Similarly, in case an extension has sub-components subcomponents (e.g., an IP address in a SubjectAltName field) with empty value, values, the EE SHOULD <bcp14>SHOULD</bcp14> fill in a value.</t>
          <t>The EE MUST <bcp14>MUST</bcp14> ignore (i.e., not include and fill in) include) empty fields, extensions, and sub-components subcomponents that it does not understand or does not know suitable values to be filled fill in.</t>
          <t>The publicKey field of type SubjectPublicKeyInfo in the CertTemplate of the CertReqTemplateValue MUST <bcp14>MUST</bcp14> be omitted. In case the PKI management entity wishes to make a stipulation on algorithms the EE may use for key generation, this MUST <bcp14>MUST</bcp14> be specified using the keySpec field as specified in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 2.16</xref>.</t> target="RFC9480" format="default" sectionFormat="of" section="2.16">CMP Updates</xref>.</t>
          <t>The keySpec field, if present, specifies the public key types optionally with parameters, parameters and/or RSA key lengths for which a certificate may be requested.</t>
          <t>The value of a keySpec element with the OID id-regCtrl-algId, as specified in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 2.16</xref>, MUST target="RFC9480" format="default" sectionFormat="of" section="2.16">CMP Updates</xref>, <bcp14>MUST</bcp14> be of type AlgorithmIdentifier and give an algorithm other than RSA.  For EC keys Elliptic Curve (EC) keys, the curve information MUST <bcp14>MUST</bcp14> be specified as described in the respective standard documents.</t>
          <t>The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, as specified in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 2.16</xref>, MUST target="RFC9480" format="default" sectionFormat="of" section="2.16">CMP Updates</xref>, <bcp14>MUST</bcp14> be a positive integer value and give an RSA key length.</t>
          <t>In the CertTemplate of the CertReqTemplateValue CertReqTemplateValue, the serialNumber, signingAlg, issuerUID, and subjectUID fields MUST <bcp14>MUST</bcp14> be omitted.</t>
          <t keepWithNext="true">Specific keepWithNext="true">The specific prerequisites augmenting the prerequisites in <xref target="Prereq" format="default"/>:</t> format="default"/> is as follows:</t>
          <ul spacing="normal">
	    <li>When using the generalInfo field certProfile, the EE MUST <bcp14>MUST</bcp14> know the identifier needed to indicate the requested certificate profile.</li>
          </ul>
          <t keepWithNext="true">The message sequence for this PKI management operation is as given above, with the following specific content:</t>
          <ol spacing="normal" type="%d"> type="1">
	    <li>the infoType OID to use is id-it-certReqTemplate</li>
            <li>the id-it-certProfile generalInfo field in the header of the request MAY <bcp14>MAY</bcp14> contain the name of the requested certificate request template</li>
            <li>the infoValue of the request MUST <bcp14>MUST</bcp14> be absent</li>
            <li>if present, the infoValue of the response MUST <bcp14>MUST</bcp14> be a CertReqTemplateValue containing a CertTemplate structure and an optional keySpec field</li>
          </ol>
          <t keepWithNext="true">Detailed Description of the infoValue Field of genp:</t>
          <artwork align="left" name="" type="" alt=""><![CDATA[
          <sourcecode type="pseudocode"><![CDATA[
      InfoValue               OPTIONAL
    -- MUST be absent if no requirements are available
    -- MUST be present if the PKI management entity has any
    --   requirements on the contents of the certificate template
        certTemplate          REQUIRED
    -- MUST be present if infoValue is present
    -- MUST contain the required CertTemplate structure elements
    -- The SubjectPublicKeyInfo field MUST be absent
        keySpec               OPTIONAL
    -- MUST be absent if no requirements on the public key are
    --   available
    -- MUST be present if the PKI management entity has any
    --   requirements on the keys generated
    -- MUST contain a sequence of one AttributeTypeAndValue per
    --   supported algorithm with attribute id-regCtrl-algId or
    --   id-regCtrl-rsaKeyLen
                ]]></artwork>
                ]]></sourcecode>
        </section>
        <section anchor="EE_CRLs" numbered="true" toc="default">
          <name>CRL Update Retrieval</name>
          <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 points or authority information access extensions into the issued certificates as specified in <xref target="RFC5280" format="default">RFC&nbsp;5280</xref> into the issued certificates. format="default"/>.  In addition, CMP offers CRL provisioning functionality as part of the PKI management operation.</t>
          <t>An EE requests a CRL update from the PKI management entity by sending a general message with OID id-it-crlStatusList.  The EE MUST <bcp14>MUST</bcp14> include the CRL source identifying the requested CRL and, if available, the thisUpdate time of the most current CRL instance it already has, as specified in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 2.17</xref>. target="RFC9480" format="default" sectionFormat="of" section="2.17">CMP Updates</xref>.  The PKI management entity MUST <bcp14>MUST</bcp14> respond with a general response with OID id-it-crls.</t>
		  <t>The EE MUST <bcp14>MUST</bcp14> identify the requested CRL either by a CRL distribution point name or issuer name.</t>
		  <t>Note: CRL distribution point names can be obtained from a cRLDistributionPoints extension of a certificate to be validated or from an issuingDistributionPoint extension of the CRL to be updated. CRL issuer names can be obtained from the cRLDistributionPoints extension of a certificate, from the issuer 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 MUST <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 MUST <bcp14>MUST</bcp14> return the latest CRL available from the referenced source.  In all other cases cases, the infoValue in the response message MUST <bcp14>MUST</bcp14> be absent.</t>
		  <t>The PKI management entity should treat a CRL distribution point 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 CRL from an external location, as this location may be unavailable to that PKI management entity.</t>
          <t>In addition to the prerequisites specified in <xref target="Prereq" format="default"/>, the EE MUST <bcp14>MUST</bcp14> know which CRL to request.</t>
          <t>Note: If the EE does not want to request a specific CRL CRL, it MAY use <bcp14>MAY</bcp14> instead use a general message with OID id-it-currentCrl as specified in <xref target="RFC4210" format="default">RFC&nbsp;4210 Section 5.3.19.6</xref>.</t> format="default" sectionFormat="of" section="5.3.19.6"/>.</t>
          <t keepWithNext="true">The message sequence for this PKI management operation is as given above, with the following specific content:</t>
          <ol spacing="normal" type="%d"> type="1">
		    <li>the infoType OID to use is id-it-crlStatusList in the request and id-it-crls in the response</li>
		    <li>the infoValue of the request MUST <bcp14>MUST</bcp14> be present and contain a sequence of one CRLStatus structure</li>
		    <li>if present, the infoValue of the response MUST <bcp14>MUST</bcp14> contain a sequence of one CRL</li>
          </ol>
          <t keepWithNext="true">Detailed Description of the infoValue Field of genm:</t>
          <artwork align="left" name="" type="" alt=""><![CDATA[
          <sourcecode type="pseudocode"><![CDATA[
      infoValue               REQUIRED
    -- MUST contain a sequence of one CRLStatus element
        source                REQUIRED
    -- MUST contain the dpn choice of type DistributionPointName if
    --   the CRL distribution point name is available
    -- Otherwise, MUST contain the issuer choice identifying the CA
    --   that issues the CRL.  It MUST contain the issuer DN in the
    --   directoryName field of a GeneralName element.
        thisUpdate            OPTIONAL
    -- MUST contain the thisUpdate field of the latest CRL the EE
    --   has got gotten from the issuer specified in the given dpn or
    --   issuer field
    -- MUST be omitted if the EE does not have any instance of the
    --   requested CRL
                ]]></artwork>
                ]]></sourcecode>
          <t keepWithNext="true">Detailed Description of the infoValue Field of genp:</t>
          <artwork align="left" name="" type="" alt=""><![CDATA[
          <sourcecode type="pseudocode"><![CDATA[
      infoValue               OPTIONAL
    -- MUST be absent if no CRL to be returned is available
    -- MUST contain a sequence of one CRL update from the referenced
    --   source,   source if a thisUpdate value was not given or a more recent
    --   CRL is available
                ]]></artwork>
                ]]></sourcecode>
        </section>
      </section>
      <section anchor="EE_Polling" numbered="true" toc="default">
         <name>Handling Delayed Delivery</name>
       <t>This is a variant of all PKI management operations described in this document.  It is initiated in case a PKI management entity cannot respond to a request message in a timely manner, typically due to offline or asynchronous upstream communication, communication or due to delays in handling the request. The polling mechanism has been specified in <xref target="RFC4210" format="default">RFC&nbsp;4210 Section 5.3.22</xref> format="default" sectionFormat="of" section="5.3.22"/> and updated by <xref target="I-D.ietf-lamps-cmp-updates" target="RFC9480" format="default"/>.</t>
       <t>Depending on the PKI architecture, the entity initiating delayed delivery 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 PKI management entity MUST <bcp14>MUST</bcp14> respond with a message including the status "waiting". In response to an ir/cr/kur/p10cr message message, it must place the status "waiting" in an ip/cp/kup message, otherwise message and for responses to other request message types in an error message.  On receiving this response, the EE MUST <bcp14>MUST</bcp14> store in its transaction context the senderNonce of the preceding request message because this value will be needed for checking the recipNonce of the final response to be received after polling. It sends a poll request with certReqId 0 if referring to the CertResponse element contained in the ip/cp/kup message, else -1 to refer to the whole message.  In case the final response is not yet available, the PKI management entity that initiated the delayed delivery MUST <bcp14>MUST</bcp14> answer with a poll response, response with the same certReqId.  The included checkAfter time value indicates the minimum number of seconds that should elapse before the EE sends a new pollReq message to the PKI management entity.  Polling earlier than indicated by the checkAfter value may increase the number of messages roundtrips. message round trips.  This is repeated until a final response is available or any party involved gives up on the current PKI management operation, i.e., a timeout occurs.</t>
	   <t>When the PKI management entity that initiated delayed delivery can provide the final response for the original request message of the EE, it MUST <bcp14>MUST</bcp14> send this response to the EE.  Using this response, the EE can continue 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 keepWithNext="true">Message Flow:</t>
       <artwork align="left" name="" type="" alt=""><![CDATA[
Step# EE                                  PKI management entity
 1   format request
       message
 2                  ->     request     ->
 3                                        handle or forward
                                            request
 4                                        format ip/cp/kup/error
                                            with status "waiting"
                                            response in case no
                                            immediate final response
                                            is available, available
 5                   <- ip/cp/kup/error <-
 6   handle
       ip/cp/kup/error
       with status
       "waiting"

--------------------------  start polling  --------------------------

 7   format pollReq
 8                     ->    pollReq   ->
 9                                        handle or forward pollReq
10                                        in case the final response
                                            for the original request
                                            is available, continue
                                            with step 14
                                          otherwise, format or
                                            receive pollRep with
                                            checkAfter value
11                     <-    pollRep   <-
12   handle pollRep
13   let checkAfter
       time elapse and
       continue with
       step 7

-----------------  end polling, continue as usual  ------------------

14                                        format or receive
                                            final response on
                                            the original request
15                     <-   response   <-
16   handle final
       response
                    ]]></artwork>
       <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

Field                         Value

header
    -- As described in Section 3.1

body
    -- As described for the respective PKI management operation, with
    --   the following adaptations:
      status                  REQUIRED -- in case of ip/cp/kup
      pKIStatusInfo           REQUIRED -- in case of error response
    -- PKIStatusInfo structure MUST be present
        status                REQUIRED
    -- MUST be status "waiting"
        statusString          OPTIONAL
    -- MAY be any human-readable text for debugging, logging for logging, or to
    --   to display in a GUI
        failInfo              PROHIBITED

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    OPTIONAL
    -- As described in Section 3.3

Polling Request -- pollReq

Field                         Value

header
    -- As described in Section 3.1

body
    -- The message of the EE asking for the final response or for a
    --   time to check again
  pollReq                     REQUIRED
    certReqId                 REQUIRED
    -- MUST be 0 if referring to a CertResponse element, else -1

protection                    REQUIRED
    -- As described in Section 3.2
    -- MUST use the same credentials as in the first request message
    --   of the PKI management operation

extraCerts                    RECOMMENDED
    -- As described in Section 3.3
    -- MAY be omitted if the message size is critical and the PKI
    --   management entity caches the CMP protection certificate from
    --   the first request message of the PKI management operation

Polling Response -- pollRep

Field                         Value

header
    -- As described in Section 3.1

body
    -- The message indicates the delay after which the EE SHOULD
    --   send another pollReq message for this transaction
  pollRep                     REQUIRED
    certReqId                 REQUIRED
    -- MUST be 0 if referring to a CertResponse element, else -1
    checkAfter                REQUIRED
    -- MUST be the time in seconds to elapse before a new pollReq
    --   should be sent
    reason                    OPTIONAL
    -- MAY be any human-readable text for debugging, logging for logging, or to
    --   to display in a GUI

protection                    REQUIRED
    -- As described in Section 3.2
    -- MUST use the same credentials as in the first response
    --   message of the PKI management operation

extraCerts                    RECOMMENDED
    -- As described in Section 3.3
    -- MAY be omitted if the message size is critical and the EE has
    --   cached the CMP protection certificate from the first
    --   response message of the PKI management operation

Final Response - Any Type of Response Message

Field                         Value

header
    -- MUST be the header header, as described for the response message
    --   of the respective PKI management operation

body
    -- The response of the PKI management entity to the initial
    --   request   request, as described in the respective PKI management
    --   operation

protection                    REQUIRED
    -- MUST be as described for the response message of the
    --   respective PKI management operation

extraCerts                    REQUIRED
    -- MUST be as described for the response message of the
    --   respective PKI management operation
                    ]]></artwork>
                    ]]></sourcecode>
      </section>
    </section>
    <section anchor="RA_UseCases" numbered="true" toc="default">
      <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>A PKI management entity may directly respond to request messages from downstream and report errors. In case the PKI management entity is an RA RA, it typically forwards the received request messages upstream after checking them and forwards respective response messages downstream.  Besides responding to messages or 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 certificates and thus act as an EE using the PKI management operations specified in <xref target="EE_UseCases" format="default"/>.</t>
      <section anchor="RA_response" numbered="true" toc="default">
        <name>Responding to Requests</name>
        <t>The PKI management entity terminating the PKI management operation at CMP level MUST <bcp14>MUST</bcp14> respond to all received requests by returning a related CMP response message or an error. Any intermediate PKI management entity MAY respond <bcp14>MAY</bcp14> respond, depending on the PKI configuration and policy.</t>
        <t>In addition to the checks described in <xref target="Validation" format="default"/>, the responding PKI management entity MUST <bcp14>MUST</bcp14> check that a request that initiates a new PKI management operation does not use a transactionID that is currently in use.  The failInfo bit value to use is transactionIdInUse as described in <xref target="Error_reporting" format="default"/>.  If any of these verification steps or any of the essential checks described in <xref target="Validation" format="default"/> and in the following subsections fails, the PKI management entity MUST <bcp14>MUST</bcp14> proceed as described in <xref target="Error" format="default"/>.</t>
        <t>The responding PKI management entity MUST <bcp14>MUST</bcp14> copy the sender field of the request to the recipient field of the response, MUST <bcp14>MUST</bcp14> copy the senderNonce of the request to the recipNonce of the response, and MUST <bcp14>MUST</bcp14> use the same transactionID for the response.</t>
		<section anchor="RA_response_enrollment" numbered="true" toc="default">
			<name>Responding to a Certificate Request</name>
			<t>An ir/cr/kur/p10cr message is used to request a certificate as described in <xref target="EE_request" format="default"/>. The responding PKI management entity MUST <bcp14>MUST</bcp14> proceed as follows unless it initiates delayed delivery as described in <xref target="RA_response_polling" format="default"/>.</t>
			<t>The PKI management entity MUST <bcp14>MUST</bcp14> check the message body according to the applicable requirements from <xref target="EE_request" format="default"/>. Possible failInfo bit values used for error reporting in case a check failed include badCertId and badCertTemplate. It MUST <bcp14>MUST</bcp14> verify the presence and value of the proof-of-possession (failInfo bit: badPOP), badPOP) unless central key generation is requested. If a signature-based proof-of-possession is present, the PKI management entity <bcp14>MUST</bcp14> verify, based on local PKI policy, that the subject name in the certTemplate identifies the same entity as the subject name in the CMP protection certificate or matches the identifier used with MAC-based protection.  In case this verification fails, the message <bcp14>MUST</bcp14> have been protected by an authorized PKI management entity (failInfo bit: notAuthorized).  If the special POP value "raVerified" is given, it the PKI management entity should check that the request message was signed using a certificate containing the cmcRA extended key usage (failInfo bit: notAuthorized). The PKI management entity should also perform any further checks on the certTemplate contents (failInfo: badCertTemplate) according to any applicable PKI policy and certificate profile.</t>
			<t>If the requested certificate is available, the PKI management entity MUST <bcp14>MUST</bcp14> respond with a positive ip/cp/kup message as described in <xref target="EE_request" format="default"/>.</t>
			<t>Note: If central key generation is performed by the responding PKI management entity, the responding PKI management entity MUST <bcp14>MUST</bcp14> include the private key in encrypted form in the response as specified in <xref target="EE_centralKeyGeneration" format="default"/>.</t>
            <t keepWithNext="true">The prerequisites of the respective PKI management operation as specified in <xref target="EE_request" format="default"/> apply.</t>
			<t>If the EE requested omission of the certConf message, the PKI management entity MUST <bcp14>MUST</bcp14> handle it as described in <xref target="EE_newPKI" format="default"/>.  Therefore, it MAY <bcp14>MAY</bcp14> grant this by including the implicitConfirm generalInfo field or include including the confirmWaitTime field in the response header.</t>
		</section>
		<section anchor="RA_response_confirmation" numbered="true" toc="default">
			<name>Responding to a Confirmation Message</name>
			<t>A PKI management entity MUST <bcp14>MUST</bcp14> handle a certConf message if it has responded before with a positive ip/cp/kup message not granting implicit confirmation.  It should check the message body according to the requirements given in <xref target="EE_newPKI" format="default"/> (failInfo bit: badCertId) and MUST <bcp14>MUST</bcp14> react as described there.</t>
			<t>The prerequisites of the respective PKI management operation as specified in <xref target="EE_request" format="default"/> apply.</t>
		</section>
		<section anchor="RA_response_revocation" numbered="true" toc="default">
			<name>Responding to a Revocation Request</name>
			<t>An rr message is used to request revocation of a certificate. The responding PKI management entity should check the message body according to the requirements in <xref target="EE_Revoke" format="default"/>. It MUST <bcp14>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 revoked (failInfo bit: certRevoked).  On success success, it MUST <bcp14>MUST</bcp14> respond with a positive rp message message, as described in <xref target="EE_Revoke" format="default"/>.</t>
			<t>No specific prerequisites apply in addition to those specified in <xref target="Prereq" format="default"/>.</t>
		</section>
		<section anchor="RA_response_support" numbered="true" toc="default">
			<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"/> and perform any further checks depending on the PKI policy.  On success success, it MUST <bcp14>MUST</bcp14> respond with a genp message as described there.</t>
			<t>Note: The responding PKI management entity may generate the response from scratch or reuse the contents of previous responses.  Therefore, it may be worth caching the body of the response message as long as the contained 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 specified in <xref target="Prereq" format="default"/>.</t>
		</section>
        <section anchor="RA_response_polling" numbered="true" toc="default">
          <name>Initiating Delayed Delivery</name>
          <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 case, the PKI 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.  In the meantime, it MUST <bcp14>MUST</bcp14> respond with an ip/cp/kup/error message including the status "waiting" and handle subsequent polling as described in <xref target="EE_Polling" format="default"/>.</t>
          <t>Typically, as stated in <xref target="RA_Replace" format="default"/>, an intermediate PKI management entity should not change the sender and recipient nonces even in case it modifies a request or a response message.  In the special case of delayed delivery initiated by an intermediate PKI management entity, 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 final response from upstream has arrived at the PKI management entity, this response contains the recipNonce copied (as usual) from the senderNonce in the original request message.  The PKI management entity that initiated the delayed delivery MAY <bcp14>MAY</bcp14> replace the recipNonce in the response message with the senderNonce of the last received pollReq because the downstream entities, including the EE, might expect it in this way.  Yet the check specified in Section 3.5 <xref target="Validation"/> allows to alternatively 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>
        </section>
      </section>
      <section anchor="RA_forwarde_messages" numbered="true" toc="default">
        <name>Forwarding Messages</name>
        <t>In case the PKI solution consists of intermediate PKI management entities (i.e., LRA or RA), each CMP request message coming from an EE or any other downstream PKI management entity MUST <bcp14>MUST</bcp14> either be forwarded to the next (upstream) PKI management entity as described in this section section, or answered as described in <xref target="RA_response" format="default"/>. Any received response message or a locally generated error message MUST <bcp14>MUST</bcp14> be forwarded to the next (downstream) PKI entity.</t>
        <t>In addition to the checks described in <xref target="Validation" format="default"/>, the forwarding PKI management entity MAY <bcp14>MAY</bcp14> verify the proof-of-possession for ir/cr/kur/p10cr messages.  If one of these verification procedures fails, the RA proceeds as described in <xref target="Error" format="default"/>.</t>
        <t>A PKI management entity SHOULD NOT <bcp14>SHOULD NOT</bcp14> change the received message unless its role in the PKI system requires it.  This is because changes to the message header or body imply re-protection. reprotection. Changes to the protection breaks end-to-end authentication of the message source. Changes to the certificate template in a certificate request breaks proof-of-possession.  More details are available in the following sub-sections. subsections.  Concrete PKI system specifications may define in more detail when to do so.</t> so in more detail.</t>
        <t>This is particularly relevant in the upstream communication of a request message.</t>
        <t keepWithNext="true">Each forwarding PKI management entity has one or more functionalities. It may</t> may:</t>
        <ul spacing="normal">
          <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>replace a MAC-based protection by with a signature-based protection that can also be verified also further upstream, upstream and vice versa,</li>
          <li>double-check if the messages transferred back and forth are properly protected and well-formed,</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>collect messages from multiple RAs and forward them jointly.</li>
        </ul>
		<t>Note: PKI management entities forwarding messages may also store 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> forwarded is:</t>
        <ul spacing="normal">
          <li>unchanged with the original protection,</li>
          <li>unchanged with an additional protection, or</li>
          <li>changed with an additional protection</li>
        </ul>
        <t>depends
        <t>depending on the PKI solution design and the associated security policy (<xref policy, e.g., as defined in the <xref target="RFC3647" format="default">CP/CPS</xref>).</t> format="default">certificate policy (CP) / certification practice statement (CPS) documents</xref>.</t>
        <t keepWithNext="true">A PKI management entity SHOULD <bcp14>SHOULD</bcp14> add or MAY <bcp14>MAY</bcp14> replace a protection of a message if it</t>
        <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 entities or</li>
          <li>needs to protect the message using a key and certificate from a different PKI.</li>
        </ul>
		<t>If remaining retaining end-to-end message authentication is required, an additional protection SHALL <bcp14>SHALL</bcp14> be added instead of replacing the original protection.</t>
        <t keepWithNext="true">A PKI management entity MUST <bcp14>MUST</bcp14> replace a protection of a message if it</t>
        <ul spacing="normal">
          <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>
        </ul>
        <t>This is particularly relevant in the upstream communication of certificate 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 <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 particularly helpful to augment upstream messages with additional certificates or to reduce the number of certificates in downstream messages when forwarding to constrained devices.</t>
        <section anchor="RA_noChange" numbered="true" toc="default">
          <name>Not Changing Protection</name>
          <t>This variant means that a PKI management entity forwards a CMP message without changing the header, body, or protection.  In this case case, the PKI management entity acts more like a proxy, e.g., on a network boundary, implementing no specific RA-like security functionality that requires an authentic indication to the PKI. Still Still, the PKI management entity might implement checks that result in refusing to forward the request message and instead responding as specified in <xref target="Error" format="default"/>.</t>
          <t>This variant of forwarding a message or the one described in <xref target="RA_AddSingel" format="default"/> MUST <bcp14>MUST</bcp14> be used for kur messages and for central key generation. </t>
		  <t>No specific prerequisites apply in addition to those specified in <xref target="Prereq" format="default"/>.</t>
        </section>
        <section anchor="RA_Add" numbered="true" toc="default">
          <name>Adding Protection and Batching of Messages</name>
          <t>This variant of forwarding a message means that a PKI management entity adds another protection to PKI management messages before forwarding them.</t>
          <t>The nested message is a PKI management message containing a PKIMessages sequence as its body body, containing one or more CMP messages.</t>
          <t>As specified in the updated <xref target="RFC4210" format="default">Section 5.1.3.4 of RFC&nbsp;4210</xref> (see also format="default" sectionFormat="of" section="5.1.3.4"/> (also see <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 2.6</xref>) target="RFC9480" format="default" sectionFormat="of" section="2.6">CMP Updates</xref>), there are various use cases for adding another protection by a PKI management entity. Specific procedures are described in more detail in the following sections.</t>
          <t keepWithNext="true">Detailed Message Description:</t>
          <artwork align="left" name="" type="" alt=""><![CDATA[
          <sourcecode type="pseudocode"><![CDATA[
Nested Message - nested

Field                         Value

header
    -- As described in Section 3.1

body
    -- Container to provide additional protection to original
    --   messages and to bundle request messages or alternatively
    --   response messages
  PKIMessages                 REQUIRED
    -- MUST be a sequence of one or more CMP messages

protection                    REQUIRED
    -- As described in Section 3.2 3.2, using the CMP protection key of
    --   the PKI management entity

extraCerts                    REQUIRED
    -- As described in Section 3.3
                    ]]></artwork>
                    ]]></sourcecode>
          <section anchor="RA_AddSingel" numbered="true" toc="default">
            <name>Adding Protection to a Request Message</name>
            <t>This variant means that a PKI management entity forwards a CMP message while authentically indicating successful validation and approval of a request message without changing the original message authentication.</t>
			<t>By adding a protection using its own CMP protection key key, the PKI management entity provides a proof of verifying and approving the message message, as described above. Thus, the PKI management entity acts as an actual Registration Authority registration authority (RA), which implements important security functionality of the PKI. Applying an additional protection is specifically relevant when forwarding a message that requests a certificate update or central key generation.  This is because the original protection of the EE needs to be preserved while adding an indication of approval by the PKI management entity.</t>
            <t>The PKI management entity wrapping the original request message in a nested message structure MUST <bcp14>MUST</bcp14> copy the values of the recipient, recipNonce, senderNonce and transactionID header fields of the original message to the respective header fields of the nested message and apply signature-based protection.  The additional signature serves as proof of verification and authorization by this PKI management entity.</t>
            <t>The PKI management entity receiving such a nested message that contains a single request message MUST <bcp14>MUST</bcp14> validate the additional protection signature on the nested message and check the authorization for the approval it implies.</t> implies.  Other fields in the header of the nested message can be ignored.</t>
			<t>The PKI management entity responding to the request contained in the nested message sends the response message as described in <xref target="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 this 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 one used in the included message.</t>
            <t keepWithNext="true">Specific prerequisites keepWithNext="true">The specific prerequisite augmenting the prerequisites in <xref target="Prereq" format="default"/>:</t> format="default"/> is as follows:</t>
            <ul spacing="normal">
              <li>The PKI management entity MUST <bcp14>MUST</bcp14> be able to validate the respective request and have the authorization to perform approval of the request according to the PKI policies.</li>
            </ul>
            <t keepWithNext="true">Message Flow:</t>
            <artwork align="left" name="" type="" alt=""><![CDATA[
Step# PKI management entity               PKI management entity
 1   format nested
 2                      ->  nested   ->
 3                                        handle or forward nested
 4                                        format or receive response
 5                      <-  response <-
 6   forward response
                    ]]></artwork>
          </section>
          <section anchor="RA_AddBatch" numbered="true" toc="default">
            <name>Batching Messages</name>
            <t>A PKI management entity MAY <bcp14>MAY</bcp14> bundle any number of PKI management messages for batch processing or to transfer a bulk of PKI management messages using the nested message structure.  In this use case, nested messages are used both on the upstream interface for transferring request messages towards the next PKI management entity and on its downstream interface for response messages.</t>
            <t>This PKI management operation is typically used on the interface between an LRA and an RA to bundle several messages for offline or asynchronous delivery.  In this case case, the LRA needs to initiate delayed delivery delivery, as described in <xref target="RA_response_polling" format="default"/>. If the RA needs different routing information per the nested PKI management message provided upstream, a suitable mechanism may need to be implemented to ensure that the downstream delivery of the response is done to the right requester.  Since this mechanism strongly depends on the requirements of the target architecture, it is out of scope of this document.</t>
            <t>A nested message containing requests is generated locally at the PKI management entity.  For the upstream nested message, the PKI management entity acts as a protocol end point and therefore endpoint; therefore, a fresh transactionID and a fresh senderNonce MUST <bcp14>MUST</bcp14> be used in the header of the nested message. An upstream nested message may contain request messages, e.g., ir, cr, p10cr, kur, pollReq, certConf, rr, or genm.  While building the upstream nested message message, the PKI management entity must store the sender, transactionID, and senderNonce fields of all bundled messages together with the transactionID of the upstream nested message.</t>
            <t>Such an upstream nested message is sent to the next PKI management entity. The upstream PKI management entity that unbundles it MUST <bcp14>MUST</bcp14> handle each of the included request messages as usual.  It MUST <bcp14>MUST</bcp14> answer with a downstream nested message.  This downstream nested message MUST <bcp14>MUST</bcp14> use the transactionID of the upstream nested message and return the senderNonce of the upstream nested message as the recipNonce of the downstream nested message.  The downstream nested message MUST <bcp14>MUST</bcp14> bundle all available individual response messages (e.g., ip, cp, kup, pollRep, pkiConf, rp, genp, or error) for all original request messages of the upstream nested message.  While unbundling the downstream nested message, the former PKI management entity must determine lost and unexpected responses based on the previously stored transactionIDs.  When it forwards the unbundled responses, any extra messages MUST <bcp14>MUST</bcp14> be dropped, and any missing response message MUST <bcp14>MUST</bcp14> be answered with an error message (failInfo bit: systemUnavail) to inform the respective requester about the failed certificate management operation.</t>
			<t>Note: This form of nesting messages is characterized by the fact that the transactionID in the header of the nested message is different to those used in the included messages.</t>
            <t>The protection of the nested messages MUST NOT <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 specified in <xref target="Prereq" format="default"/>.</t>
            <t keepWithNext="true">Message Flow:</t>
            <artwork align="left" name="" type="" alt=""><![CDATA[
Step# PKI management entity               PKI management entity
 1   format nested
 2                      ->  nested   ->
 3                                        handle or forward nested
 4                                        format or receive nested
 5                      <-  nested   <-
 6   handle nested
                    ]]></artwork>
          </section>
        </section>
        <section anchor="RA_Replace" numbered="true" toc="default">
          <name>Replacing Protection</name>
          <t>The following two alternatives can be used by any PKI management entity forwarding a CMP message with or without changes while providing its own protection and and, in this way way, asserting approval of the message.</t>
		  <t>If retaining end-to-end message authentication is required, an additional protection SHALL <bcp14>SHALL</bcp14> be added instead of replacing the original protection.</t>
		  <t>By replacing the existing protection using its own CMP protection key 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 actual Registration Authority registration authority (RA), which implements important security functionality of the PKI.</t> PKI such as verifying the proof of requester identity and authorization.</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 original message protection gets lost.  To enable the CA to verify this binding, the original message can be provided in the origPKIMessage generalInfo field.</t>
          <t keepWithNext="true">Before replacing the existing protection by with a new protection, the PKI management entity</t> entity:</t>
          <ul spacing="normal">
            <li>MUST
            <li><bcp14>MUST</bcp14> validate the protection of the received message,</li>
            <li>should check the content of the message,</li>
            <li>may do any modifications that it wants to perform, and</li>
            <li>MUST
            <li><bcp14>MUST</bcp14> check that the sender of the original message, as authenticated by the message protection, is authorized for the given operation.</li>
			<li>for certificate requests, <bcp14>MUST</bcp14> verify the binding of signature-based proof-of-possession to the proof-of-identity as described in <xref target="RA_response_enrollment" format="default"/>.</li>
            </ul>
          <t>These message adaptations MUST NOT <bcp14>MUST NOT</bcp14> be applied to kur messages described in <xref target="EE_Update" format="default"/> since their original protection using the key and certificate to be updated needs to be preserved.</t>
          <t>These message adaptations MUST NOT <bcp14>MUST NOT</bcp14> be applied to certificate request messages described in <xref target="EE_centralKeyGeneration" format="default"/> for central key generation since their original protection needs to be preserved up to the Key Generation Authority, KGA, which needs to use it for encrypting the new private key for the EE.</t>
          <t>In both the kur and central key generation cases, if a PKI management entity needs to state its approval of the original request message message, it MUST <bcp14>MUST</bcp14> provide this using a nested message as specified in <xref target="RA_AddSingel" format="default"/>.</t>
          <t>When an intermediate PKI management entity modifies a message, it MUST NOT <bcp14>MUST NOT</bcp14> change the transactionID, the senderNonce, or the recipNonce - recipNonce, apart from the exception for the recipNonce given in <xref target="RA_response_polling" format="default"/>.</t>
          <section anchor="RA_keepPOPO" numbered="true" toc="default">
            <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 body while preserving any included proof-of-possession.</t>
			<t>This variant is typically used when an RA replaces an existing MAC-based protection by with its own signature-based protection, protection; because the upstream PKI management entity does not know the respective shared secret information, replacing the protection is useful.</t>
			<t>Note: A signature-based proof-of-possession of a certificate request will be broken if any field in the certTemplate structure is changed.</t>
            <t>In case the PKI management entity breaks an existing proof-of-possession, the message adaptation described in <xref target="RA_breakPOPO" format="default"/> needs to be applied instead.</t>
            <t keepWithNext="true">Specific prerequisites keepWithNext="true">The specific prerequisite augmenting the prerequisites in <xref target="Prereq" format="default"/>:</t> format="default"/> is as follows:</t>
            <ul spacing="normal">
              <li>The PKI management entity MUST <bcp14>MUST</bcp14> be able to validate the respective request and have the authorization to perform approval of the request according to the PKI policies.</li>
            </ul>
          </section>
          <section anchor="RA_breakPOPO" numbered="true" toc="default">
            <name>Using raVerified</name>
            <t>This variant of forwarding a message needs to be used if a PKI management entity breaks any included proof-of-possession in a certificate request message, for instance instance, because it forwards an ir or cr message with modifications of the certTemplate, i.e., modification, addition, or removal of fields.</t>
            <t>The PKI management entity MUST <bcp14>MUST</bcp14> verify the proof-of-possession contained in the original message using the included public key.  If successful, the PKI management entity MUST <bcp14>MUST</bcp14> change the popo field value to raVerified.</t>
            <t keepWithNext="true">Specific prerequisites augmenting the prerequisites in <xref target="Prereq" format="default"/>:</t> format="default"/> are as follows:</t>
            <ul spacing="normal">
              <li>The PKI management entity MUST <bcp14>MUST</bcp14> be authorized to replace the proof-of-possession (after verifying it) with raVerified.</li>
              <li>The PKI management entity MUST <bcp14>MUST</bcp14> be able to validate the respective request and have the authorization to perform approval of the request according to the PKI policies.</li>
            </ul>
            <t keepWithNext="true">Detailed Description of the popo Field of the certReq Structure:</t>
            <artwork align="left" name="" type="" alt=""><![CDATA[
            <sourcecode type="pseudocode"><![CDATA[
    popo
      raVerified              REQUIRED
    -- MUST have the value NULL and indicates that the PKI
    --   management entity verified the popo of the original message
                        ]]></artwork>
                        ]]></sourcecode>
          </section>
        </section>
      </section>
      <section anchor="RA_on-behalf" numbered="true" toc="default">
        <name>Acting on Behalf of other Other PKI Entities</name>
        <t>A PKI management entity may need to request a PKI management operation on behalf of another PKI entity.  In this case case, the PKI management entity initiates the respective PKI management operation as described in <xref target="EE_UseCases" format="default"/> format="default"/>, acting in the role of the EE.</t>
		<t>Note: The request message protection will not authenticate the EE, but it will authenticate the RA acting on behalf of the EE.</t>
		<section anchor="RA_on-behalf_request" numbered="true" toc="default">
			<name>Requesting a Certificate</name>
			<t>A PKI management entity may use one of the PKI management operations described in <xref target="EE_request" format="default"/> to request a certificate on behalf of another PKI entity.  It either generates the key pair itself and inserts the new public key in the subjectPublicKey field of the request certTemplate, or it uses a certificate request received from downstream, e.g., by means of a different protocol.
			In the latter case case, it MUST <bcp14>MUST</bcp14> verify the received proof-of-possession if this proof breaks, e.g., due to transformation from <xref target="RFC2986" format="default">PKCS#10</xref> format="default">PKCS #10</xref> to <xref target="RFC4211" format="default">CRMF</xref> certificate request format.</t> format="default">CRMF</xref>.
			It <bcp14>MUST</bcp14> also verify, based on local PKI policy, that the subject name in the certTemplate identifies the EE.</t>
			<t>No specific prerequisites apply in addition to those specified in <xref target="EE_request" format="default"/>.</t>
			<t>Note: An upstream PKI management entity will not be able to differentiate this PKI management operation from the one described in <xref target="RA_Replace" format="default"/> because because, in both cases 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 given in <xref target="EE_request" format="default"/>, with the following changes:</t>
			<ol spacing="normal" type="%d"> type="1">
				<li>The request messages MUST <bcp14>MUST</bcp14> be signed using the CMP protection key of the PKI management entity taking the role of the EE in this operation.</li>
				<li>If inclusion of a proper proof-of-possession is not possible possible, the PKI management entity MUST <bcp14>MUST</bcp14> verify the POP provided 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>
		</section>
		<section anchor="RA_on-behalf_revoke" numbered="true" toc="default">
			<name>Revoking a Certificate</name>
			<t>A PKI management entity may use the PKI management operation described in <xref target="EE_Revoke" format="default"/> to revoke a certificate of another PKI entity.  This revocation request message MUST <bcp14>MUST</bcp14> be signed by 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>No specific prerequisites apply in addition to those specified in <xref target="EE_Revoke" format="default"/>.</t>
			<t>Note: An upstream PKI management entity will not be able to differentiate this PKI management operation from the ones described in <xref 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" format="default"/>, with the following changes:</t>
			<ol spacing="normal" type="%d"> type="1">
				<li>The rr message MUST <bcp14>MUST</bcp14> be signed using the CMP protection key of the PKI management entity acting on behalf of the EE in this operation.</li>
			</ol>
		</section>
      </section>
    </section>
    <section anchor="Transfer_types" numbered="true" toc="default">
      <name>CMP Message Transfer Mechanisms</name>
      <t>CMP messages are designed to be self-contained, such that that, in principle principle, any reliable transfer mechanism can be used.  EEs will typically support only one transfer mechanism.  PKI management entities SHOULD <bcp14>SHOULD</bcp14> offer HTTP and MAY <bcp14>MAY</bcp14> offer CoAP where required. Piggybacking of CMP messages on any other reliable transfer protocol MAY <bcp14>MAY</bcp14> be used, and file-based transfer MAY <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 indefinitely, each PKI entity that sends CMP requests should use a configurable per-request timeout, and each PKI management entity that handles CMP requests should use a configurable timeout in case a further request message is to be expected from the client side within the same transaction.  In this way way, a hanging transaction can be closed cleanly with an error as described in <xref target="Error" format="default"/> (failInfo bit: systemUnavail) systemUnavail), and related resources (for instance, any cached extraCerts) can be freed.</t>
	  <t>Moreover, there are various situations where the delivery of messages gets delayed.  For instance, a serving PKI management entity might take longer than expected to form a response due to administrative processes, resource constraints, or upstream message delivery delays.  The transport layer itself may cause delays, for instance instance, due to offline transport, network segmentation, or intermittent network connectivity.  Part of these issues can be detected and handled at CMP level using pollReq and pollRep messages as described in <xref target="EE_Polling" format="default"/>, while others are better handled at transfer level.  Depending on the transfer protocol and system architecture, solutions for handling delays at transfer level may be present and can be used for CMP connections, for instance instance, connection re-establishment 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: When using TCP and similar reliable connection-oriented transport protocols, which is typical in conjunction with HTTP, there is the option to keep the connection alive over multiple request-response message pairs.  This may improve efficiency.</t>
      <t>When conveying CMP messages in HTTP, CoAP, or MIME-based transfer protocols, the internet Internet media type "application/pkixcmp" MUST <bcp14>MUST</bcp14> be set for transfer encoding as specified in <xref target="RFC6712" format="default">Section 3.4 of CMP format="default" sectionFormat="of" section="3.4">CMP over HTTP</xref> and <xref target="I-D.ietf-ace-cmpv2-coap-transport" format="default">Section 2.4 of CMP target="RFC9482" format="default" sectionFormat="of" section="2.3">CMP over CoAP</xref>.</t>
      <section anchor="HTTP" numbered="true" toc="default">
        <name>HTTP Transfer</name>
        <t>This transfer mechanism can be used by a PKI entity to transfer CMP messages over HTTP. If HTTP transfer is used used, the specifications as described in <xref target="RFC6712" format="default"/> and updated by <xref target="I-D.ietf-lamps-cmp-updates" target="RFC9480" format="default">CMP Updates</xref> MUST <bcp14>MUST</bcp14> be followed.</t>
        <t>PKI management operations MUST <bcp14>MUST</bcp14> use an a URI path consisting of '/.well-known/cmp/' '/.well-known/cmp' or '/.well-known/cmp/p/&lt;name&gt;/' '/.well-known/cmp/p/&lt;name&gt;' as specified in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 3.3</xref>. target="RFC9480" format="default" sectionFormat="of" section="3.3">CMP Updates</xref>. It SHOULD <bcp14>SHOULD</bcp14> be followed by an operation label depending on the type of PKI management operation.</t>
        <table anchor="http_endpoints" align="left">
          <name>HTTP URI Path Segment &lt;operation&gt;</name>
          <thead>
            <tr>
              <th align="left">PKI Management Operation</th>
              <th align="center">URI Path Segment</th>
              <th align="left">Details</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left"><xref target="EE_newPKI" format="title"/></td> align="left">Enrolling an End Entity to a New PKI</td>
              <td align="center">initialization</td>
              <td align="left"><xref target="EE_newPKI" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_trustedPKI" format="title"/></td> align="left">Enrolling an End Entity to a Known PKI</td>
              <td align="center">certification</td>
              <td align="left"><xref target="EE_trustedPKI" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_Update" format="title"/></td> align="left">Updating a Valid Certificate</td>
              <td align="center">keyupdate</td>
              <td align="left"><xref target="EE_Update" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_P10" format="title"/></td> align="left">Enrolling an End Entity Using a PKCS #10 Request</td>
              <td align="center">pkcs10</td>
              <td align="left"><xref target="EE_P10" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_Revoke" format="title"/></td> align="left">Revoking a Certificate</td>
              <td align="center">revocation</td>
              <td align="left"><xref target="EE_Revoke" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_CACerts" format="title"/></td> align="left">Get CA Certificates</td>
              <td align="center">getcacerts</td>
              <td align="left"><xref target="EE_CACerts" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_RootCAUpdate" format="title"/></td> align="left">Get Root CA Certificate Update</td>
              <td align="center">getrootupdate</td>
              <td align="left"><xref target="EE_RootCAUpdate" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_Temp" format="title"/></td> align="left">Get Certificate Request Template</td>
              <td align="center">getcertreqtemplate</td>
              <td align="left"><xref target="EE_Temp" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_CRLs" format="title"/></td> align="left">CRL Update Retrieval</td>
              <td align="center">getcrls</td>
              <td align="left"><xref target="EE_CRLs" format="default"/></td>
            </tr>
            <tr>
              <td align="left">
			    <t><xref target="RA_AddBatch" format="title"/></t>
			    <t>Batching Messages</t>
				<t>Note: This path element is applicable only between PKI management entities.</t>
			  </td>
              <td align="center">nested</td>
              <td align="left"><xref target="RA_AddBatch" format="default"/></td>
            </tr>
          </tbody>
        </table>
		<t keepWithNext="true">If operation labels are used:</t>
        <ul spacing="normal">
			<li>Independently
	  <li>independently of any variants used (see Sections <xref target="EE_MAC" format="counter"/>, <xref target="EE_centralKeyGeneration" format="counter"/>, and <xref target="EE_Polling" format="counter"/>) format="counter"/>), the operation label corresponding to the PKI management operation SHALL <bcp14>SHALL</bcp14> be used.</li>
			<li>Any
			<li>any certConf or pollReq messages SHALL <bcp14>SHALL</bcp14> be sent to the same endpoint as determined by the PKI management operation.</li>
			<li>When
			<li>when a single request message is nested as described in <xref target="RA_AddSingel" format="default"/>, the label to use SHALL <bcp14>SHALL</bcp14> be the same as for the underlying PKI management operation.</li>
		</ul>
        <t>By sending a request to its preferred endpoint, the PKI entity will recognize recognize, via the HTTP response status code code, whether a configured URI is supported by the PKI management entity.</t>
		<t>In case a PKI management entity receives an unexpected HTTP status code from upstream, it MUST <bcp14>MUST</bcp14> respond downstream with an error message as described in <xref target="Error" format="default"/> format="default"/>, using a failInfo bit corresponding to the status code, e.g., systemFailure.</t>
		<t>For certificate management management, the major security goal is integrity and data origin authentication. For delivery of centrally generated keys, also confidentiality is also a must. These goals are sufficiently achieved by CMP itself, also in an end-to-end fashion.</t>
		<t>If a second line of defense is required or general privacy concerns 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 addition, the recommendations provided in <xref target="RFC9325" format="default"/> should be followed.</t>
        <t>Note: The requirements for checking certificates given in <xref target="RFC5280" format="default"/> and either <xref target="RFC5246" format="default"/> or <xref target="RFC8446" format="default"/> must be followed for the TLS layer. 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 are 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 authentication.  A pre-shared key (PSK) mechanism may be used with shared secret information 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>
      </section>
      <section anchor="CoAP" numbered="true" toc="default">
        <name>CoAP Transfer </name>
		<t>This transfer  mechanism can be used by a PKI entity to transfer CMP messages over <xref target="RFC7252" format="default">CoAP</xref>, e.g., in constrained environments.  If CoAP transfer is used used, the specifications as described in <xref target="I-D.ietf-ace-cmpv2-coap-transport" target="RFC9482" format="default">CMP over CoAP</xref> MUST <bcp14>MUST</bcp14> be followed.</t>
		<t>PKI management operations MUST <bcp14>MUST</bcp14> use an a URI path consisting of '/.well-known/cmp/' '/.well-known/cmp' or '/.well-known/cmp/p/&lt;name&gt;/' '/.well-known/cmp/p/&lt;name&gt;' as specified in <xref target="I-D.ietf-ace-cmpv2-coap-transport" format="default">CMP target="RFC9482" format="default" sectionFormat="of" section="2.1">CMP over CoAP Section 2.1</xref>. CoAP</xref>.  It SHOULD <bcp14>SHOULD</bcp14> be followed by an operation label depending on the type of PKI management operation.</t>
        <table anchor="coap_endpoints" align="left">
          <name>CoAP URI Path Segment &lt;operation&gt;</name>
          <thead>
            <tr>
              <th align="left">PKI Management Operation</th>
              <th align="center">URI Path Segment</th>
              <th align="left">Details</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left"><xref target="EE_newPKI" format="title"/></td> align="left">Enrolling an End Entity to a New PKI</td>
              <td align="center">ir</td>
              <td align="left"><xref target="EE_newPKI" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_trustedPKI" format="title"/></td> align="left">Enrolling an End Entity to a Known PKI</td>
              <td align="center">cr</td>
              <td align="left"><xref target="EE_trustedPKI" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_Update" format="title"/></td> align="left">Updating a Valid Certificate</td>
              <td align="center">kur</td>
              <td align="left"><xref target="EE_Update" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_P10" format="title"/></td> align="left">Enrolling an End Entity Using a PKCS #10 Request</td>
              <td align="center">p10</td>
              <td align="left"><xref target="EE_P10" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_Revoke" format="title"/></td> align="left">Revoking a Certificate</td>
              <td align="center">rr</td>
              <td align="left"><xref target="EE_Revoke" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_CACerts" format="title"/></td> align="left">Get CA Certificates</td>
              <td align="center">crts</td>
              <td align="left"><xref target="EE_CACerts" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_RootCAUpdate" format="title"/></td> align="left">Get Root CA Certificate Update</td>
              <td align="center">rcu</td>
              <td align="left"><xref target="EE_RootCAUpdate" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_Temp" format="title"/></td> align="left">Get Certificate Request Template</td>
              <td align="center">att</td>
              <td align="left"><xref target="EE_Temp" format="default"/></td>
            </tr>
            <tr>
              <td align="left"><xref target="EE_CRLs" format="title"/></td> align="left">CRL Update Retrieval</td>
              <td align="center">crls</td>
              <td align="left"><xref target="EE_CRLs" format="default"/></td>
            </tr>
            <tr>
              <td align="left">
			    <t><xref target="RA_AddBatch" format="title"/></t>
			    <t>Batching Messages</t>
				<t>Note: This path element is applicable only between PKI management entities.</t>
			  </td>
              <td align="center">nest</td>
              <td align="left"><xref target="RA_AddBatch" format="default"/></td>
            </tr>
          </tbody>
        </table>
		<t keepWithNext="true">If operation labels are used:</t>
        <ul spacing="normal">
			<li>Independently
			<li>independently of any variants used (see Sections <xref target="EE_MAC" format="counter"/>, <xref target="EE_centralKeyGeneration" format="counter"/>, and <xref target="EE_Polling" format="counter"/>) format="counter"/>), the operation label corresponding to the PKI management operation SHALL <bcp14>SHALL</bcp14> be used.</li>
			<li>Any
			<li>any certConf or pollReq messages SHALL <bcp14>SHALL</bcp14> be sent to the same endpoint endpoint, as determined by the PKI management operation.</li>
			<li>When
			<li>when a single request message is nested as described in <xref target="RA_AddSingel" format="default"/>, the label to use SHALL <bcp14>SHALL</bcp14> be the same as for the underlying PKI management operation.</li>
		</ul>
		<t>By sending a request to its preferred endpoint, the PKI entity will recognize recognize, via the CoAP response status code code, whether a configured URI is supported by the PKI management entity.  The CoAP-inherent discovery mechanisms MAY <bcp14>MAY</bcp14> also be used.</t>
		<t>In case a PKI management entity receives an unexpected CoAP status code from upstream, it MUST <bcp14>MUST</bcp14> respond downstream with an error message message, as described in <xref target="Error" format="default"/> format="default"/>, using a failInfo bit corresponding to the status code, e.g., systemFailure.</t>
		<t>Like for HTTP transfer, to offer a second line of defense or to provide hop-by-hop privacy protection, DTLS may be utilized as described in <xref target="I-D.ietf-ace-cmpv2-coap-transport" target="RFC9482" format="default">CMP over CoAP</xref>.  If DTLS is utilized, the same boundary conditions (peer authentication, etc.) as those stated for TLS to protect HTTP transfer in <xref target="HTTP" format="default"/> apply to DTLS likewise.</t>
		<t>Note: The provisioning of client certificates and PSKs is out of scope of this document.</t>
      </section>
      <section anchor="Piggybacking" numbered="true" toc="default">
        <name>Piggybacking on Other Reliable Transfer</name>
        <t>CMP messages MAY <bcp14>MAY</bcp14> also be transfer transferred on some other reliable protocol, e.g., EAP Extensible Authentication Protocol (EAP) or MQTT. Message Queuing Telemetry Transport (MQTT). Connection, delay, and error handling mechanisms similar to those specified for HTTP in <xref target="RFC6712" format="default">RFC&nbsp;6712</xref>need format="default"/> need to be implemented.</t>
        <t>A more detailed specification is out of scope of this document and would need to be given given, for instance instance, in the scope of the transfer protocol used.</t>
      </section>
      <section anchor="Offline" numbered="true" toc="default">
        <name>Offline Transfer</name>
        <t>For transferring CMP messages between PKI entities, any mechanism can be used that is able to store and forward binary objects of sufficient length and with sufficient reliability while preserving the order of messages for each transaction.</t> transaction can be used.</t>
        <t>The transfer mechanism should be able to indicate message loss, excessive delay, and possibly other transmission errors. In such cases cases, the PKI entities MUST <bcp14>MUST</bcp14> report an error as specified in <xref target="Error" format="default"/> format="default"/>, as far as possible.</t>
        <section anchor="File-based" numbered="true" toc="default">
          <name>File-Based Transfer</name>
          <t>CMP messages MAY <bcp14>MAY</bcp14> be transferred between PKI entities using file-based mechanisms, for instance instance, when an EE is offline or a PKI management entity performs delayed delivery.  Each file MUST <bcp14>MUST</bcp14> contain the ASN.1 DER encoding of one CMP message only, where the message may be nested.  There MUST <bcp14>MUST</bcp14> be no extraneous header or trailer information in the file.  The file name filename extension ".pki" MUST <bcp14>MUST</bcp14> be used.</t>
        </section>
        <section anchor="Other_trans" numbered="true" toc="default">
          <name>Other Asynchronous Transfer Protocols</name>
          <t>Other asynchronous transfer protocols, e.g., email or website up-/download, MAY upload/download, <bcp14>MAY</bcp14> transfer CMP messages between PKI entities. A MIME wrapping is defined for those environments that are MIME-native. The MIME wrapping is specified in <xref target="RFC8551" format="default">RFC&nbsp;8551 Section 3.1</xref>.</t> format="default" sectionFormat="of" section="3.1"/>.</t>
          <t>The ASN.1 DER encoding of the CMP messages MUST <bcp14>MUST</bcp14> be transferred using the "application/pkixcmp" content type and base64-encoded content transfer encoding encoding, as specified in <xref target="RFC6712" format="default">Section 3.4 of CMP format="default" sectionFormat="of" section="3.4">CMP over HTTP</xref>. A filename MUST <bcp14>MUST</bcp14> be included either in a "content-type" or a "content-disposition" statement. The file name filename extension ".pki" MUST <bcp14>MUST</bcp14> be used.</t>
        </section>
      </section>
    </section>
    <section anchor="Conformity" numbered="true" toc="default">
      <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>
      <section anchor="UseCases" numbered="true" toc="default">
        <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, or not applicable.  Variants amend or change behavior of base PKI management operations and are therefore also included.</t>
        <t>The PKI management operation specifications in <xref target="EE_UseCases" format="default"/> assume that either the RA or CA is the PKI management entity that terminates the CMP protocol. Certificate Management Protocol. If the RA terminates the CMP protocol CMP, it either responds directly as described in <xref target="RA_response" format="default"/> format="default"/>, or it forwards the certificate management operation towards the CA not using CMP. <xref target="RA_forwarde_messages" format="default"/> describes different options of how an RA can forward a CMP message using CMP. <xref target="RA_on-behalf" 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="default"/>.</t>
          <t keepWithNext="true"/>
          <table anchor="PKIManOp_support" align="left">
            <name>Level of Support for PKI Management Operations and Variants</name>
            <thead>
              <tr>
                <th align="left">ID</th>
                <th align="left">PKI Management Operations and Variants</th>
                <th align="left">EE</th>
                <th align="left">RA</th>
                <th align="left">CA</th>
              </tr>
            </thead>
            <tbody>
              <tr>
				<td align="left">Generic</td>
                <td align="left"><xref target="GenericParts" format="title"/>, align="left">Generic Aspects of PKI Messages and PKI Management Operations, <xref target="GenericParts" format="default"/></td>
                <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
                <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
                <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
              </tr>
              <tr>
				<td align="left">IR</td>
                <td align="left"><xref target="EE_newPKI" format="title"/>, align="left">Enrolling an End Entity to a New PKI, <xref target="EE_newPKI" format="default"/></td>
                <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
              </tr>
              <tr>
				<td align="left">CR</td>
                <td align="left"><xref target="EE_trustedPKI" format="title"/>, align="left">Enrolling an End Entity to a Known PKI, <xref target="EE_trustedPKI" format="default"/></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
              </tr>
              <tr>
				<td align="left">KUR</td>
                <td align="left"><xref target="EE_Update" format="title"/>, align="left">Updating a Valid Certificate, <xref target="EE_Update" format="default"/></td>
                <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
              </tr>
              <tr>
				<td align="left">P10CR</td>
                <td align="left"><xref target="EE_P10" format="title"/>, align="left"> 	Enrolling an End Entity Using a PKCS #10 Request, <xref target="EE_P10" format="default"/></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
              </tr>
              <tr>
				<td align="left">MAC</td>
                <td align="left"><xref target="EE_MAC" format="title"/>, with IR, align="left">Using MAC-Based Protection for Enrollment (IR, CR, and P10CR if supported, supported), <xref target="EE_MAC" format="default"/></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">SHOULD align="left"><bcp14>SHOULD</bcp14> 1)</td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
              </tr>
              <tr>
				<td align="left">CKeyGen</td>
                <td align="left"><xref target="EE_centralKeyGeneration" format="title"/>, IR, align="left">Adding Central Key Pair Generation to Enrollment (IR, CR, KUR, and P10CR if supported, supported), <xref target="EE_centralKeyGeneration" format="default"/></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
              </tr>
              <tr>
				<td align="left">RR</td>
                <td align="left"><xref target="EE_Revoke" format="title"/>, align="left">Revoking a Certificate, <xref target="EE_Revoke" format="default"/></td>
                <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
                <td align="left">SHOULD align="left"><bcp14>SHOULD</bcp14> 2)</td>
                <td align="left">SHOULD align="left"><bcp14>SHOULD</bcp14> 3)</td>
              </tr>
              <tr>
				<td align="left">CACerts</td>
                <td align="left"><xref target="EE_CACerts" format="title"/>, align="left">Get CA Certificates, <xref target="EE_CACerts" format="default"/></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
              </tr>
              <tr>
				<td align="left">RootUpd</td>
                <td align="left"><xref target="EE_RootCAUpdate" format="title"/>, align="left">Get Root CA Certificate Update, <xref target="EE_RootCAUpdate" format="default"/></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
              </tr>
              <tr>
				<td align="left">ReqTempl</td>
                <td align="left"><xref target="EE_Temp" format="title"/>, align="left">Get Certificate Request Template, <xref target="EE_Temp" format="default"/></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
              </tr>
              <tr>
				<td align="left">CRLUpd</td>
                <td align="left"><xref target="EE_CRLs" format="title"/>, align="left">CRL Update Retrieval, <xref target="EE_CRLs" format="default"/></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
              </tr>
              <tr>
				<td align="left">Polling</td>
                <td align="left"><xref target="EE_Polling" format="title"/>, align="left">Handling Delayed Delivery, <xref target="EE_Polling" format="default"/></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
              </tr>
              <tr>
				<td align="left">CertResp</td>
                <td align="left"><xref target="RA_response_enrollment" format="title"/> align="left">Responding to a Certificate Request (IR, CR, KUR, and P10CR if supported), <xref target="RA_response_enrollment" format="default"/></td>
                <td align="left">N/A</td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
              </tr>
              <tr>
				<td align="left">CertConf</td>
                <td align="left"><xref target="RA_response_confirmation" format="title"/>, align="left">Responding to a Confirmation Message, <xref target="RA_response_confirmation" format="default"/></td>
                <td align="left">N/A</td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
              </tr>
              <tr>
				<td align="left">RevResp</td>
                <td align="left"><xref target="RA_response_revocation" format="title"/>, align="left">Responding to a Revocation Request, <xref target="RA_response_revocation" format="default"/></td>
                <td align="left">N/A</td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
              </tr>
              <tr>
				<td align="left">GenResp</td>
                <td align="left"><xref target="RA_response_support" format="title"/> align="left">Responding to a Support Message (CACerts, RootUpd, ReqTempl, CRLUpd if supported), <xref target="RA_response_support" format="default"/></td>
                <td align="left">N/A</td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
              </tr>
              <tr>
				<td align="left">InitPoll</td>
                <td align="left"><xref target="RA_response_polling" format="title"/>, align="left">Initiating Delayed Delivery, <xref target="RA_response_polling" format="default"/></td>
                <td align="left">N/A</td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
              </tr>
              <tr>
				<td align="left">FwdKeep</td>
                <td align="left"><xref target="RA_forwarde_messages" format="title"/> align="left">Forwarding Messages - <xref target="RA_noChange" format="title"/>, Not Changing Protection, <xref target="RA_noChange" format="default"/></td>
                <td align="left">N/A</td>
                <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
                <td align="left">N/A</td>
              </tr>
              <tr>
				<td align="left">FwdAddS</td>
                <td align="left"><xref target="RA_forwarde_messages" format="title"/> align="left">Forwarding Messages - <xref target="RA_AddSingel" format="title"/>, Adding Protection to a Request Message, <xref target="RA_AddSingel" format="default"/></td>
                <td align="left">N/A</td>
                <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
                <td align="left">MUST</td> align="left"><bcp14>MUST</bcp14></td>
              </tr>
              <tr>
				<td align="left">FwdAddB</td>
                <td align="left"><xref target="RA_forwarde_messages" format="title"/> align="left">Forwarding Messages - <xref target="RA_AddBatch" format="title"/>, Batching Messages, <xref target="RA_AddBatch" format="default"/></td>
                <td align="left">N/A</td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
              </tr>
              <tr>
				<td align="left">FwdReqKP</td>
                <td align="left"><xref target="RA_forwarde_messages" format="title"/> align="left">Forwarding Messages - <xref target="RA_keepPOPO" format="title"/>, Not Changing Proof-of-Possession, <xref target="RA_keepPOPO" format="default"/></td>
                <td align="left">N/A</td>
                <td align="left">SHOULD align="left"><bcp14>SHOULD</bcp14> 1)</td>
                <td align="left">N/A</td>
              </tr>
              <tr>
				<td align="left">FwdReqBP</td>
                <td align="left"><xref target="RA_forwarde_messages" format="title"/> align="left">Forwarding Messages - <xref target="RA_breakPOPO" format="title"/>, Using raVerified, <xref target="RA_breakPOPO" format="default"/></td>
                <td align="left">N/A</td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
              </tr>
              <tr>
				<td align="left">CertROnB</td>
                <td align="left"><xref target="RA_on-behalf" format="title"/> align="left">Acting on Behalf of Other PKI Entities - <xref target="RA_on-behalf_request" format="title"/>, Requesting a Certificate, <xref target="RA_on-behalf_request" format="default"/></td>
                <td align="left">N/A</td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">N/A</td>
              </tr>
              <tr>
				<td align="left">RevROnB</td>
                <td align="left"><xref target="RA_on-behalf" format="title"/> align="left">Acting on Behalf of Other PKI Entities - <xref target="RA_on-behalf_revoke" format="title"/>, Revoking a Certificate, <xref target="RA_on-behalf_revoke" format="default"/></td>
                <td align="left">N/A</td>
                <td align="left">SHOULD align="left"><bcp14>SHOULD</bcp14> 2)</td>
                <td align="left">SHOULD align="left"><bcp14>SHOULD</bcp14> 3)</td>
              </tr>
            </tbody>
          </table>
		  <t>1) The
	  <ol type="%d)" spacing="normal">
		  <li>The RA should be able to change the CMP message protection from MAC-based to signature-based protection, protection; see <xref target="RA_keepPOPO" format="default"/>.</t>
		  <t>2) The format="default"/>.</li>
		  <li>The RA should be able to request certificate revocation on behalf of an EE, see EE (see <xref target="RA_on-behalf_revoke" format="default"/>, format="default"/>), e.g., in order to handle incidents.</t>
		  <t>3) An incidents.</li>
		  <li>An alternative would be to perform revocation at the CA without using CMP, for instance instance, using a local administration interface.</t> interface.</li>
	  </ol>
      </section>
      <section anchor="Transport" numbered="true" toc="default">
        <name>Message Transfer</name>
		<t>CMP does not have specific needs regarding message transfer, except that that, for each request message sent, eventually a sequence of one response message should be received.  Therefore, virtually any reliable transfer mechanism 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 conforming implementations.</t>
		<t>On different links between PKI entities, e.g., entities (e.g., EE-RA and RA-CA, RA-CA), different transfer mechanisms mechanisms, as specified in <xref target="Transfer_types" format="default"/> format="default"/>, may be used.</t>
		<t>HTTP SHOULD <bcp14>SHOULD</bcp14> be supported and CoAP MAY <bcp14>MAY</bcp14> be supported at all PKI entities for maximizing general interoperability at transfer level. Yet full flexibility is retained to choose whatever transfer mechanism is suitable, for instance instance, for devices and system architectures with specific constraints.</t>
		<t>The following table lists the name and level of support specified for each transfer mechanism.</t>
        <table anchor="Trans_Support" align="left">
          <name>Level of Support for Message Transfer Types</name>
          <thead>
            <tr>
              <th align="left">ID</th>
              <th align="left">Message Transfer Type</th>
              <th align="left">EE</th>
              <th align="left">RA</th>
              <th align="left">CA</th>
            </tr>
          </thead>
          <tbody>
            <tr>
                <td align="left">HTTP</td>
                <td align="left"><xref target="HTTP" format="title"/>, align="left">HTTP Transfer, <xref target="HTTP" format="default"/></td>
                <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
                <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
                <td align="left">SHOULD</td> align="left"><bcp14>SHOULD</bcp14></td>
            </tr>
            <tr>
                <td align="left">CoAP</td>
                <td align="left"><xref target="CoAP" format="title"/>, align="left">CoAP Transfer, <xref target="CoAP" format="default"/></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
            </tr>
            <tr>
                <td align="left">Piggyb</td>
                <td align="left"><xref target="Piggybacking" format="title"/>, align="left">Piggybacking on Other Reliable Transfer, <xref target="Piggybacking" format="default"/></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
            </tr>
            <tr>
                <td align="left">Offline</td>
                <td align="left"><xref target="Offline" format="title"/>, align="left">Offline Transfer, <xref target="Offline" format="default"/></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
                <td align="left">MAY</td> align="left"><bcp14>MAY</bcp14></td>
            </tr>
            </tbody>
          </table>
      </section>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
	  <t>This document defines new entries with
	  <t>IANA has registered the following content in the "CMP Well-Known URI Path Segments" registry (see https://www.iana.org/assignments/cmp/) <eref brackets="angle" target="https://www.iana.org/assignments/cmp"/>), as defined in <xref target="RFC8615" format="default">RFC&nbsp;8615</xref>.</t> format="default"/>.</t>
        <table anchor="Trans_operationLabels" align="left">
          <name>New "CMP Well-Known URI Path Segments" Registry Entries</name>
          <thead>
            <tr>
              <th align="left">Path Segment</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">initialization</td>
              <td align="left"><xref target="EE_newPKI" format="title"/> align="left">Enrolling an End Entity to a New PKI over HTTP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_newPKI" format="default"/></td>
           </tr>
            <tr>
              <td align="left">certification</td>
              <td align="left"><xref target="EE_trustedPKI" format="title"/> align="left">Enrolling an End Entity to a Known PKI over HTTP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_trustedPKI" format="default"/></td>
            </tr>
            <tr>
              <td align="left">keyupdate</td>
              <td align="left"><xref target="EE_Update" format="title"/> align="left">Updating a Valid Certificate over HTTP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_Update" format="default"/></td>
           </tr>
            <tr>
              <td align="left">pkcs10</td>
              <td align="left"><xref target="EE_P10" format="title"/> align="left">Enrolling an End Entity Using a PKCS #10 Request over HTTP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_P10" format="default"/></td>
            </tr>
            <tr>
              <td align="left">revocation</td>
              <td align="left"><xref target="EE_Revoke" format="title"/> align="left">Revoking a Certificate over HTTP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_Revoke" format="default"/></td>
            </tr>
            <tr>
              <td align="left">getcacerts</td>
              <td align="left"><xref target="EE_CACerts" format="title"/> align="left">Get CA Certificates over HTTP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_CACerts" format="default"/></td>
            </tr>
            <tr>
              <td align="left">getrootupdate</td>
              <td align="left"><xref target="EE_RootCAUpdate" format="title"/> align="left">Get Root CA Certificate Update over HTTP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_RootCAUpdate" format="default"/></td>
            </tr>
            <tr>
              <td align="left">getcertreqtemplate</td>
              <td align="left"><xref target="EE_Temp" format="title"/> align="left">Get Certificate Request Template over HTTP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_Temp" format="default"/></td>
            </tr>
            <tr>
              <td align="left">getcrls</td>
              <td align="left"><xref target="EE_CRLs" format="title"/> align="left">CRL Update Retrieval over HTTP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_CRLs" format="default"/></td>
            </tr>
            <tr>
              <td align="left">nested</td>
              <td align="left"><xref target="RA_AddBatch" format="title"/> align="left">Batching Messages over HTTP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="RA_AddBatch" format="default"/></td>
            </tr>
            <tr>
              <td align="left">ir</td>
              <td align="left"><xref target="EE_newPKI" format="title"/> align="left">Enrolling an End Entity to a New PKI over CoAP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_newPKI" format="default"/></td>
            </tr>
            <tr>
              <td align="left">cr</td>
              <td align="left"><xref target="EE_trustedPKI" format="title"/> align="left">Enrolling an End Entity to a Known PKI over CoAP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_trustedPKI" format="default"/></td>
            </tr>
            <tr>
              <td align="left">kur</td>
              <td align="left"><xref target="EE_Update" format="title"/> align="left">Updating a Valid Certificate over CoAP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_Update" format="default"/></td>
            </tr>
            <tr>
              <td align="left">p10</td>
              <td align="left"><xref target="EE_P10" format="title"/> align="left">Enrolling an End Entity Using a PKCS #10 Request over CoAP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_P10" format="default"/></td>
            </tr>
            <tr>
              <td align="left">rr</td>
              <td align="left"><xref target="EE_Revoke" format="title"/> align="left">Revoking a Certificate over CoAP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_Revoke" format="default"/></td>
            </tr>
            <tr>
              <td align="left">crts</td>
              <td align="left"><xref target="EE_CACerts" format="title"/> align="left">Get CA Certificates over CoAP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_CACerts" format="default"/></td>
            </tr>
            <tr>
              <td align="left">rcu</td>
              <td align="left"><xref target="EE_RootCAUpdate" format="title"/> align="left">Get Root CA Certificate Update over CoAP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_RootCAUpdate" format="default"/></td>
            </tr>
            <tr>
              <td align="left">att</td>
              <td align="left"><xref target="EE_Temp" format="title"/> align="left">Get Certificate Request Template over CoAP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_Temp" format="default"/></td>
            </tr>
            <tr>
              <td align="left">crls</td>
              <td align="left"><xref target="EE_CRLs" format="title"/> align="left">CRL Update Retrieval over CoAP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="EE_CRLs" format="default"/></td>
            </tr>
            <tr>
              <td align="left">nest</td>
              <td align="left"><xref target="RA_AddBatch" format="title"/> align="left">Batching Messages over CoAP</td>
              <td align="left">[thisRFC]</td> align="left">RFC 9483, <xref target="RA_AddBatch" format="default"/></td>
            </tr>
            </tbody>
          </table>
		  <t>&lt; TBD: New entries must be added to the registry "CMP Well-Known URI Path Segments". &gt;</t>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations as laid out in <xref target="RFC4210" format="default">CMP</xref> and updated by <xref target="I-D.ietf-lamps-cmp-updates" target="RFC9480" format="default">CMP Updates</xref> and Updates</xref>, <xref target="I-D.ietf-lamps-cmp-algorithms" target="RFC9481" format="default">CMP Algorithms</xref>, <xref target="RFC4211" format="default">CRMF</xref> updated by format="default">CRMF</xref>, <xref target="RFC9045" format="default">Algorithm Requirements Update</xref>, <xref target="RFC6712" format="default">CMP over HTTP</xref>, and <xref target="I-D.ietf-ace-cmpv2-coap-transport" target="RFC9482" format="default">CMP over CoAP</xref> apply.</t>
	  <t>Trust anchors for chain validations are often provided in the form of self-signed certificates. All trust anchors MUST <bcp14>MUST</bcp14> be stored on the device with integrity protection. In some cases, a PKI entity may not have sufficient storage for the complete certificates. In such cases cases, it may only store, e.g., a hash of each self-signed certificate and require receiving the certificate in the extraCerts field field, as described in <xref target="extraCerts" format="default"/>. If such self-signed certificates are provided in-band in the messages, they MUST <bcp14>MUST</bcp14> be verified using information from the trust store of the PKI entity.</t>
      <t>For TLS using shared secret information-based authentication, both PSK and PAKE provide the same amount of protection against a real-time authentication attack attack, which is directly the amount of entropy in the shared secret. The difference 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 against brute-force decryption, where a PSK-based cipher suite only provides security according to the entropy of the shared secret, while a PAKE-based cipher 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>
  </middle>
  <back>
    <!-- References split into informative and normative -->

   <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (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.xml")

    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 files in the same
    directory as the including file. You can also define the XML_LIBRARY environment 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/... ).-->
   <displayreference target="I-D.ietf-anima-brski-ae" to="BRSKI-AE"/>
   <displayreference target="I-D.ietf-anima-brski-prm" to="BRSKI-PRM"/>
   <displayreference target="I-D.ietf-netconf-sztp-csr" to="SZTP-CSR"/>
   <displayreference target="I-D.ietf-lamps-rfc4210bis" to="PKIX-CMP"/>
   <displayreference target="I-D.ietf-lamps-rfc6712bis" to="HTTP-CMP"/>
   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4210.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4210.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4211.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4211.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5958.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5958.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6712.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6712.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
	    <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8615.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8615.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8933.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8933.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9045.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9045.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-lamps-cmp-updates.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-lamps-cmp-algorithms.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ace-cmpv2-coap-transport.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/>

<reference anchor="RFC9480" target="https://www.rfc-editor.org/info/rfc9480">
<front>
<title>Certificate Management Protocol (CMP) Updates</title>
<author fullname="Hendrik Brockhaus" initials="H." surname="Brockhaus">
<organization>Siemens</organization>
</author>
<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="editor">
<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>
        <name>Informative References</name>
        <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3647.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3647.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5753.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5753.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8366.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8366.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8572.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8649.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8572.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8995.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8649.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-anima-brski-ae.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8995.xml"/>

<reference anchor="I-D.ietf-anima-brski-ae" target="https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-05">
<front>
<title>
BRSKI-AE: Alternative Enrollment Protocols in BRSKI
</title>
<author fullname="David von Oheimb" initials="D." surname="von Oheimb">
<organization>Siemens AG</organization>
</author>
<author fullname="Steffen Fries" initials="S." surname="Fries">
<organization>Siemens AG</organization>
</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://datatracker.ietf.org/doc/bibxml3/draft-ietf-anima-brski-prm.xml"/> href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-brski-prm.xml"/>

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-netconf-sztp-csr.xml"/> href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-sztp-csr.xml"/>

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-lamps-rfc4210bis.xml"/> href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lamps-rfc4210bis.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-lamps-rfc6712bis.xml"/>
        <!-- A reference written by an organization not a person. --> href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lamps-rfc6712bis.xml"/>

		<reference anchor="NIST.CSWP.04162018" target="http://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf">
		  <front>
		    <title>Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1</title> Cybersecurity</title>
		    <author>
		      <organization>National Institute of Standards and Technology (NIST)</organization>
		    </author>
		    <date year="2018" month="April"/>
		  </front>
			<seriesInfo name="NIST" value="NIST.CSWP.04162018"/>
		  <refcontent>Version 1.1</refcontent>
		  <seriesInfo name="DOI" value="10.6028/NIST.CSWP.04162018"/>
		</reference>

		<reference anchor="NIST.SP.800-57p1r5" target="https://doi.org/10.6028/NIST.SP.800-57pt1r5">
		  <front>
		    <title>Recommendation for key management, part Key Management: Part 1 :general</title> - General</title>
		    <author initials="E B" initials="E" surname="Barker" fullname="E B fullname="Elaine Barker">
		      <organization/>
		    </author>
		    <date year="2020"/> year="2020" month="May"/>
		  </front>
		  <seriesInfo name="NIST" value="NIST.SP.800-57pt1r5"/>
			<seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
		</reference>

		<reference anchor="IEEE.802.1AR_2018" target="https://ieeexplore.ieee.org/document/8423794">
		<front>
		  <title>IEEE Standard for Local and metropolitan area networks Metropolitan Area Networks - Secure Device Identity</title>
		  <author>
		    <organization>IEEE</organization>
		  </author>
		  <date day="2" month="August" year="2018"/>
		</front>
		<seriesInfo name="IEEE" name="IEEE Std" value="802.1AR-2018"/>
		<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8423794"/>
		</reference>

		<reference anchor="ETSI-3GPP.33.310" target="http://www.3gpp.org/ftp/Specs/html-info/33310.htm">
		  <front>
		    <title>Network Domain Security (NDS); Authentication Framework (AF)</title>
		    <author>
		      <organization>3GPP</organization>
		    </author>
		    <date day="16" month="December" year="2020"/>
		  </front>
		  <seriesInfo name="3GPP TS" value="33.310 16.6.0"/>
		</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">
		  <front>
		    <title>Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements</title>
		    <author>
		      <organization>ETSI</organization>
		    </author>
		    <date month="May" year="2021"/>
		  </front>
		  <seriesInfo name="ETSI EN" value="319 411-1 V1.3.1"/> 411-1"/>
		  <refcontent>V1.3.1</refcontent>
		</reference>

		<reference anchor="UNISIG.Subset-137" target="https://www.era.europa.eu/sites/default/files/filesystem/ertms/ccs_tsi_annex_a_-_mandatory_specifications/set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-_subset-137_v100.pdf"> target="https://www.era.europa.eu/system/files/2023-01/sos3_index083_-_subset-137_v100.pdf">
		  <front>
            <title>Subset-137; ERTMS/ETCS
		    <title>ERTMS/ETCS On-line Key Management FFFIS; V1.0.0</title> FFFIS</title>
		    <author>
		      <organization>UNISIG</organization>
		    </author>
		    <date month="December" year="2015"/>
		  </front>
		  <refcontent>Subset-137, V1.0.0</refcontent>
		</reference>

        <reference anchor="IEC.62443-3-3" target="https://webstore.iec.ch/publication/7033">
          <front>
            <title>Industrial communication networks - Network and system security - Part 3-3: System security requirements and security levels</title>
            <author>
              <organization>IEC</organization>
            </author>
            <date month="August" year="2013"/>
          </front>
          <seriesInfo name="IEC" value="62443-3-3"/> value="62443-3-3:2013"/>
        </reference>
      </references>
    </references>
    <section anchor="Param_Example" numbered="true" toc="default">
      <name>Example CertReqTemplate</name>
      <t keepWithNext="true">Suppose the server requires that the certTemplate contains</t> contains:</t>
      <ul spacing="normal">
        <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 two organizational unit fields with given values "myDept" and "myGroup",</li>
        <li>the publicKey field contains an ECC Elliptic Curve Cryptography (ECC) key 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 keyUsage extension marked critical with the value digitalSignature and keyAgreement, and</li>
        <li>the extKeyUsage extension with values to be filled in by the EE.</li>
      </ul>
      <t keepWithNext="true">Then the infoValue with certTemplate and keySpec fields returned to the EE will be encoded as follows:</t>
      <artwork align="left" name="Example_CertReqTemplate" name="" type="" alt=""><![CDATA[
SEQUENCE {
  SEQUENCE {
    [3] {
      SEQUENCE {}
      }
    [5] {
      SEQUENCE {
        SET {
          SEQUENCE {
            OBJECT IDENTIFIER commonName (2 5 4 3)
            UTF8String ""
            }
          }
        SET {
          SEQUENCE {
            OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
            UTF8String "myDept"
            }
          }
        SET {
          SEQUENCE {
            OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
            UTF8String "myGroup"
            }
          }
        }
      }
    [9] {
      SEQUENCE {
        OBJECT IDENTIFIER subjectAltName (2 5 29 17)
        OCTET STRING, encapsulates {
          SEQUENCE {
            [2] "www.myServer.com"
            [7] ""
            }
          }
        }
      SEQUENCE {
        OBJECT IDENTIFIER keyUsage (2 5 29 15)
        BOOLEAN TRUE
        OCTET STRING, encapsulates {
          BIT STRING 3 unused bits
            "10001"B
          }
        }
      SEQUENCE {
        OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
        OCTET STRING, encapsulates {
          SEQUENCE {}
          }
        }
      }
    }
  SEQUENCE {
    SEQUENCE {
      OBJECT IDENTIFIER algId (1 3 6 1 5 5 7 5 1 11)
        SEQUENCE {
          OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
          OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7)
          }
      }
    SEQUENCE {
      OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12)
      INTEGER 2048
      }
    }
  }
                ]]></artwork>
    </section>
    <section anchor="History" numbered="true" anchor="Acknowledgements" numbered="false" toc="default">
      <name>History of Changes</name>
      <t>Note: This appendix will be deleted in the final version of the document.</t>
      <t keepWithNext="true">From version 20 -&gt; 21:</t>
      <ul spacing="compact">
	    <li>Addressed comment from Murray checking each usage of key word "SHOULD" and changing it to "MUST", "MAY", or "should" where needed or adding an explanation how interoperability may be affected (see thread "Murray Kucherawy's No 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 review 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 Terminology' after Section 1.1 and adding a paragraph on the use of key word "SHOULD", moving section 'Compatibility with Existing CMP Profiles' right before section 'Use of CMP in SZTP and BRSKI Environments', and adding a paragraph to section 'Scope of this Document' also clarifying the use of key word "SHOULD" (see thread "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 guidance which CMS key management technique to use with central key management (see thread "CMS: selection of key management technique to use for EnvelopedData") and removed normative language regarding which key management technique to support</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 draft-ietf-lamps-lightweight-cmp-profile-16: (with COMMENT)")</li>
	    <li>Updated Section 4.3.4 with one minor correction and one clarification (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 draft-ietf-lamps-lightweight-cmp-profile-16: (with COMMENT)")</li>
	    <li>Addressed comment from Robert (see thread “Robert Wilton’s No Objection 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 Record 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 Objection 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 review 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 draft-ietf-lamps-lightweight-cmp-profile-13")</li>
	    <li>Added a note to Section 1 informing about rfc4210bis and rfc6712bis activity</li>
	    <li>Added support for constrained PKI entities that can, e.g., only store a hash of a self-signed certificate as trust anchor and require the self-signed certificate to be provided in-line in extraCerts, see Section 3.3 and Section 9</li>
		<li>Addressed idnits feedback, specifically changing the following 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' -> 'sequence 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 central key generation with certificate update</li>
	    <li>Updated Section 4.3.4 for clarification that only one CRL per round-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 signature-based protection as the default and the exception for not protecting error messages 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 management 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 into more detailed tables in Section 7 (see thread "WG Last Call for draft-ietf-lamps-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 "certConf - 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 validating the authorization of centrally generated keys</li>
        <li>Updated Section 4.3.4 adding some clarifications on CRL update retrieval (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>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-algorithms-07")</li>
        <li>Rolled back part of the changes on root CA certificate updates in Section 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 BRSKI-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 delayed 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 and 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 operational 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 prevent 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 protection to a single message to mandatory and replacing protection to optional</li>
        <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</li>
        <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-profile-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 wording</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 Section 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 extensive 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 Algorithms 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 draft 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 handling 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 copied 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 nested messages when a protection by the RA is required.</li>
        <li>Deleted the section on HTTP URI definition and discovery as some content was moved to CMP Updates. The rest of the content was moved back to the HTTP 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 to conflicts with UNISIG Subset-137.</li>
        <li>Minor clarifications on extraCerts in <xref target="extraCerts" format="default"/> and <xref target="EE_newPKI" format="default"/>.</li>
        <li>Complete specification of requesting a certificate from a trusted PKI with signature protection in <xref target="EE_trustedPKI" format="default"/>.</li>
        <li>Changed from symmetric key-encryption to password-based key management technique in  <xref target="EE_KGPB" format="default"/> as discussed on the mailing 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" format="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 operation, including an example added in the Appendix.  Keep rsaKeyLen as a single integer value in <xref target="EE_Temp" format="default"/> as discussed on the mailing 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 <xref target="HTTP" format="default"/> on definition and discovery of supported HTTP 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 and /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 for 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 management 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"/> Appendix D and E in <xref target="Existing_profiles" format="default"/>.</li>
        <li>Clarified some references to different sections and added some clarification in response to feedback from Michael Richardson and Tomas Gustavsson.</li>
        <li>Added an additional label to the operational path to address multiple 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 protection of centrally generated keys in <xref target="EE_centralKeyGeneration" format="default"/>.</li>
        <li>Added some clarifications on the certificates for root CA certificate update in <xref target="EE_RootCAUpdate" format="default"/>.</li>
        <li>Added a section to specify the usage of nested messages for RAs to add an additional protection for further discussion, see <xref target="RA_Add" format="default"/>.</li>
        <li>Added a table containing endpoints for HTTP transport in <xref target="HTTP" format="default"/> to simplify addressing PKI management entities.</li>
        <li>Added some ToDos resulting from discussion with Tomas Gustavsson.</li>
        <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 PKI 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="default"/>.</li>
        <li>Complete specification of handling delayed enrollment due to asynchronous message delivery in <xref target="EE_Polling" format="default"/>.</li>
        <li>Complete specification of additional support messages, e.g., to update a Root CA certificate or to request an <xref target="RFC8366" format="default">RFC&nbsp;8366</xref> voucher, in <xref target="EE_GeneralMessage" format="default"/>.</li>
        <li>Minor changes in wording.</li>
      </ul>
      <t keepWithNext="true">From draft-brockhaus-lamps-industrial-cmp-profile-00 -&gt; draft-brockhaus-lamps-lightweight-cmp-profile-00:</t>
      <ul spacing="compact">
        <li>Change focus from industrial to more multi-purpose use cases and lightweight CMP profile.</li>
        <li>Incorporate the omitted confirmation into the header specified in <xref target="Header" format="default"/> and described in the standard enrollment use case in <xref target="EE_newPKI" format="default"/> due to discussion with Tomas Gustavsson.</li>
        <li>Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's entities certificate' in <xref target="RA_on-behalf_revoke" format="default"/>, because it is regarded as important functionality in many environments to enable the management station to revoke EE certificates.</li>
        <li>Complete the specification of
      <name>Acknowledgements</name>
      <t>We thank the revocation message flow in <xref target="EE_Revoke" format="default"/> and <xref target="RA_on-behalf_revoke" format="default"/>.</li>
        <li>The CoAP based transport mechanism and piggybacking of CMP messages on top of other reliable transport protocols is out of scope various reviewers of this document and would need to be specified in another document.</li>
        <li>Further minor changes in wording.</li>
      </ul> document.</t>
    </section>
  </back>
</rfc>