rfc9483.original.xml   rfc9483.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!-- This ID was written based on the davies-template-bare-06.xml
available on https://tools.ietf.org/tools/templates/
The template was designed for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org . -->
<!-- <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!-- declare nbsp and friends --> <!ENTITY nbsp "&#160;">
<!ENTITY nbsp "&#xa0;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#x2011;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#x2060;"> <!ENTITY wj "&#8288;">
]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> ]>
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<!-- end of list of popular I-D processing instructions -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
category="std" category="std"
consensus="true" consensus="true"
number="9483"
docName="draft-ietf-lamps-lightweight-cmp-profile-21" docName="draft-ietf-lamps-lightweight-cmp-profile-21"
ipr="trust200902" ipr="trust200902"
obsoletes="" obsoletes=""
updates="" updates=""
submissionType="IETF" submissionType="IETF"
xml:lang="en" xml:lang="en"
tocInclude="true" tocInclude="true"
tocDepth="4" tocDepth="4"
symRefs="true" symRefs="true"
sortRefs="true" sortRefs="true"
version="3"> version="3">
<!-- xml2rfc v2v3 conversion 3.5.0 --> <!-- xml2rfc v2v3 conversion 3.5.0 -->
<front> <front>
<title abbrev="Lightweight CMP Profile">Lightweight Certificate Management P <title abbrev="LCMPP">Lightweight Certificate Management Protocol (CMP) Prof
rotocol (CMP) Profile</title> ile</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-lightweight-cmp-pr <seriesInfo name="RFC" value="9483"/>
ofile-21"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Hendrik Brockhaus" initials="H." surname="Brockhaus"> <author fullname="Hendrik Brockhaus" initials="H." surname="Brockhaus">
<organization abbrev="Siemens">Siemens</organization> <organization abbrev="Siemens">Siemens</organization>
<address> <address>
<postal> <postal>
<street>Werner-von-Siemens-Strasse 1</street> <street>Werner-von-Siemens-Strasse 1</street>
<code>80333</code> <code>80333</code>
<city>Munich</city> <city>Munich</city>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>hendrik.brockhaus@siemens.com</email> <email>hendrik.brockhaus@siemens.com</email>
skipping to change at line 84 skipping to change at line 67
<postal> <postal>
<street>Werner-von-Siemens-Strasse 1</street> <street>Werner-von-Siemens-Strasse 1</street>
<code>80333</code> <code>80333</code>
<city>Munich</city> <city>Munich</city>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>steffen.fries@siemens.com</email> <email>steffen.fries@siemens.com</email>
<uri>https://www.siemens.com</uri> <uri>https://www.siemens.com</uri>
</address> </address>
</author> </author>
<date year="2023"/> <date year="2023" month="October"/>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2r
fc will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<area>Internet</area> <area>Internet</area>
<workgroup>LAMPS Working Group</workgroup> <workgroup>LAMPS Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>CMP</keyword> <keyword>CMP</keyword>
<abstract> <abstract>
<t>This document aims at simple, interoperable, and automated PKI manageme nt operations covering typical use cases of industrial and IoT scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightwei ght as possible, only the most crucial types of operations and options are speci fied as mandatory. More specialized or complex use cases are supported with opt ional features.</t> <t>This document aims at simple, interoperable, and automated PKI manageme nt operations covering typical use cases of industrial and Internet of Things (I oT) scenarios. This is achieved by profiling the Certificate Management Protoco l (CMP), the related Certificate Request Message Format (CRMF), and transfer bas ed on HTTP or Constrained Application Protocol (CoAP) in a succinct but sufficie ntly detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the m ost crucial types of operations and options are specified as mandatory. More sp ecialized or complex use cases are supported with optional features.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" numbered="true" toc="default"> <section anchor="Introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>[RFC Editor:</t> <t>This document specifies PKI management operations supporting machine-to
<t>Please perform the following substitution.</t> -machine and IoT use cases. Its focus is to maximize automation and interoperabi
<ul spacing="normal"> lity between all involved PKI entities, ranging from end entities (EEs) over any
<li>RFCXXXX --> the assigned numerical RFC value for this draft</li> number of intermediate PKI management entities, such as registration authoritie
<li>RFCAAAA --> the assigned numerical RFC value for <xref target="I-D s (RAs), to the <xref target="RFC4210" format="default">Certificate Management P
.ietf-lamps-cmp-updates" format="default"/></li> rotocol (CMP)</xref> endpoints of certification authority (CA) systems. This pr
<li>RFCBBBB --> the assigned numerical RFC value for <xref target="I-D ofile makes use of the concepts and syntax specified in <xref target="RFC4210" f
.ietf-lamps-cmp-algorithms" format="default"/></li> ormat="default">CMP</xref> <xref target="RFC9480" format="default"/> <xref targe
</ul> t="RFC9481" format="default"/>, <xref target="RFC4211" format="default">Certific
<t>Please also update the following references to associated drafts in ate Request Message Format (CRMF)</xref> <xref target="RFC9045" format="default"
progress to reflect their final RFC assignments, if available:</t> />, <xref target="RFC5652" format="default">Cryptographic Message Syntax (CMS)</
<ul spacing="normal"> xref> <xref target="RFC8933" format="default"/>, <xref target="RFC6712" format="
<li><xref target="I-D.ietf-lamps-cmp-updates" format="default"/></li> default">HTTP transfer for CMP</xref>, and <xref target="RFC9482" format="defaul
<li><xref target="I-D.ietf-lamps-cmp-algorithms" format="default"/></l t">CoAP transfer for CMP</xref>. CMP, CRMF, and CMS are feature-rich specificat
i> ions, but most application scenarios use only a limited subset of the same speci
<li><xref target="I-D.ietf-ace-cmpv2-coap-transport" format="default"/ fied functionality. Additionally, the standards are not always precise enough o
></li> n how to interpret and implement the described concepts. Therefore, this docume
<li><xref target="I-D.ietf-netconf-sztp-csr" format="default"/></li> nt aims to tailor the available options and specify how to use them in adequate
<li><xref target="I-D.ietf-anima-brski-ae" format="default"/></li> detail to make the implementation of interoperable automated certificate managem
<li><xref target="I-D.ietf-anima-brski-prm" format="default"/></li> ent as straightforward and lightweight as possible.</t>
</ul> <t>While this document was being developed, documents intended to obsol
<t>]</t> ete RFC 4210 <xref target="I-D.ietf-lamps-rfc4210bis" format="default"/> and RF
<t>This document specifies PKI management operations supporting machine-to C 6712 <xref target="I-D.ietf-lamps-rfc6712bis" format="default"/> were posted,
-machine and IoT use cases. Its focus is to maximize automation and interoperabi and they include the full set of changes described in <xref target="RFC9480" for
lity between all involved PKI entities, ranging from end entities (EE) over any mat="default">CMP Updates</xref>.</t>
number of intermediate PKI management entities such as Registration Authorities
(RA) to the CMP endpoints of Certification Authority (CA) systems. This profile
makes use of the concepts and syntax specified in <xref target="RFC4210" format
="default">CMP</xref>, <xref target="I-D.ietf-lamps-cmp-updates" format="default
"/>, and <xref target="I-D.ietf-lamps-cmp-algorithms" format="default"/>, <xref
target="RFC4211" format="default">CRMF</xref> and <xref target="RFC9045" format=
"default"/>, <xref target="RFC5652" format="default">CMS</xref> and <xref target
="RFC8933" format="default"/>, <xref target="RFC6712" format="default">HTTP tran
sfer for CMP</xref>, and <xref target="I-D.ietf-ace-cmpv2-coap-transport" format
="default">CoAP transfer for CMP</xref>. CMP, CRMF and CMS are feature-rich spe
cifications, but most application scenarios use only a limited subset of the sam
e specified functionality. Additionally, the standards are not always precise e
nough on how to interpret and implement the described concepts. Therefore, this
document aims to tailor the available options and specify how to use them in ad
equate detail to make the implementation of interoperable automated certificate
management as straightforward and lightweight as possible.</t>
<t>Note: In the meantime <xref target="I-D.ietf-lamps-rfc4210bis" forma
t="default">RFC4210bis</xref> and <xref target="I-D.ietf-lamps-rfc6712bis" forma
t="default">RFC6712bis</xref> drafts were submitted incorporating the changes li
sted in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates</
xref> into the original RFC text.</t>
<section anchor="How_to_read" numbered="true" toc="default"> <section anchor="How_to_read" numbered="true" toc="default">
<name>How to Read This Document</name> <name>How to Read This Document</name>
<t>This document has become longer than the authors would have li <t>This document has become longer than the authors would have li
ked it to be. Yet apart from studying <xref target="GenericParts" format="defau ked it to be. Yet apart from studying <xref target="GenericParts" format="defau
lt"/>, which contains general requirements, the reader does not have to work thr lt"/>, which contains general requirements, the reader does not have to work thr
ough the whole document. The guidance in Sections <xref target="Structure" form ough the whole document. The guidance in Sections <xref target="Structure" form
at="counter"/> and <xref target="Conformity" format="counter"/> should be used t at="counter"/> and <xref target="Conformity" format="counter"/> should be used t
o figure out which parts of <xref target="EE_UseCases" format="default"/> to <xr o figure out which parts of Sections <xref target="EE_UseCases" format="counter"
ef target="Transfer_types" format="default"/> are relevant for the target certif /> to <xref target="Transfer_types" format="counter"/> are relevant for the targ
icate management solution depending on the PKI management operations, their vari et certificate management solution, depending on the PKI management operations,
ants, and types of message transfer needed.</t> their variants, and types of message transfer needed.</t>
<t>Since conformity to this document can be achieved by implement <t>Since conformity to this document can be achieved by implement
ing only the functionality declared mandatory in <xref target="Conformity" forma ing only the functionality declared mandatory in <xref target="Conformity" forma
t="default"/>, the profile can still be called lightweight because in particular t="default"/>, the profile can still be called lightweight because, in particula
for end entities the mandatory-to-implement set of features is rather limited.< r for end entities, the mandatory-to-implement set of features is rather limited
/t> .</t>
</section> </section>
<section anchor="Convention_Terminology" numbered="true" toc="default"> <section anchor="Convention_Terminology" numbered="true" toc="default">
<name>Conventions and Terminology</name> <name>Conventions and Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", " <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" i 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp1
n this document are to be interpreted as described in BCP 14 <xref target="RFC21 4>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<
19" format="default"/> <xref target="RFC8174" format="default"/> when, and only bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp1
when, they appear in all capitals, as shown here.</t> 4>" in this document are to be interpreted as described in BCP 14 <xref target="
<t>The key word "PROHIBITED" is to be interpreted to mean that th RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and
e respective ASN.1 field SHALL NOT be present or used.</t> only when, they appear in all capitals, as shown here.</t>
<t keepWithNext="true">Technical terminology is used in conformance with <t>The term "PROHIBITED" is to be interpreted to mean that the re
<xref target="RFC4210" format="default">RFC&nbsp;4210</xref>, <xref target="RFC spective ASN.1 field <bcp14>SHALL NOT</bcp14> be present or used.</t>
4211" format="default">RFC&nbsp;4211</xref>, <xref target="RFC5280" format="defa <t keepWithNext="true">Technical terminology is used in conformance with
ult">RFC&nbsp;5280</xref>, and <xref target="IEEE.802.1AR_2018" format="default" <xref target="RFC4210" format="default"/>, <xref target="RFC4211" format="defau
>IEEE&nbsp;802.1AR</xref>. The following key words are used:</t> lt"/>, <xref target="RFC5280" format="default"/>, and <xref target="IEEE.802.1AR
_2018" format="default">IEEE&nbsp;802.1AR</xref>. The following terminology is u
sed:</t>
<dl newline="false" spacing="normal" indent="7"> <dl newline="false" spacing="normal" indent="7">
<dt>CA:</dt> <dt>CA:</dt>
<dd>Certification authority, which issues certificates.</dd> <dd>Certification authority, which issues certificates.</dd>
<dt>RA:</dt> <dt>RA:</dt>
<dd>Registration authority, an optional PKI component to which a CA de legates certificate management functions such as end entity authentication and a uthorization checks for incoming requests. An RA can also provide conversion bet ween various certificate management protocols and other protocols providing some operations related to certificate management.</dd> <dd>Registration authority, an optional PKI component to which a CA de legates certificate management functions, such as end entity authentication and authorization checks for incoming requests. An RA can also provide conversion be tween various certificate management protocols and other protocols providing som e operations related to certificate management.</dd>
<dt>LRA:</dt> <dt>LRA:</dt>
<dd> <dd>
<t>Local registration authority, a specific form of RA wi <t>Local registration authority, a specific form of RA with proximity
th proximity to the end entities.</t> to the end entities.</t>
<t>Note: For ease of reading, this document uses the term <t>Note: For ease of reading, this document also uses the term "R
"RA" also for LRAs in all cases where the difference is not relevant.</t> A" for LRAs in all cases where the difference is not relevant.</t>
</dd> </dd>
<dt>KGA:</dt> <dt>KGA:</dt>
<dd>Key generation authority, an optional system component, typically co-located with an RA or CA, that offers key generation services to end entities .</dd> <dd>Key generation authority, an optional system component, typically colocated with an RA or CA, that offers key generation services to end entities. </dd>
<dt>EE:</dt> <dt>EE:</dt>
<dd>End entity, typically a device or service that holds a public-priv ate key pair for which it manages a public-key certificate. An identifier for th e EE is given as the subject of its certificate.</dd> <dd>End entity, typically a device or service that holds a public-priv ate key pair for which it manages a public key certificate. An identifier for th e EE is given as the subject of its certificate.</dd>
</dl> </dl>
<t keepWithNext="true">The following terminology is reused from <xref ta <t keepWithNext="true">The following terminology is reused from <xref ta
rget="RFC4210" format="default">RFC&nbsp;4210</xref>, as follows:</t> rget="RFC4210" format="default"/> as follows:</t>
<dl newline="false" spacing="normal" indent="28"> <dl newline="false" spacing="normal" indent="29">
<dt>PKI management operation:</dt> <dt>PKI management operation:</dt>
<dd>All CMP messages belonging to a single transaction. The transacti on is identified by the transactionID field of the message headers.</dd> <dd>All CMP messages belonging to a single transaction. The transacti on is identified by the transactionID field of the message headers.</dd>
<dt>PKI management entity:</dt> <dt>PKI management entity:</dt>
<dd>A non-EE PKI entity, i.e., RA or CA.</dd> <dd>A non-EE PKI entity, i.e., an RA or a CA.</dd>
<dt>PKI entity:</dt> <dt>PKI entity:</dt>
<dd>An EE or PKI management entity.</dd> <dd>An EE or PKI management entity.</dd>
</dl> </dl>
<t>CMP messages are referred to by the names of PKIBody choices d efined in <xref target="RFC4210" format="default">RFC&nbsp;4210 Section 5.1.2</x ref> and are further described in <xref target="EE_UseCases" format="default"/> of this document.</t> <t>CMP messages are referred to by the names of PKIBody choices d efined in <xref target="RFC4210" format="default" sectionFormat="of" section="5. 1.2"/> and are further described in <xref target="EE_UseCases" format="default"/ > of this document.</t>
<t keepWithNext="true">The following terms are introduced in this docume nt:</t> <t keepWithNext="true">The following terms are introduced in this docume nt:</t>
<dl newline="false" spacing="normal" indent="30"> <dl newline="false" spacing="normal" indent="29">
<dt>CMP protection key:</dt> <dt>CMP protection key:</dt>
<dd>The private key used to sign a CMP message.</dd> <dd>The private key used to sign a CMP message.</dd>
<dt>CMP protection certificate:</dt> <dt>CMP protection certificate:</dt>
<dd>The certificate related to the CMP protection key. If the keyUsag e extension is present, it MUST include digitalSignature.</dd> <dd>The certificate related to the CMP protection key. If the keyUsag e extension is present, it <bcp14>MUST</bcp14> include digitalSignature.</dd>
</dl> </dl>
</section> </section>
<section anchor="Motivation" numbered="true" toc="default"> <section anchor="Motivation" numbered="true" toc="default">
<name>Motivation for a Lightweight Profile of CMP</name> <name>Motivation for a Lightweight Profile of CMP</name>
<t>CMP was standardized in 1999 and is implemented in several PKI produc ts. In 2005, a completely reworked and enhanced version 2 of <xref target="RFC42 10" format="default">CMP</xref> and <xref target="RFC4211" format="default">CRMF </xref> has been published, followed by a document specifying a transfer mechani sm for CMP messages using HTTP <xref target="RFC6712" format="default"/> in 2012 .</t> <t>CMP was standardized in 1999 and is implemented in several PKI produc ts. In 2005, a completely reworked and enhanced version 2 of <xref target="RFC42 10" format="default">CMP</xref> and <xref target="RFC4211" format="default">CRMF </xref> has been published, followed by a document specifying a transfer mechani sm for CMP messages using HTTP <xref target="RFC6712" format="default"/> in 2012 .</t>
<t>CMP is a capable protocol and could be used more widely. <xref target <t>CMP is a capable protocol and could be used more widely. <xref target
="RFC4210" format="default">RFC&nbsp;4210</xref> and <xref target="I-D.ietf-lamp ="RFC4210" format="default">CMP</xref> and <xref target="RFC9480" format="defaul
s-cmp-updates" format="default">CMP Updates</xref> offer a very large set of fea t">CMP Updates</xref> offer a very large set of features and options. On one ha
tures and options. On the one hand, this makes CMP applicable to a very wide ra nd, this makes CMP applicable to a very wide range of scenarios; on the other ha
nge of scenarios, but on the other hand, a full implementation supporting all op nd, a full implementation supporting all options is not realistic because this w
tions is not realistic because this would take undue effort.</t> ould take undue effort.</t>
<t>In order to reduce complexity, the set of mandatory PKI manage <t>In order to reduce complexity, the set of mandatory PKI management ope
ment operations and variants required by this specification has been kept lean. rations and variants required by this specification has been kept lean. This li
This limits development effort and minimizes resource needs, which is particula mits development efforts and minimizes resource needs, which is particularly imp
rly important for memory-constrained devices. To this end, when there was desig ortant for memory-constrained devices. To this end, when there was design flexi
n flexibility to either have necessary complexity on the EE or in the PKI manage bility to either have necessary complexity on the EE or in the PKI management en
ment entity, this profile chose to include it in the PKI management entities whe tity, this profile chose to include it in the PKI management entities where typi
re typically more computational resources are available. Additional recommended cally more computational resources are available. Additional recommended PKI ma
PKI management operations and variants support some more complex scenarios that nagement operations and variants support some more complex scenarios that are co
are considered beneficial for environments with more specific demands or bounda nsidered beneficial for environments with more specific demands or boundary cond
ry conditions. The optional PKI management operations support less common scena itions. The optional PKI management operations support less common scenarios an
rios and requirements.</t> d requirements.</t>
<t>Moreover, many details of the CMP protocol have been left open or hav <t>Moreover, many details of the Certificate Management Protocol have be
e not been specified in full preciseness. The profiles specified in <xref target en left open or have not been specified in full preciseness. The profiles specif
="RFC4210" format="default">Appendix D and E of RFC&nbsp;4210</xref> define some ied in Appendices <xref target="RFC4210" sectionFormat="bare" section="D"/> and
more detailed PKI management operations. Yet, the specific needs of highly auto <xref target="RFC4210" sectionFormat="bare" section="E"/> of <xref target="RFC42
mated scenarios for a machine-to-machine communication are not covered sufficien 10" format="default"/> define some more detailed PKI management operations. Yet
tly.</t> the specific needs of highly automated scenarios for machine-to-machine communic
<t>Profiling is a way to reduce feature richness and complexity of stand ation are not covered sufficiently.</t>
ards to what is needed for specific use cases. 3GPP and UNISIG already use profi <t>Profiling is a way to reduce feature richness and complexity of stand
ling of CMP as a way to cope with these challenges. To profile means to take ad ards to what is needed for specific use cases. 3GPP and UNISIG already use profi
vantage of the strengths of the given protocol, while explicitly narrowing down ling of CMP as a way to cope with these challenges. To profile means to take ad
the options it provides to those needed for the purpose(s) at hand and eliminati vantage of the strengths of the given protocol while explicitly narrowing down t
ng all identified ambiguities. In this way the general aspects of the protocol a he options it provides to those needed for the purpose(s) at hand and eliminatin
re utilized and only the special requirements of the target scenarios need to be g all identified ambiguities. In this way, the general aspects of the protocol a
dealt with using distinct features the protocol offers.</t> re utilized and only the special requirements of the target scenarios need to be
<t>Defining a profile for a new target environment takes high effort bec dealt with using distinct features the protocol offers.</t>
ause the range of available options needs to be well understood and the selected <t>Defining a profile for a new target environment takes high effort bec
options need to be consistent with each other and suitably cover the intended a ause the range of available options needs to be well understood and the selected
pplication scenario. Since most industrial PKI management use cases typically h options need to be consistent with each other and suitably cover the intended a
ave much in common it is worth sharing this effort, which is the aim of this doc pplication scenario. Since most industrial PKI management use cases typically h
ument. Other standardization bodies can reference this document and further tai ave much in common, it is worth sharing this effort, which is the aim of this do
lor the PKI management operations to their needs to avoid coming up with individ cument. Other standardization bodies can reference this document and further ta
ual profiles from scratch.</t> ilor the PKI management operations to their needs to avoid coming up with indivi
dual profiles from scratch.</t>
</section> </section>
<section anchor="Lightweight_profile" numbered="true" toc="default"> <section anchor="Lightweight_profile" numbered="true" toc="default">
<name>Special Requirements of Industrial and IoT Scenarios</name> <name>Special Requirements of Industrial and IoT Scenarios</name>
<t>The profiles specified in <xref target="RFC4210" format="default">App <t>The profiles specified in Appendices <xref target="RFC4210" format="d
endix D and E of RFC&nbsp;4210</xref> have been developed particularly for manag efault" sectionFormat="bare" section="D"/> and <xref target="RFC4210" sectionFor
ing certificates of human end entities. With the evolution of distributed system mat="bare" section="E"/> of <xref target="RFC4210"/> have been developed particu
s and client-server architectures, certificates for machines and applications on larly for managing certificates of human end entities. With the evolution of dis
them have become widely used. This trend has strengthened even more in emerging tributed systems and client-server architectures, certificates for machines and
industrial and IoT scenarios. CMP is sufficiently flexible to support them well applications on them have become widely used. This trend has strengthened even m
.</t> ore in emerging industrial and IoT scenarios. CMP is sufficiently flexible to su
<t>Today's IT security architectures for industrial solutions typically pport them well.</t>
use certificates for endpoint authentication within protocols like IPsec, TLS, o <t>Today's IT security architectures for industrial solutions typically
r SSH. Therefore, the security of these architectures highly relies upon the sec use certificates for endpoint authentication within protocols like IPsec, TLS, o
urity and availability of the implemented certificate management operations.</t> r Secure Shell (SSH). Therefore, the security of these architectures highly reli
<t>Due to increasing security and availability needs in operational tech es upon the security and availability of the implemented certificate management
nology, especially when used for critical infrastructures and systems with a hig operations.</t>
h number of certificates, a state-of-the-art certificate management system must <t>Due to increasing security and availability needs in operational tech
be constantly available and cost-efficient, which calls for high automation and nology, especially when used for critical infrastructures and systems with a hig
reliability. Consequently, the <xref target="NIST.CSWP.04162018" format="defaul h number of certificates, a state-of-the-art certificate management system must
t">NIST Framework for Improving Critical Infrastructure Cybersecurity</xref> ref be constantly available and cost-efficient, which calls for high automation and
ers to proper processes for issuance, management, verification, revocation, and reliability. Consequently, <xref target="NIST.CSWP.04162018" format="default"> "
audit for authorized devices, users, and processes involving identity and creden Framework for Improving Critical Infrastructure Cybersecurity"</xref> refers to
tial management. Such PKI management operations according to commonly accepted b proper processes for issuance, management, verification, revocation, and audit o
est practices are also required in <xref target="IEC.62443-3-3" format="default" f authorized devices, users, and processes involving identity and credential man
>IEC&nbsp;62443-3-3</xref> for security level 2 and higher.</t> agement. According to commonly accepted best practices, such PKI management oper
<t>Further challenges in many industrial systems are network segmentatio ations are also required in <xref target="IEC.62443-3-3" format="default"/> for
n and asynchronous communication. Also, PKI management entities like Certificati security level 2 and higher.</t>
on Authorities (CA) typically are not deployed on-site but in a highly protected <t>Further challenges in many industrial systems are network segmentatio
data center environment, e.g., operated according to <xref target="ETSI-EN.3194 n and asynchronous communication. Also, PKI management entities like certificati
11-1" format="default">ETSI Policy and security requirements for Trust Service P on authorities (CAs) are not typically deployed on-site but in a highly protecte
roviders issuing certificates</xref>. Certificate management must be able to co d data center environment, e.g., operated according to <xref target="ETSI-EN.319
pe with such network architectures. CMP offers the required flexibility and func 411-1" format="default">ETSI Policy and security requirements for Trust Service
tionality, namely authenticated self-contained messages, efficient polling, and Providers issuing certificates</xref>. Certificate management must be able to c
support for asynchronous message transfer while retaining end-to-end authenticat ope with such network architectures. CMP offers the required flexibility and fun
ion.</t> ctionality, namely authenticated self-contained messages, efficient polling, and
support for asynchronous message transfer while retaining end-to-end authentica
tion.</t>
</section> </section>
<section anchor="Existing_profiles" numbered="true" toc="default"> <section anchor="Existing_profiles" numbered="true" toc="default">
<name>Existing CMP Profiles</name> <name>Existing CMP Profiles</name>
<t>As already stated, <xref target="RFC4210" format="default">RFC&nbsp;4 <t>As already stated, <xref target="RFC4210" format="default"/> contains
210</xref> contains profiles with mandatory and optional PKI management operatio profiles with mandatory and optional PKI management operations in Appendices <x
ns in Appendix D and E. Those profiles focus on management of human user certifi ref target="RFC4210" sectionFormat="bare" section="D"/> and <xref target="RFC421
cates and only partly address the specific needs of certificate management autom 0" sectionFormat="bare" section="E"/> of <xref target="RFC4210"/>. Those profile
ation for unattended devices or machine-to-machine application scenarios.</t> s focus on management of human user certificates and only partly address the spe
<t>Both Appendixes D and E focus on EE-to-RA/CA PKI management operation cific needs of certificate management automation for unattended devices or machi
s and do not address further profiling of RA-to-CA communication as typically ne ne-to-machine application scenarios.</t>
eded for full backend automation. All requirements regarding algorithm support <t>Both Appendices <xref target="RFC4210" sectionFormat="bare" section="
for <xref target="RFC4210" format="default">RFC&nbsp;4210 Appendix D and E</xref D"/> and <xref target="RFC4210" sectionFormat="bare" section="E"/> of <xref targ
> have been updated by <xref target="I-D.ietf-lamps-cmp-algorithms" format="defa et="RFC4210"/> focus on PKI management operations between an EE and an RA or CA.
ult">CMP Algorithms Section 7.1</xref>.</t> They do not address further profiling of RA-to-CA communication, which is typic
<t>3GPP makes use of <xref target="RFC4210" format="default">CMP</xref> ally needed for full backend automation. All requirements regarding algorithm s
in its <xref target="ETSI-3GPP.33.310" format="default">Technical Specification upport for Appendices <xref target="RFC4210" format="default" sectionFormat="bar
33.310</xref> for automatic management of IPsec certificates in 3G, LTE, and 5G e" section="D"/> and <xref target="RFC4210" sectionFormat="bare" section="E"/> o
backbone networks. Since 2010, a dedicated CMP profile for initial certificate e f <xref target="RFC4210"/> have been updated by <xref target="RFC9481" format="d
nrollment and certificate update operations between EE and RA/CA is specified in efault" sectionFormat="of" section="7.1">CMP Algorithms</xref>.</t>
that document.</t> <t>3GPP makes use of <xref target="RFC4210" format="default">CMP</xref>
<t>UNISIG has included a CMP profile for enrollment of TLS certificates in its <xref target="ETSI-3GPP.33.310" format="default">Technical Specification
in the Subset-137 specifying the <xref target="UNISIG.Subset-137" format="defaul 33.310</xref> for automatic management of IPsec certificates in 3G, LTE, and 5G
t">ETRAM/ETCS on-line key management for train control systems</xref> in 2015.</ backbone networks. Since 2010, a dedicated CMP profile for initial certificate e
t> nrollment and certificate update operations between EEs and RAs/CAs is specified
in that document.</t>
<t>In 2015, UNISIG included a CMP profile for enrollment of TLS certific
ates in the Subset-137 specifying the <xref target="UNISIG.Subset-137" format="d
efault">ETRAM/ETCS online key management for train control systems</xref>.</t>
<t>Both standardization bodies tailor <xref target="RFC4210" format="def ault">CMP</xref>, <xref target="RFC4211" format="default">CRMF</xref>, and <xref target="RFC6712" format="default">HTTP transfer for CMP</xref> for highly autom ated and reliable PKI management operations for unattended devices and services. </t> <t>Both standardization bodies tailor <xref target="RFC4210" format="def ault">CMP</xref>, <xref target="RFC4211" format="default">CRMF</xref>, and <xref target="RFC6712" format="default">HTTP transfer for CMP</xref> for highly autom ated and reliable PKI management operations for unattended devices and services. </t>
</section> </section>
<section anchor="Compatibility" numbered="true" toc="default"> <section anchor="Compatibility" numbered="true" toc="default">
<name>Compatibility with Existing CMP Profiles</name> <name>Compatibility with Existing CMP Profiles</name>
<t keepWithNext="true">The profile specified in this document is compati ble with <xref target="RFC4210" format="default">RFC&nbsp;4210 Appendixes D and E (PKI Management Message Profiles)</xref>, with the following exceptions:</t> <t keepWithNext="true">The profile specified in this document is compati ble with Appendices <xref target="RFC4210" format="default" sectionFormat="bare" section="D"/> and <xref target="RFC4210" format="default" sectionFormat="bare" section="E"/> of <xref target="RFC4210"/>, with the following exceptions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>signature-based protection is the default protection; an initial P KI management operation may also use MAC-based protection,</li> <li>signature-based protection is the default protection; an initial P KI management operation may also use protection based on the message authenticat ion code (MAC),</li>
<li>certification of a second key pair within the same PKI management operation is not supported,</li> <li>certification of a second key pair within the same PKI management operation is not supported,</li>
<li>proof-of-possession (POPO) with self-signature of the certTemplate according to <xref target="RFC4211" format="default">RFC&nbsp;4211 Section 4.1< /xref> clause 3 is the recommended default POPO method (deviations are possible for EEs when requesting central key generation, for RAs when using raVerified, a nd if the newly generated keypair is technically not capable to generate digital signatures),</li> <li>proof-of-possession (POP) with the self-signature of the certReq c ontaining the certTemplate (according to <xref target="RFC4211" format="default" sectionFormat="comma" section="4.1"/>, clause 3) is the recommended default POP method (deviations are possible for EEs when requesting central key generation, for RAs when using raVerified, and if the newly generated keypair is technicall y not capable to generate digital signatures),</li>
<li>confirmation of newly enrolled certificates may be omitted, and</l i> <li>confirmation of newly enrolled certificates may be omitted, and</l i>
<li>all PKI management operations consist of request-response message pairs originating at the EE, i.e., announcement messages (requiring a push model , a CMP server on the EE) are excluded in favor of a lightweight implementation on the EE.</li> <li>all PKI management operations consist of request-response message pairs originating at the EE, i.e., announcement messages (requiring a push model , a CMP server on the EE) are excluded in favor of a lightweight implementation on the EE.</li>
</ul> </ul>
<t keepWithNext="true">The profile specified in this document is compati ble with the CMP profile for 3G, LTE, and 5G network domain security and authent ication framework <xref target="ETSI-3GPP.33.310" format="default"/>, except tha t:</t> <t keepWithNext="true">The profile specified in this document is compati ble with the CMP profile for 3G, LTE, and 5G network domain security and authent ication framework <xref target="ETSI-3GPP.33.310" format="default"/>, except tha t:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>protection of initial PKI management operations may be MAC-based,< /li> <li>protection of initial PKI management operations may be MAC-based,< /li>
<li>the subject field is mandatory in certificate templates, and</li> <li>the subject field is mandatory in certificate templates, and</li>
<li>confirmation of newly enrolled certificates may be omitted.</li> <li>confirmation of newly enrolled certificates may be omitted.</li>
</ul> </ul>
<t keepWithNext="true">The profile specified in this document is compati ble with the CMP profile for on-line key management in rail networks as specifie d in <xref target="UNISIG.Subset-137" format="default">UNISIG Subset-137</xref>, except that:</t> <t keepWithNext="true">The profile specified in this document is compati ble with the CMP profile for online key management in rail networks as specified in <xref target="UNISIG.Subset-137" format="default"/>, except that:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>A certificate enrollment request message consists of only one cer tificate request (CertReqMsg).</li> <li>A certificate enrollment request message consists of only one cer tificate request (CertReqMsg).</li>
<li> <li>
<t><xref target="RFC4210" format="default">RFC&nbsp;4210< <t><xref target="RFC4210" format="default"/> requires tha
/xref> requires that the messageTime is Greenwich Mean Time coded as generalized t the messageTime is Greenwich Mean Time coded as generalizedTime.</t>
Time.</t> <t>Note: As Table 5 of <xref target="UNISIG.Subset-137" format="d
<t>Note: As <xref target="UNISIG.Subset-137" format="defa efault"/> explicitly states that the messageTime is required to be "UTC time", i
ult">UNISIG Subset-137 Table 5</xref> explicitly states that the messageTime in t is not clear if this means a coding as UTCTime or generalizedTime and if time
required to be "UTC time", it is not clear if this means a coding as UTCTime or zones other than Greenwich Mean Time shall be allowed. Both time formats are des
generalizedTime and if other time zones than Greenwich Mean Time shall be allowe cribed in <xref target="RFC5280" format="default" sectionFormat="of" section="4.
d. Both time formats are described in <xref target="RFC5280" format="default">RF 1.2.5"/>.</t>
C&nbsp;5280 Section 4.1.2.5</xref>.</t>
</li> </li>
<li>The same type of protection is required to be used for all message s of one PKI management operation. This means, in case the request message prote ction is MAC-based, also the response, certConf, and pkiConf messages must have a MAC-based protection.</li> <li>The same type of protection is required to be used for all message s of one PKI management operation. This means, in case the request message prote ction is MAC-based, the response, certConf, and pkiConf messages must also have MAC-based protection.</li>
<li> <li>
<t>Use of caPubs is not required but typically allowed in <t>Use of caPubs is not required but is typically allowed
combination with MAC-based protected PKI management operations. On the other h in combination with MAC-based protected PKI management operations. On the othe
and <xref target="UNISIG.Subset-137" format="default">UNISIG Subset-137 Table 12 r hand, Table 12 of <xref target="UNISIG.Subset-137" format="default"/> requires
</xref> requires using caPubs.</t> using caPubs.</t>
<t>Note: It remains unclear from UNISIG Subset-137 for wh <t>Note: It remains unclear from UNISIG Subset-137 which
ich certificate(s) the caPubs field should be used. For security reasons, it can certificate(s) for the caPubs field should be used. For security reasons, it can
not be used for delivering the root CA certificate needed for validating the sig not be used for delivering the root CA certificate needed to validate the signat
nature-based protection of the given response message (as stated indirectly also ure-based protection of the given response message (as stated indirectly also in
in its <xref target="UNISIG.Subset-137" format="default">UNISIG Subset-137 Sect Section 6.3.1.5.2 b of <xref target="UNISIG.Subset-137" format="default"/>).</t
ion 6.3.1.5.2 b</xref>).</t> >
</li> </li>
<li> <li>
<t>This profile requires that the certConf message has on <t>This profile requires that the certConf message have o
e CertStatus element where the statusInfo field is recommended.</t> ne CertStatus element where the statusInfo field is recommended.</t>
<t>Note: In contrast, <xref target="UNISIG.Subset-137" fo <t>Note: In contrast, Table 18 of <xref target="UNISIG.Su
rmat="default">UNISIG Subset-137 Table 18</xref> requires that the certConf mess bset-137" format="default"/> requires that the certConf message has one CertStat
age has one CertStatus element where the statusInfo field must be absent. This p us element where the statusInfo field must be absent. This precludes sending a n
recludes sending a negative certConf message in case the EE rejects the newly en egative certConf message in case the EE rejects the newly enrolled certificate.
rolled certificate. This results in violating the general rule that a certificat This results in violating the general rule that a certificate request transactio
e request transaction must include a certConf message (since moreover, using imp n must include a certConf message (moreover, since using implicitConfirm is not
licitConfirm is not allowed there, either).</t> allowed there either).</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="ZTO" numbered="true" toc="default"> <section anchor="ZTO" numbered="true" toc="default">
<name>Use of CMP in SZTP and BRSKI Environments</name> <name>Use of CMP in SZTP and BRSKI Environments</name>
<t>In <xref target="RFC8572" format="default">Secure Zero Touch P <t>In <xref target="RFC8572" format="default">Secure Zero Touch P
rovisioning (SZTP)</xref> and other environments using NETCONF/YANG modules, <xr rovisioning (SZTP)</xref> and other environments using Network Configuration Pro
ef target="I-D.ietf-netconf-sztp-csr" format="default">SZTP-CSR</xref> offers a tocol (NETCONF) / YANG modules, <xref target="I-D.ietf-netconf-sztp-csr" format=
YANG module that includes several types of certificate requests to obtain a publ "default"/> offers a YANG module that includes several types of certificate requ
ic-key certificate for a locally generated key pair. Such messages are of the f ests to obtain a public key certificate for a locally generated key pair. Such
orm ietf-ztp-types:cmp-csr from module ietf-ztp-csr and offer both proof-of-poss messages are of the form ietf-ztp-types:cmp-csr from module ietf-ztp-csr and off
ession and proof-of-identity. To allow PKI management entities that use the mod er both proof-of-possession and proof-of-identity. To allow PKI management enti
ule ietf-ztp-csr and also wish to comply with this profile, the ir, cr, kur, or ties that use the module ietf-ztp-csr and also wish to comply with this profile,
p10cr message MUST be formatted by the EE as described in <xref target="EE_reque the ir, cr, kur, or p10cr message <bcp14>MUST</bcp14> be formatted by the EE as
st" format="default"/>, and it MAY be forwarded as specified in <xref target="RA described in <xref target="EE_request" format="default"/>, and it <bcp14>MAY</b
_forwarde_messages" format="default"/>.</t> cp14> be forwarded, as specified in <xref target="RA_forwarde_messages" format="
<t>In <xref target="RFC8995" format="default">Bootstrapping Remot default"/>.</t>
e Secure Key Infrastructure (BRSKI)</xref> environments, <xref target="I-D.ietf- <t>In <xref target="RFC8995" format="default">Bootstrapping Remot
anima-brski-ae" format="default">BRSKI-AE: Alternative Enrollment Protocols in B e Secure Key Infrastructure (BRSKI)</xref> environments, <xref target="I-D.ietf-
RSKI</xref> describes a generalization regarding the employed enrollment protoco anima-brski-ae" format="default">"BRSKI-AE: Alternative Enrollment Protocols in
ls to allow alternatives to <xref target="RFC7030" format="default">EST</xref>. BRSKI"</xref> describes a generalization regarding the employed enrollment proto
For the use of CMP, it requires adherence to this profile.</t> cols to allow alternatives to <xref target="RFC7030" format="default">Enrollment
over Secure Transport (EST)</xref>. For the use of CMP, it requires adherence t
o this profile.</t>
</section> </section>
<section anchor="Scope" numbered="true" toc="default"> <section anchor="Scope" numbered="true" toc="default">
<name>Scope of this Document</name> <name>Scope of This Document</name>
<t>This profile on the one hand intends to reduce the flexibility <t>On one hand, this profile intends to reduce the flexibility of
of CMP to the generic needs of automated certificate management of machine end CMP to the generic needs of automated certificate management of machine end ent
entities. On the other hand, it offers a variety of PKI management operations a ities. On the other hand, it offers a variety of PKI management operations and
nd options relevant for industrial use cases. Therefore, it is still a framewor options relevant for industrial use cases. Therefore, it is still a framework t
k that supports further profiling by those addressing a specific use case or sce hat supports further profiling by those addressing a specific use case or scenar
nario, e.g., 3GPP/ETSI or UNISIG. There is room for further tailoring this prof io, e.g., 3GPP/ETSI or UNISIG. There is room to further tailor this profile. T
ile. This enables stricter profiling to the needs of concrete application areas his enables stricter profiling to meet the concrete needs in application areas.<
.</t> /t>
<t>To minimize ambiguity and complexity through needless variety, this d <t>To minimize ambiguity and complexity through needless variety, this d
ocument specifies exhaustive requirements for generating PKI management messages ocument specifies exhaustive requirements for generating PKI management messages
on the sender side. On the other hand, it gives only minimal requirements on c on the sender side. However, it gives only minimal requirements on checks by t
hecks by the receiving side and how to handle error cases.</t> he receiving side and how to handle error cases.</t>
<t>Especially on the EE side this profile aims at a lightweight implemen <t>Especially on the EE side, this profile aims at a lightweight impleme
tation. This means that the number of PKI management operations implementations ntation. This means that the number of PKI management operation implementations
are reduced to a reasonable minimum to support typical certificate management us are reduced to a reasonable minimum to support typical certificate management us
e cases in industrial machine-to-machine environments. On the EE side only limit e cases in industrial machine-to-machine environments. On the EE side, only limi
ed resources are expected, while on the side of the PKI management entities the ted resources are expected, while on the side of the PKI management entities, th
profile accepts higher requirements.</t> e profile accepts higher requirements.</t>
<t>For the sake of interoperability and robustness, implementations shou <t>For the sake of interoperability and robustness, implementations shou
ld, as far as security is not affected, adhere to Postel's law: "Be conservative ld, so long as security is not affected, adhere to Postel's law: "Be conservativ
in what you do, be liberal in what you accept from others" (often reworded as: e in what you do, be liberal in what you accept from others" (often reworded as:
"Be conservative in what you send, be liberal in what you receive").</t> "Be conservative in what you send, be liberal in what you receive").</t>
<t>Fields used in ASN.1 syntax in <xref target="GenericParts" format="de <t>Fields used in ASN.1 syntax in Sections <xref target="GenericParts" f
fault"/>, <xref target="EE_UseCases" format="default"/>, or <xref target="RA_Use ormat="counter"/>, <xref target="EE_UseCases" format="counter"/>, or <xref targe
Cases" format="default"/> are specified in <xref target="RFC4210" format="defaul t="RA_UseCases" format="counter"/> are specified in <xref target="RFC4210" forma
t">CMP</xref> <xref target="I-D.ietf-lamps-cmp-updates" format="default"/>, <xre t="default">CMP</xref> <xref target="RFC9480" format="default"/>, <xref target="
f target="RFC4211" format="default">CRMF</xref>, and <xref target="RFC5652" form RFC4211" format="default">CRMF</xref>, and <xref target="RFC5652" format="defaul
at="default">CMS</xref> <xref target="RFC8933" format="default"/>. When these se t">CMS</xref> <xref target="RFC8933" format="default"/>. When these sections do
ctions do not explicitly discuss a field, then the field SHOULD NOT be used by t not explicitly discuss a field, then the field <bcp14>SHOULD NOT</bcp14> be used
he sending entity. The receiving entity MUST NOT require the absence of such a f by the sending entity. The receiving entity <bcp14>MUST NOT</bcp14> require the
ield, and if the field is present, MUST handle it gracefully.</t> absence of such a field and, if the field is present, <bcp14>MUST</bcp14> handl
e it gracefully.</t>
</section> </section>
<section anchor="Structure" numbered="true" toc="default"> <section anchor="Structure" numbered="true" toc="default">
<name>Structure of this Document</name> <name>Structure of This Document</name>
<t><xref target="Architecture" format="default"/> introduces the general PKI architecture and approach to certificate management that is assumed in this document.</t> <t><xref target="Architecture" format="default"/> introduces the general PKI architecture and approach to certificate management that is assumed in this document.</t>
<t><xref target="GenericParts" format="default"/> profiles the generic a spects of the PKI management operations specified in detail in Sections <xref ta rget="EE_UseCases" format="counter"/> and <xref target="RA_UseCases" format="cou nter"/> to minimize redundancy in the description and to ease implementation. Th is covers the general structure and protection of messages, as well as generic p rerequisites, validation, and error handling.</t> <t><xref target="GenericParts" format="default"/> profiles the generic a spects of the PKI management operations specified in detail in Sections <xref ta rget="EE_UseCases" format="counter"/> and <xref target="RA_UseCases" format="cou nter"/> to minimize redundancy in the description and to ease implementation. Th is covers the general structure and protection of messages, as well as generic p rerequisites, validation, and error handling.</t>
<t><xref target="EE_UseCases" format="default"/> profiles the exchange o f CMP messages between an EE and the PKI management entity. There are various fl avors of certificate enrollment requests, optionally with polling, central key g eneration, revocation, and general support PKI management operations.</t> <t><xref target="EE_UseCases" format="default"/> profiles the exchange o f CMP messages between an EE and the PKI management entity. There are various fl avors of certificate enrollment requests, optionally with polling, central key g eneration, revocation, and general support PKI management operations.</t>
<t><xref target="RA_UseCases" format="default"/> profiles responding to requests, exchanges between PKI management entities, and operations on behalf of other PKI entities. This may include delayed delivery of messages, which invol ves polling for responses, and nesting of messages.</t> <t><xref target="RA_UseCases" format="default"/> profiles responding to requests, exchanges between PKI management entities, and operations on behalf of other PKI entities. This may include delayed delivery of messages, which invol ves polling for responses, and nesting of messages.</t>
<t><xref target="Transfer_types" format="default"/> outlines several mec hanisms for CMP message transfer, including HTTP-based transfer <xref target="RF C6712" format="default"/> optionally using TLS, and CoAP-based transfer <xref ta rget="I-D.ietf-ace-cmpv2-coap-transport" format="default"/> optionally using DTL S, and offline file-based transport.</t> <t><xref target="Transfer_types" format="default"/> outlines several mec hanisms for CMP message transfer, including HTTP-based transfer <xref target="RF C6712" format="default"/> optionally using TLS, CoAP-based transfer <xref target ="RFC9482" format="default"/> optionally using DTLS, and offline file-based tran sport.</t>
<t><xref target="Conformity" format="default"/> defines which par ts of the profile are mandatory, recommended, optional, or not relevant to imple ment for which type of entity.</t> <t><xref target="Conformity" format="default"/> defines which par ts of the profile are mandatory, recommended, optional, or not relevant to imple ment for which type of entity.</t>
</section> </section>
</section> </section>
<section anchor="Architecture" numbered="true" toc="default"> <section anchor="Architecture" numbered="true" toc="default">
<name>Solution Architecture</name> <name>Solution Architecture</name>
<t>To facilitate secure automatic certificate enrollment, the device hosti <t>To facilitate secure automatic certificate enrollment, the device hosti
ng an EE is typically equipped with a manufacturer-issued device certificate. S ng an EE is typically equipped with a manufacturer-issued device certificate. S
uch a certificate is typically installed during production and is meant to ident uch a certificate is typically installed during production and is meant to ident
ify the device throughout its lifetime. This certificate can be used to protect ify the device throughout its lifetime. This certificate can be used to protect
the initial enrollment of operational certificates after installation of the EE the initial enrollment of operational certificates after installation of the EE
in its operational environment. In contrast to the manufacturer-issued device in its operational environment. In contrast to the manufacturer-issued device
certificate, operational certificates are issued by the owner or operator of the certificate, operational certificates are issued by the owner or operator of the
device to identify the device or one of its components for operational use, e.g device to identify the device or one of its components for operational use, e.g
., in a security protocol like IPsec, TLS, or SSH. In <xref target="IEEE.802.1A ., in a security protocol like IPsec, TLS, or SSH. In <xref target="IEEE.802.1A
R_2018" format="default">IEEE&nbsp;802.1AR</xref> a manufacturer-issued device c R_2018" format="default">IEEE&nbsp;802.1AR</xref>, a manufacturer-issued device
ertificate is called IDevID certificate and an operational certificate is called certificate is called an Initial Device Identifier (IDevID) certificate and an o
LDevID certificate.</t> perational certificate is called a Locally Significant Device Identifier (LDevID
<t>Note: The owner or operator using the manufacturer-issued device certif ) certificate.</t>
icate for authenticating the device during initial enrollment of operational cer <t>Note: The owner or operator using the manufacturer-issued device certif
tificates MUST trust the respective trust anchor provided by the manufacturer.</ icate for authenticating the device during initial enrollment of operational cer
t> tificates <bcp14>MUST</bcp14> trust the respective trust anchor provided by the
<t>Note: According to <xref target="IEEE.802.1AR_2018" format="default">IE manufacturer.</t>
EE&nbsp;802.1AR</xref> a DevID comprises the triple of the certificate, the corr <t>Note: According to <xref target="IEEE.802.1AR_2018" format="default">I
esponding private key, and the certificate chain.</t> EEE&nbsp;802.1AR</xref>, a DevID comprises the triple of the certificate, the co
<t>All certificate management operations specified in this document fol rresponding private key, and the certificate chain.</t>
low the pull model, i.e., are initiated by an EE (or by an RA acting as an EE). <t>All certificate management operations specified in this document fol
The EE creates a CMP request message, protects it using some asymmetric credent low the pull model, i.e., they are initiated by an EE (or by an RA acting as an
ial or shared secret information and sends it to a PKI management entity. This EE). The EE creates a CMP request message, protects it using some asymmetric cr
PKI management entity may be a CA or more typically an RA, which checks the requ edential or shared secret information, and sends it to a PKI management entity.
est, responds to it itself, or forwards the request upstream to the next PKI man This PKI management entity may be a CA or more typically an RA, which checks th
agement entity. In case an RA changes the CMP request message header or body or e request and responds to it itself or forwards the request upstream to the next
wants to demonstrate successful verification or authorization, it can apply a p PKI management entity. In case an RA changes the CMP request message header or
rotection of its own. The communication between an LRA and RA can be performed body or wants to demonstrate successful verification or authorization, it can a
synchronously or asynchronously. Asynchronous communication typically leads to pply a protection of its own. The communication between an LRA and RA can be pe
delayed message delivery as described in <xref target="EE_Polling" format="defau rformed synchronously or asynchronously. Asynchronous communication typically l
lt"/>.</t> eads to delayed message delivery as described in <xref target="EE_Polling" forma
t="default"/>.</t>
<figure anchor="CertManUseCasesFigure"> <figure anchor="CertManUseCasesFigure">
<name>Certificate Management Architecture Example</name> <name>Certificate Management Architecture Example</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | | | | | |
| EE |<---------->| LRA |<-------------->| RA |<---------->| CA | | EE |<---------->| LRA |<-------------->| RA |<---------->| CA |
| | | | | | | | | | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
synchronous (a)synchronous (a)synchronous synchronous (a)synchronous (a)synchronous
+----connection----+------connection------+----connection----+ +----connection----+------connection------+----connection----+
operators service partner operators service partner
+---------on site---------+---back-end services--+---trust center--+ +---------on site---------+---back-end services--+---trust center--+
<--- downstream <--- | ---> upstream ---> <--- downstream <--- | ---> upstream --->
]]></artwork> ]]></artwork>
</figure> </figure>
<t>In operational environments the certificate management architecture can <t>In operational environments, the certificate management architecture ca
have multiple LRAs bundling requests from multiple EEs at dedicated locations a n have multiple LRAs bundling requests from multiple EEs at dedicated locations
nd one (or more than one) central RA aggregating the requests from the LRAs. Ev and one (or more than one) central RA aggregating the requests from the LRAs. E
ery LRA in this scenario has shared secret information (one per EE) for MAC-base very LRA in this scenario has shared secret information (one per EE) for MAC-bas
d protection or a CMP protection key and certificate allowing it to protect CMP ed protection or a CMP protection key and certificate, allowing it to protect CM
messages it processes using its own credentials. The figure above shows an arch P messages it processes using its own credentials. The figure above shows an ar
itectural example with one LRA, RA, and CA. It is also possible not to have an chitectural example with one LRA, RA, and CA. It is also possible not to have a
RA or LRA or that there is no CA with a CMP interface. Depending on the network n RA or LRA or that there is no CA with a CMP interface. Depending on the netwo
infrastructure, the message transfer between PKI management entities may be bas rk infrastructure, the message transfer between PKI management entities may be b
ed on synchronous online connections, asynchronous connections, or even offline ased on synchronous online connections, asynchronous connections, or even offlin
(e.g., file-based) transfer.</t> e (e.g., file-based) transfer.</t>
<t>Note: In contrast to the pull model used in this document, other specif <t>Note: In contrast to the pull model used in this document, other spe
ications could use the messages specified in this document implementing the push cifications could use the messages specified in this document to implement the p
model. In this case the EE is pushed (triggered) by the PKI management entity ush model. In this case, the EE is pushed (triggered) by the PKI management ent
to provide the CMP request, and therefore, EE acts as the receiver, not initiati ity to provide the CMP request; therefore, the EE acts as the receiver, not init
ng the interaction with the PKI. For example, when the device itself does only a iating the interaction with the PKI. For example, when the device itself only ac
ct as a server as described in <xref target="I-D.ietf-anima-brski-prm" format="d ts (as a server as described in <xref target="I-D.ietf-anima-brski-prm" format="
efault">BRSKI with Pledge in Responder Mode (BRSKI-PRM)</xref>, support of certi default">BRSKI with Pledge in Responder Mode</xref>), support of certificate enr
ficate enrollment in a push model is needed. While BRSKI-PRM currently utilizes ollment in a push model is needed. While BRSKI-PRM currently utilizes its own fo
its own format for the exchanges, CMP in general and the messages specified in t rmat for the exchanges, CMP in general and the messages specified in this profil
his profile offer all required capabilities. Nevertheless, the message flow and e offer all required capabilities. Nevertheless, the message flow and state mach
state machine as described in <xref target="EE_State_Machine" format="default"/> ine as described in <xref target="EE_State_Machine" format="default"/> must be a
must be adapted to implement a push model.</t> dapted to implement a push model.</t>
<t>Note: Third-party CAs, not conforming to this document, may implement o <t>Note: Third-party CAs not conforming to this document may implement oth
ther variants of CMP, different standardized protocols, or even proprietary inte er variants of CMP, different standardized protocols, or even proprietary interf
rfaces for certificate management. In such cases, an RA needs to adapt the exch aces for certificate management. In such cases, an RA needs to adapt the exchan
anged CMP messages to the flavor of certificate management interaction required ged CMP messages to the flavor of certificate management interaction required by
by such a non-conformant CA.</t> such a nonconformant CA.</t>
</section> </section>
<section anchor="GenericParts" numbered="true" toc="default"> <section anchor="GenericParts" numbered="true" toc="default">
<name>Generic Aspects of PKI Messages and PKI Management Operations</name> <name>Generic Aspects of PKI Messages and PKI Management Operations</name>
<t>This section covers the generic aspects of the PKI management operation s specified in Sections <xref target="EE_UseCases" format="counter"/> and <xref target="RA_UseCases" format="counter"/> as upfront general requirements to minim ize redundancy in the description and to ease implementation.</t> <t>This section covers the generic aspects of the PKI management operation s specified in Sections <xref target="EE_UseCases" format="counter"/> and <xref target="RA_UseCases" format="counter"/> as upfront general requirements to minim ize redundancy in the description and to ease implementation.</t>
<t keepWithNext="true">As described in <xref target="RFC4210" format="defa ult">Section 5.1 of RFC&nbsp;4210</xref>, all CMP messages have the following ge neral structure:</t> <t keepWithNext="true">As described in <xref target="RFC4210" format="defa ult" sectionFormat="of" section="5.1"/>, all CMP messages have the following gen eral structure:</t>
<figure anchor="CMP_messageStructure"> <figure anchor="CMP_messageStructure">
<name>CMP Message Structure</name> <name>CMP Message Structure</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+--------------------------------------------+ +--------------------------------------------+
| PKIMessage | | PKIMessage |
| +----------------------------------------+ | | +----------------------------------------+ |
| | header | | | | header | |
| +----------------------------------------+ | | +----------------------------------------+ |
| +----------------------------------------+ | | +----------------------------------------+ |
| | body | | | | body | |
skipping to change at line 305 skipping to change at line 259
| +----------------------------------------+ | | +----------------------------------------+ |
| +----------------------------------------+ | | +----------------------------------------+ |
| | extraCerts (OPTIONAL) | | | | extraCerts (OPTIONAL) | |
| +----------------------------------------+ | | +----------------------------------------+ |
+--------------------------------------------+ +--------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The general contents of the message header, protection, and extraCerts fields are specified in the following three subsections.</t> <t>The general contents of the message header, protection, and extraCerts fields are specified in the following three subsections.</t>
<t>In case a specific PKI management operation needs different contents in the header, protection, or extraCerts fields, the differences are described in the respective subsections of Sections <xref target="EE_UseCases" format="counte r"/> and <xref target="RA_UseCases" format="counter"/>.</t> <t>In case a specific PKI management operation needs different contents in the header, protection, or extraCerts fields, the differences are described in the respective subsections of Sections <xref target="EE_UseCases" format="counte r"/> and <xref target="RA_UseCases" format="counter"/>.</t>
<t>The CMP message body contains the PKI management operation-specific inf ormation. It is described in Sections <xref target="EE_UseCases" format="counter "/> and <xref target="RA_UseCases" format="counter"/>.</t> <t>The CMP message body contains the PKI management operation-specific inf ormation. It is described in Sections <xref target="EE_UseCases" format="counter "/> and <xref target="RA_UseCases" format="counter"/>.</t>
<t>Note: In the description of CMP messages, the presence of some fiel <t>Note: In the description of CMP messages, the presence of some fiel
ds is stated as OPTIONAL or RECOMMENDED. The following text that states require ds is stated as <bcp14>OPTIONAL</bcp14> or <bcp14>RECOMMENDED</bcp14>. The foll
ments on such a field applies only if the field is present.</t> owing text that states requirements on such a field applies only if the field is
<t>The generic prerequisites needed by the PKI entities in order to be abl present.</t>
e to perform PKI management operations are described in <xref target="Prereq" fo <t>The generic prerequisites needed by the PKI entities in order to per
rmat="default"/>.</t> form PKI management operations are described in <xref target="Prereq" format="de
<t>The generic validation steps to be performed by PKI entities on receivi fault"/>.</t>
ng a CMP message are described in <xref target="Validation" format="default"/>.< <t>The generic validation steps to be performed by PKI entities upon recei
/t> ving a CMP message are described in <xref target="Validation" format="default"/>
.</t>
<t>The generic aspects of handling and reporting errors are described in < xref target="Error" format="default"/>.</t> <t>The generic aspects of handling and reporting errors are described in < xref target="Error" format="default"/>.</t>
<section anchor="Header" numbered="true" toc="default"> <section anchor="Header" numbered="true" toc="default">
<name>General Description of the CMP Message Header</name> <name>General Description of the CMP Message Header</name>
<t>This section describes the generic header fields of all CMP messages. </t> <t>This section describes the generic header fields of all CMP messages. </t>
<t>Any PKI management operation-specific fields or variations are <t>Any fields or variations specific to PKI management operation are desc
described in Sections <xref target="EE_UseCases" format="counter"/> and <xref t ribed in Sections <xref target="EE_UseCases" format="counter"/> and <xref target
arget="RA_UseCases" format="counter"/>.</t> ="RA_UseCases" format="counter"/>.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
header header
pvno REQUIRED pvno REQUIRED
-- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData -- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData
-- is supported and expected to be used in the current -- is supported and expected to be used in the current
-- PKI management operation -- PKI management operation
-- MUST be 3 to indicate CMP v3 in certConf messages when using -- MUST be 3 to indicate CMP v3 in certConf messages when using
-- the hashAlg field -- the hashAlg field
-- MUST be 2 to indicate CMP v2 in all other cases -- MUST be 2 to indicate CMP v2 in all other cases
-- For details on version negotiation see RFCAAAA -- For details on version negotiation, see [RFC9480]
sender REQUIRED sender REQUIRED
-- Contains a name representing the originator which also -- Contains a name representing the originator, which also
-- protects the message -- protects the message
-- For signature-based protection MUST be the subject of the CMP -- For signature-based protection, MUST be the subject field of
-- protection certificate -- the CMP protection certificate
-- For MAC-based protection MUST be the subject name of the -- For MAC-based protection, MUST contain a name the PKI
-- certificate request, if available; otherwise, the NULL-DN -- management entity can use to identify the shared secret
-- (a zero-length SEQUENCE OF RelativeDistinguishedNames) MUST -- information. This name MUST be placed in the commonName
-- be used -- field of the directoryName choice.
-- In a multi-hop scenario, the receiving entity cannot rely -- In a multihop scenario, the receiving entity cannot rely
-- on the correctness of the sender field. -- on the correctness of the sender field.
recipient REQUIRED recipient REQUIRED
-- SHOULD be the name of the intended recipient; otherwise, the -- SHOULD be the name of the intended recipient; otherwise, the
-- NULL-DN MUST be used -- NULL-DN MUST be used
-- In the first message of a PKI management operation: SHOULD be -- In the first message of a PKI management operation, SHOULD be
-- the subject DN of the CA the PKI management operation is -- the subject DN of the CA the PKI management operation is
-- requested from -- requested from
-- In all other messages: SHOULD contain the value of the sender -- In all other messages, SHOULD contain the value of the sender
-- field of the previous message in the same PKI management -- field of the previous message in the same PKI management
-- operation -- operation
-- The recipient field shall be handled gracefully by the -- The recipient field shall be handled gracefully by the
-- receiving entity, because in a multi-hop scenario its -- receiving entity, because in a multihop scenario, its
-- correctness cannot be guaranteed. -- correctness cannot be guaranteed.
messageTime OPTIONAL messageTime OPTIONAL
-- MUST be present if the confirmWaitTime field is present -- MUST be present if the confirmWaitTime field is present
-- MUST be the time at which the message was produced, if present -- MUST be the time at which the message was produced, if present
-- MAY be set by a PKI management entity to provide the current -- MAY be set by a PKI management entity to provide the current
-- time -- time
-- MAY be used by the end entity for time synchronization if the -- MAY be used by the end entity for time synchronization if the
-- response was received within a short time frame -- response was received within a short time frame
protectionAlg REQUIRED protectionAlg REQUIRED
-- MUST be an algorithm identifier indicating the algorithm -- MUST be an algorithm identifier indicating the algorithm
-- used for calculating the protection bits -- used for calculating the protection bits
-- If it is a signature algorithm its type MUST be a -- If it is a signature algorithm, its type MUST be
-- MSG_SIG_ALG as specified in [RFCBBBB] Section 3 and -- MSG_SIG_ALG as specified in Section 3 of [RFC9481] and
-- MUST be consistent with the subjectPublicKeyInfo field of -- MUST be consistent with the subjectPublicKeyInfo field of
-- the CMP protection certificate -- the CMP protection certificate
-- If it is a MAC algorithm its type MUST be a MSG_MAC_ALG as -- If it is a MAC algorithm, its type MUST be MSG_MAC_ALG, as
-- specified in [RFCBBBB] Section 6.1 -- specified in [RFC9481], Section 6.1
senderKID RECOMMENDED senderKID RECOMMENDED
-- For signature-based protection MUST be used and contain the -- For signature-based protection, MUST be used and contain the
-- value of the SubjectKeyIdentifier if present in the CMP -- value of the SubjectKeyIdentifier if present in the CMP
-- protection certificate -- protection certificate
-- For MAC-based protection MUST be used and contain a name the -- For MAC-based protection, MUST be used and contain the same
-- PKI management entity can use to identify the shared secret -- name as in the commonName field of the sender field
-- information
transactionID REQUIRED transactionID REQUIRED
-- In the first message of a PKI management operation: MUST be -- In the first message of a PKI management operation, MUST be
-- 128 bits of random data, to minimize the probability of -- 128 bits of random data to minimize the probability of
-- having the transactionID already in use at the server -- having the transactionID already in use at the server
-- In all other messages: MUST be the value from the previous -- In all other messages, MUST be the value from the previous
-- message in the same PKI management operation -- message in the same PKI management operation
senderNonce REQUIRED senderNonce REQUIRED
-- MUST be cryptographically secure and fresh 128 random bits -- MUST be cryptographically secure and fresh 128 random bits
recipNonce RECOMMENDED recipNonce RECOMMENDED
-- If this is the first message of a transaction: MUST be absent -- If this is the first message of a transaction, MUST be absent
-- If this is a delayed response message: MUST be present and -- If this is a delayed response message, MUST be present and
-- contain the value of the senderNonce of the respective -- contain the value of the senderNonce of the respective
-- request message in the same transaction -- request message in the same transaction
-- In all other messages: MUST be present and contain the value -- In all other messages, MUST be present and contain the value
-- of the senderNonce of the previous message in the same -- of the senderNonce of the previous message in the same
-- transaction -- transaction
generalInfo OPTIONAL generalInfo OPTIONAL
implicitConfirm OPTIONAL implicitConfirm OPTIONAL
-- RECOMMENDED in ir/cr/kur/p10cr messages, -- RECOMMENDED in ir/cr/kur/p10cr messages,
-- OPTIONAL in ip/cp/kup response messages, and -- OPTIONAL in ip/cp/kup response messages, and
-- PROHIBITED in other types of messages -- PROHIBITED in other types of messages
-- Added to request messages to request omission of the certConf -- Added to request messages to request omission of the certConf
-- message -- message
-- Added to response messages to grant omission of the certConf -- Added to response messages to grant omission of the certConf
-- message -- message
-- See [RFC4210] Section 5.1.1.1. -- See [RFC4210], Section 5.1.1.1.
ImplicitConfirmValue REQUIRED ImplicitConfirmValue REQUIRED
-- ImplicitConfirmValue MUST be NULL -- ImplicitConfirmValue MUST be NULL
confirmWaitTime OPTIONAL confirmWaitTime OPTIONAL
-- RECOMMENDED in ip/cp/kup messages if implicitConfirm is -- RECOMMENDED in ip/cp/kup messages if implicitConfirm is
-- not included -- not included
-- PROHIBITED if implicitConfirm is included -- PROHIBITED if implicitConfirm is included
-- See [RFC4210] Section 5.1.1.2. -- See [RFC4210], Section 5.1.1.2.
ConfirmWaitTimeValue REQUIRED ConfirmWaitTimeValue REQUIRED
-- ConfirmWaitTimeValue MUST be a GeneralizedTime value -- ConfirmWaitTimeValue MUST be a GeneralizedTime value
-- specifying the point in time up to which the PKI management -- specifying the point in time up to which the PKI management
-- entity will wait for the certConf message. The accepted -- entity will wait for the certConf message. The accepted
-- length of the waiting period will vary by use case. -- length of the waiting period will vary by use case.
certProfile OPTIONAL certProfile OPTIONAL
-- MAY be present in ir/cr/kur/p10cr and in genm messages of type -- MAY be present in ir/cr/kur/p10cr and in genm messages of type
-- id-it-certReqTemplate -- id-it-certReqTemplate
-- MUST be omitted in all other messages -- MUST be omitted in all other messages
-- See [RFCAAAA] -- See [RFC9480].
CertProfileValue REQUIRED CertProfileValue REQUIRED
-- MUST contain a sequence of one UTF8String element -- MUST contain a sequence of one UTF8String element
-- MUST contain the name of a certificate profile -- MUST contain the name of a certificate profile
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="Protection" numbered="true" toc="default"> <section anchor="Protection" numbered="true" toc="default">
<name>General Description of the CMP Message Protection</name> <name>General Description of the CMP Message Protection</name>
<t>This section describes the generic protection field contents of all C <t>This section describes the generic protection field contents of all C
MP messages. For signature-based protection, which is the default protection me MP messages. For signature-based protection, which is the default protection me
chanism for all CMP messages described in this profile, the CMP protection key a chanism for all CMP messages described in this profile, the CMP protection key a
nd CMP protection certificate are used. For MAC-based protection shared secret i nd CMP protection certificate are used. For MAC-based protection, shared secret
nformation is used as described in <xref target="EE_MAC" format="default"/>.</t> information is used as described in <xref target="EE_MAC" format="default"/>.</t
<artwork align="left" name="" type="" alt=""><![CDATA[ >
<sourcecode type="pseudocode"><![CDATA[
protection protection
-- If present, the same kind of protection MUST be used for all -- If present, the same kind of protection MUST be used for all
-- messages of that PKI management operation. -- messages of that PKI management operation.
-- MUST be present, except if protection is not possible for -- MUST be present, except if protection is not possible for
-- error messages as described in Section 3.6.4. -- error messages as described in Section 3.6.4
-- For signature-based protection MUST contain the signature -- For signature-based protection, MUST contain the signature
-- calculated using the CMP protection key of the entity -- calculated using the CMP protection key of the entity
-- protecting the message. -- protecting the message
-- For MAC-based protection MUST contain a MAC calculated using -- For MAC-based protection, MUST contain a MAC calculated using
-- the shared secret information. -- the shared secret information
-- The protection algorithm used MUST be given in the -- The protection algorithm used MUST be given in the
-- protectionAlg field. -- protectionAlg field.
]]></artwork> ]]></sourcecode>
<t>The CMP message protection provides, if available, message origin aut hentication and integrity protection for the header and body. The CMP message ex traCerts field is not covered by this protection.</t> <t>The CMP message protection provides, if available, message origin aut hentication and integrity protection for the header and body. The CMP message ex traCerts field is not covered by this protection.</t>
<t>Note: The extended key usages described in <xref target="I-D.ietf-lam ps-cmp-updates" format="default">CMP Updates Section 2.2</xref> can be used for authorization of a sending PKI management entity.</t> <t>Note: The extended key usages described in <xref target="RFC9480" for mat="default" sectionFormat="of" section="2.2">CMP Updates</xref> can be used fo r authorization of a sending PKI management entity.</t>
</section> </section>
<section anchor="extraCerts" numbered="true" toc="default"> <section anchor="extraCerts" numbered="true" toc="default">
<name>General Description of CMP Message ExtraCerts</name> <name>General Description of CMP Message ExtraCerts</name>
<t>This section describes the generic extraCerts field of all CMP messag es. Any specific requirements on the extraCerts are specified in the respective PKI management operation.</t> <t>This section describes the generic extraCerts field of all CMP messag es. Any specific requirements on the extraCerts are specified in the respective PKI management operation.</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
extraCerts extraCerts
-- MUST be present for signature-based protection and contain the -- MUST be present for signature-based protection and contain the
-- CMP protection certificate together with its chain for the -- CMP protection certificate together with its chain for the
-- first request and response message of a PKI management -- first request and response message of a PKI management
-- operation. MAY be omitted in certConf, PKIConf, pollReq, and -- operation. MAY be omitted in certConf, PKIConf, pollReq,
-- pollRep messages. The first certificate in this field MUST -- and pollRep messages. The first certificate in this field
-- be the CMP protection certificate followed by its chain -- MUST be the CMP protection certificate followed by its
-- where each element should directly certify the one -- chain, where each element should directly certify the one
-- immediately preceding it. -- immediately preceding it.
-- MUST be present in ip, cp, and kup messages and contain the -- MUST be present in ip, cp, and kup messages and contain the
-- chain of a newly issued certificate. -- chain of a newly issued certificate.
-- Self-signed certificates should be omitted from extraCerts and -- Self-signed certificates should be omitted from extraCerts and
-- MUST NOT be trusted based on their inclusion in any case -- MUST NOT be trusted based on their inclusion in any case
]]></artwork> ]]></sourcecode>
<t>Note: One reason for adding a self-signed certificate to extraCerts i <t>Note: One reason for adding a self-signed certificate to extraCerts i
s if it is the CMP protection certificate or a successor root CA self-signed cer s if it is the CMP protection certificate or a successor root CA self-signed cer
tificate as indicated in the HashOfRootKey extension of the current root CA cert tificate as indicated in the HashOfRootKey extension of the current root CA cert
ificate, see <xref target="RFC8649" format="default"></xref>. Another reason for ificate; see <xref target="RFC8649" format="default"></xref>.
including self-signed certificates in the extraCerts is, for instance due to st Another reason
orage limitations, a receiving PKI entity may not have the complete trust anchor for including self-signed certificates in the extraCerts is, for
as self-signed certificate available but just unique identification of it, and instance, due to storage limitations. A receiving PKI entity may not
thus needs the full self-signed certificate for further processing (see also <xr have the complete trust anchor information available
ef target="Security" format="default"/>).</t> but just a unique identification of it and thus needs the full
<t>For maximum interoperability, all implementations SHOULD be pr trust anchor information carried in a self-signed certificate for further
epared to handle potentially additional certificates and arbitrary orderings of processing (see <xref target="Security" format="default"/>).</t>
the certificates.</t> <t>For maximum interoperability, all implementations <bcp14>SHOUL
D</bcp14> be prepared to handle potentially additional certificates and arbitrar
y orderings of the certificates.</t>
</section> </section>
<section anchor="Prereq" numbered="true" toc="default"> <section anchor="Prereq" numbered="true" toc="default">
<name>Generic PKI Management Operation Prerequisites</name> <name>Generic PKI Management Operation Prerequisites</name>
<t>This subsection describes what is generally needed by the PKI entitie s to be able to perform PKI management operations.</t> <t>This subsection describes what is generally needed by the PKI entitie s to be able to perform PKI management operations.</t>
<t keepWithNext="true">Identification of PKI entities:</t> <t keepWithNext="true">Identification of PKI entities:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>For signature-based protection each EE knows its own identity from the CMP protection certificate and for MAC-based protection it MAY know its ide ntity to fill the sender field.</li> <li>For signature-based protection, each EE knows its own identity fro m the CMP protection certificate; for MAC-based protection, it <bcp14>MAY</bcp14 > know its identity to fill the sender field.</li>
<li> <li>
<t>Each EE MAY know the intended recipient of its request <t>Each EE <bcp14>MAY</bcp14> know the intended recipient of its requ
s to fill the recipient field, e.g., the name of the addressed CA.</t> ests to fill the recipient field, e.g., the name of the addressed CA.</t>
<t>Note: This name may be established using an enrollment <t>Note: This name may be established using an enrollment
voucher, e.g., <xref target="RFC8366" format="default"></xref>, the issuer fiel voucher (as described in <xref target="RFC8366" format="default"></xref>), the
d from a CertReqTemplate response message content, or by other configuration mea issuer field from a CertReqTemplate response message content, or by other config
ns.</t> uration means.</t>
</li> </li>
</ul> </ul>
<t keepWithNext="true">Routing of CMP messages:</t> <t keepWithNext="true">Routing of CMP messages:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Each PKI entity sending messages upstream MUST know th <t>Each PKI entity sending messages upstream <bcp14>MUST<
e address needed for transferring messages to the next PKI management entity in /bcp14> know the address needed for transferring messages to the next PKI manage
case online-transfer is used.</t> ment entity in case online transfer is used.</t>
<t>Note: This address may depend on the recipient, the ce <t>Note: This address may depend on the recipient, the ce
rtificate profile, and on the used transfer mechanism.</t> rtificate profile, and the used transfer mechanism.</t>
</li> </li>
</ul> </ul>
<t keepWithNext="true">Authentication of PKI entities:</t> <t keepWithNext="true">Authentication of PKI entities:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Each PKI entity MUST have credentials to authenticate itself. For signature-based protection it MUST have a private key and the corresponding cert ificate along with its chain.</li> <li>Each PKI entity <bcp14>MUST</bcp14> have credentials to authentica te itself. For signature-based protection, it <bcp14>MUST</bcp14> have a private key and the corresponding certificate along with its chain.</li>
<li> <li>
<t>Each PKI entity MUST be able to establish trust in PKI <t>Each PKI entity <bcp14>MUST</bcp14> be able to establi
it receives responses from. When signature-based protection is used, it MUST ha sh trust in the PKI it receives responses from. When signature-based protection
ve the trust anchor(s) and any certificate status information needed to perform is used, it <bcp14>MUST</bcp14> have the trust anchor(s) and any certificate sta
path validation of CMP protection certificates used for signature-based protecti tus information needed to perform path validation of CMP protection certificates
on.</t> used for signature-based protection.</t>
<t>Note: A trust anchor usually is a root certificate of <t>Note: A trust anchor is usually a root certificate of
the PKI addressed by the requesting EE. It may be established by configuration o the PKI addressed by the requesting EE. It may be established by configuration o
r in an out-of-band manner. For an EE it may be established using an enrollment r in an out-of-band manner. For an EE, it may be established using an enrollmen
voucher <xref target="RFC8366" format="default"></xref> or in-band of CMP by th t voucher <xref target="RFC8366" format="default"></xref> or in-band of CMP by t
e caPubs field in a certificate response message.</t> he caPubs field in a certificate response message.</t>
</li> </li>
</ul> </ul>
<t keepWithNext="true">Authorization of PKI management operations:</t> <t keepWithNext="true">Authorization of PKI management operations:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Each EE or RA MUST have sufficient information to be a <t>Each EE or RA <bcp14>MUST</bcp14> have sufficient info
ble to authorize the PKI management entity for performing the upstream PKI manag rmation to be able to authorize the PKI management entity to perform the upstrea
ement operation.</t> m PKI management operation.</t>
<t>Note: This may be achieved for example by using the cm <t>Note: This may be achieved, for example, by using the
cRA extended key usage in server certificates, by local configuration such as sp cmcRA extended key usage in server certificates, by local configuration (such as
ecific name patterns for subject DN or SAN portions that may identify an RA, and specific name patterns for subject Distinguished Name (DN) or Subject Alternati
/or by having a dedicated root CA usable only for authenticating PKI management ve Name (SAN) portions that may identify an RA) and/or by having a dedicated roo
entities.</t> t CA usable only for authenticating PKI management entities.</t>
</li> </li>
<li> <li>
<t>Each PKI management entity MUST have sufficient inform <t>Each PKI management entity <bcp14>MUST</bcp14> have su
ation to be able to authorize the downstream PKI entity requesting the PKI manag fficient information to be able to authorize the downstream PKI entity requestin
ement operation.</t> g the PKI management operation.</t>
<t>Note: For authorizing an RA the same examples apply as <t>Note: For authorizing an RA, the same examples apply a
above. The authorization of EEs can be very specific to the application domain s above. The authorization of EEs can be very specific to the application domain
based on local PKI policy.</t> based on local PKI policy.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="Validation" numbered="true" toc="default"> <section anchor="Validation" numbered="true" toc="default">
<name>Generic Validation of a PKI Message</name> <name>Generic Validation of a PKI Message</name>
<t>This section describes generic validation steps of each PKI entity re <t>This section describes generic validation steps of each PKI entity re
ceiving a PKI request or response message before any further processing or forwa ceiving a PKI request or response message before any further processing or forwa
rding. If a PKI management entity decides to terminate a PKI management operati rding. If a PKI management entity decides to terminate a PKI management operati
on because a check failed, it MUST send a negative response or an error message on because a check failed, it <bcp14>MUST</bcp14> send a negative response or an
as described in <xref target="Error" format="default"/>. The PKIFailureInfo bits error message as described in <xref target="Error" format="default"/>. The PKIF
given below in parentheses MAY be used in the failInfo field of the PKIStatusIn ailureInfo bits given below in parentheses <bcp14>MAY</bcp14> be used in the fai
fo as described in <xref target="Error_reporting" format="default"/>, see also < lInfo field of the PKIStatusInfo as described in <xref target="Error_reporting"
xref target="RFC4210" format="default">RFC&nbsp;4210 Appendix F</xref>.</t> format="default"/>; also see <xref target="RFC4210" format="default" sectionForm
<t>All PKI message header fields not mentioned in this section like the at="of" section="F"/>.</t>
recipient and generalInfo fields SHOULD be handled gracefully on reception.</t> <t>All PKI message header fields not mentioned in this section, like the
<t keepWithNext="true">The following list describes the basic set of mes recipient and generalInfo fields, <bcp14>SHOULD</bcp14> be handled gracefully u
sage input validation steps. Without these checks the protocol becomes dysfuncti pon receipt.</t>
onal.</t> <t keepWithNext="true">The following list describes the basic set of mes
sage input validation steps. Without these checks, the protocol becomes dysfunct
ional.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The formal ASN.1 syntax of the whole message MUST be compliant wit <li>The formal ASN.1 syntax of the whole message <bcp14>MUST</bcp14> b
h the definitions given in <xref target="RFC4210" format="default">CMP</xref> an e compliant with the definitions given in <xref target="RFC4210" format="default
d <xref target="I-D.ietf-lamps-cmp-updates" format="default"/>, <xref target="RF ">CMP</xref> <xref target="RFC9480" format="default"/>, <xref target="RFC4211" f
C4211" format="default">CRMF</xref>, and <xref target="RFC5652" format="default" ormat="default">CRMF</xref>, and <xref target="RFC5652" format="default">CMS</xr
>CMS</xref> and <xref target="RFC8933" format="default"/>. (failInfo: badDataFor ef> <xref target="RFC8933" format="default"/>. (failInfo: badDataFormat)</li>
mat)</li> <li>The pvno <bcp14>MUST</bcp14> be cmp2000(2) or cmp2021(3). (failInf
<li>The pvno MUST be cmp2000(2) or cmp2021(3). (failInfo bit: unsuppor o bit: unsupportedVersion)</li>
tedVersion)</li> <li>The transactionID <bcp14>MUST</bcp14> be present. (failInfo bit: b
<li>The transactionID MUST be present. (failInfo bit: badDataFormat)</ adDataFormat)</li>
li> <li>The PKI message body type <bcp14>MUST</bcp14> be one of the messag
<li>The PKI message body type MUST be one of the message types support e types supported by the receiving PKI entity and <bcp14>MUST</bcp14> be allowed
ed by the receiving PKI entity and MUST be allowed in the current state of the P in the current state of the PKI management operation identified by the given tr
KI management operation identified by the given transactionID. (failInfo bit: ba ansactionID. (failInfo bit: badRequest)</li>
dRequest)</li>
</ul> </ul>
<t keepWithNext="true">The following list describes the set of message i nput validation steps required to ensure secure protocol operation:</t> <t keepWithNext="true">The following list describes the set of message i nput validation steps required to ensure secure protocol operation:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The senderNonce MUST be present and MUST contain at least 128 bits of data. (failInfo bit: badSenderNonce)</li> <li>The senderNonce <bcp14>MUST</bcp14> be present and <bcp14>MUST</bc p14> contain at least 128 bits of data. (failInfo bit: badSenderNonce)</li>
<li> <li>
<t>Unless the PKI message is the first message of a PKI management o peration,</t> <t>Unless the PKI message is the first message of a PKI management o peration,</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the recipNonce MUST be present and MUST equal the senderNonce of the previous message or equal the senderNonce of the most recent request mess age for which the response was delayed, in case of delayed delivery as specified in <xref target="EE_Polling" format="default"/>. (failInfo bit: badRecipientNon ce)</li> <li>the recipNonce <bcp14>MUST</bcp14> be present and <bcp14>MUST< /bcp14> equal the senderNonce of the previous message or equal the senderNonce o f the most recent request message for which the response was delayed, in case of delayed delivery as specified in <xref target="EE_Polling" format="default"/>. (failInfo bit: badRecipientNonce)</li>
</ul> </ul>
</li> </li>
<li>Messages without protection MUST be rejected except for err or messages as described in <xref target="Error_reporting" format="default"/>.</ li> <li>Messages without protection <bcp14>MUST</bcp14> be rejected except for error messages as described in <xref target="Error_reporting" format ="default"/>.</li>
<li> <li>
<t>The message protection MUST be validated when present and message s with an invalid protection MUST be rejected.</t> <t>The message protection <bcp14>MUST</bcp14> be validated when pres ent, and messages with an invalid protection <bcp14>MUST</bcp14> be rejected.</t >
<ul spacing="normal"> <ul spacing="normal">
<li>The protection MUST be signature-based except if MAC-based pro <li>The protection <bcp14>MUST</bcp14> be signature-based except i
tection is used as described in <xref target="EE_MAC" format="default"/> and <xr f MAC-based protection is used as described in Sections <xref target="EE_MAC" fo
ef target="EE_KGPB" format="default"/>. (failInfo bit: wrongIntegrity)</li> rmat="counter"/> and <xref target="EE_KGPB" format="counter"/>. (failInfo bit:
<li>If present, the senderKID MUST identify the key material neede wrongIntegrity)</li>
d for verifying the message protection. (failInfo bit: badMessageCheck)</li> <li>If present, the senderKID <bcp14>MUST</bcp14> identify the key
<li>If signature-based protection is used, the CMP protection cert material needed for verifying the message protection. (failInfo bit: badMessage
ificate MUST be successfully validated including path validation using a trust a Check)</li>
nchor and MUST be authorized according to local policies. If the keyUsage extens <li>If signature-based protection is used, the CMP protection cert
ion is present in the CMP protection certificate the digitalSignature bit MUST b ificate <bcp14>MUST</bcp14> be successfully validated, including path validation
e set. (failInfo bit: badAlg, badMessageCheck, or signerNotTrusted)</li> using a trust anchor, and <bcp14>MUST</bcp14> be authorized according to local
<li>The sender of a request message MUST be authorized policies. If the keyUsage extension is present in the CMP protection certificate
for requesting the operation according to PKI policies. (failInfo bit: notAuthor , the digitalSignature bit <bcp14>MUST</bcp14> be set. (failInfo bit: badAlg, ba
ized)</li> dMessageCheck, or signerNotTrusted)</li>
<li>The sender of a request message <bcp14>MUST</bcp14>
be authorized to request the operation according to PKI policies. (failInfo bit
: notAuthorized)</li>
</ul> </ul>
</li> </li>
<li></li>
</ul> </ul>
<t>Note: The requirements for checking certificates given in <xre f target="RFC5280" format="default">RFC&nbsp;5280</xref> MUST be followed for si gnature-based CMP message protection. Unless the message is a positive ip/cp/ku p where the issuing CA certificate of the newly enrolled certificate is the same as the CMP protection certificate of that message, certificate status checking SHOULD be performed on the CMP protection certificates. If the response message contains the caPubs field to transfer new trust anchor information, the CMP pro tection is crucial and certificate status checking is REQUIRED. For other cases it MAY be acceptable to omit certificate status checking when respective inform ation is not available.</t> <t>Note: The requirements for checking certificates given in <xre f target="RFC5280" format="default"/> <bcp14>MUST</bcp14> be followed for signat ure-based CMP message protection. Unless the message is a positive ip/cp/kup, w here the issuing CA certificate of the newly enrolled certificate is the same as the CMP protection certificate of that message, certificate status checking <bc p14>SHOULD</bcp14> be performed on the CMP protection certificates. If the resp onse message contains the caPubs field to transfer new trust anchor information, the CMP protection is crucial and certificate status checking is <bcp14>REQUIRE D</bcp14>. For other cases, it <bcp14>MAY</bcp14> be acceptable to omit certifi cate status checking when respective information is not available.</t>
<t keepWithNext="true">Depending on local policies, one or more of the i nput validation checks described below need to be implemented:</t> <t keepWithNext="true">Depending on local policies, one or more of the i nput validation checks described below need to be implemented:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If signature-based protection is used, the sender field MUST match the subject of the CMP protection certificate. (failInfo bit: badMessageCheck)< /li> <li>If signature-based protection is used, the sender field <bcp14>MUS T</bcp14> match the subject of the CMP protection certificate. (failInfo bit: ba dMessageCheck)</li>
<li> <li>
<t>If the messageTime is present and</t> <t>If the messageTime is present and</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the receiving system has a reliable system time, the messageTi <li>the receiving system has a reliable system time, the messageTi
me MUST be close to the current time of the receiving system, where the threshol me <bcp14>MUST</bcp14> be close to the current time of the receiving system, whe
d will vary by use case. (failInfo bit: badTime)</li> re the threshold will vary by use case. (failInfo bit: badTime)</li>
<li>the receiving system does not have a reliable system time, the <li>the receiving system does not have a reliable system time, the
messageTime MAY be used for time synchronization.</li> messageTime <bcp14>MAY</bcp14> be used for time synchronization.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="Error" numbered="true" toc="default"> <section anchor="Error" numbered="true" toc="default">
<name>Error Handling</name> <name>Error Handling</name>
<t>This section describes how a PKI entity handles error conditions on m essages it receives. Each error condition should be logged appropriately to allo w root-cause analysis of failure cases.</t> <t>This section describes how a PKI entity handles error conditions on m essages it receives. Each error condition should be logged appropriately to allo w root-cause analysis of failure cases.</t>
<section anchor="Error_upstream" numbered="true" toc="default"> <section anchor="Error_upstream" numbered="true" toc="default">
<name>Reporting Error Conditions Upstream</name> <name>Reporting Error Conditions Upstream</name>
<t>An EE SHALL NOT send error messages. PKI management entitie <t>An EE <bcp14>SHALL NOT</bcp14> send error messages. PKI man
s SHALL NOT send error messages in the upstream direction, either.</t> agement entities <bcp14>SHALL NOT</bcp14> send error messages in the upstream di
<t>In case an EE rejects a newly issued certificate contained i rection either.</t>
n an ip, cp, or kup message and implicit confirmation has not been granted, the <t>In case an EE rejects a newly issued certificate contained i
EE MUST report this using a certConf message with "rejection" status and await t n an ip, cp, or kup message and implicit confirmation has not been granted, the
he pkiConf response as described in <xref target="EE_newPKI" format="default"/>. EE <bcp14>MUST</bcp14> report this using a certConf message with "rejection" sta
</t> tus and await the pkiConf response as described in <xref target="EE_newPKI" form
<t>On all other error conditions regarding response messages, t at="default"/>.</t>
he EE or PKI management entity MUST regard the current PKI management operation <t>On all other error conditions regarding response messages, t
as terminated with failure. The error conditions include</t> he EE or PKI management entity <bcp14>MUST</bcp14> regard the current PKI manage
ment operation as terminated with failure. The error conditions include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>invalid response message header, body type, protection, or extra Certs according to the checks described in <xref target="Validation" format="def ault"/>,</li> <li>invalid response message header, body type, protection, or extra Certs, according to the checks described in <xref target="Validation" format="de fault"/>,</li>
<li>any issue detected with response message contents,</li> <li>any issue detected with response message contents,</li>
<li>receipt of an error message from upstream,</li> <li>receipt of an error message from upstream,</li>
<li>timeout occurred while waiting for a response,</li> <li>timeout occurred while waiting for a response, and</li>
<li>rejection of a newly issued certificate while implicit confirmat ion has been granted.</li> <li>rejection of a newly issued certificate while implicit confirmat ion has been granted.</li>
</ul> </ul>
<t>Upstream PKI management entities will not receive any CMP me ssage to learn that the PKI management operation has been terminated. In case t hey expect a further message from the EE, a connection interruption or timeout w ill occur. The value set for such timeouts will vary by use case. Then they als o MUST regard the current PKI management operation as terminated with failure an d MUST NOT attempt to send an error message downstream.</t> <t>Upstream PKI management entities will not receive any CMP me ssage to learn that the PKI management operation has been terminated. In case t hey expect a further message from the EE, a connection interruption or timeout w ill occur. The value set for such timeouts will vary by use case. Then they <bc p14>MUST</bcp14> also regard the current PKI management operation as terminated with failure and <bcp14>MUST NOT</bcp14> attempt to send an error message downst ream.</t>
</section> </section>
<section anchor="Error_downstream" numbered="true" toc="default"> <section anchor="Error_downstream" numbered="true" toc="default">
<name>Reporting Error Conditions Downstream</name> <name>Reporting Error Conditions Downstream</name>
<t>In case the PKI management entity detects an error condition <t>In case the PKI management entity detects an error condition
, e.g., rejecting the request due to policy decision, in the body of an ir, cr, , e.g., rejecting the request due to policy decision, in the body of an ir, cr,
p10cr, kur, or rr message received from downstream, it MUST report the error in p10cr, kur, or rr message received from downstream, it <bcp14>MUST</bcp14> repor
the specific response message, i.e., an ip, cp, kup, or rp with "rejection" stat t the error in the specific response message, i.e., an ip, cp, kup, or rp with "
us, as described in <xref target="EE_newPKI" format="default"/> and <xref target rejection" status, as described in Sections <xref target="EE_newPKI" format="cou
="EE_Revoke" format="default"/>. This can also happen in case of polling.</t> nter"/> and <xref target="EE_Revoke" format="counter"/>. This can also happen in
<t>In case the PKI management entity detects any other error co case of polling.</t>
ndition on requests, including pollReq, certConf, genm, and nested messages, rec <t>In case the PKI management entity detects any other error co
eived from downstream and on responses received from upstream, such as invalid m ndition on requests (including pollReq, certConf, genm, and nested messages) rec
essage header, body type, protection, or extraCerts according to the checks desc eived from downstream and on responses received from upstream (such as invalid m
ribed in <xref target="Validation" format="default"/> it MUST report them downst essage header, body type, protection, or extraCerts, according to the checks des
ream in the form of an error message as described in <xref target="Error_reporti cribed in <xref target="Validation" format="default"/>), it <bcp14>MUST</bcp14>
ng" format="default"/>.</t> report them downstream in the form of an error message as described in <xref tar
get="Error_reporting" format="default"/>.</t>
</section> </section>
<section anchor="Error_nested" numbered="true" toc="default"> <section anchor="Error_nested" numbered="true" toc="default">
<name>Handling Error Conditions on Nested Messages Used for Batching</ name> <name>Handling Error Conditions on Nested Messages Used for Batching</ name>
<t>Batching of messages using nested messages as described in < xref target="RA_AddBatch" format="default"/> requires special error handling.</t > <t>Batching of messages using nested messages as described in < xref target="RA_AddBatch" format="default"/> requires special error handling.</t >
<t>If the error condition is on an upstream nested message cont aining batched requests, it MUST NOT attempt to respond to the individual reques ts included in it, but to the nested message itself.</t> <t>If the error condition is on an upstream nested message cont aining batched requests, it <bcp14>MUST NOT</bcp14> attempt to respond to the in dividual requests included in it but to the nested message itself.</t>
<t>In case a PKI management entity receives an error message in response to a nested message, it must propagate the error by responding with an error message to each of the request messages contained in the nested message.< /t> <t>In case a PKI management entity receives an error message in response to a nested message, it must propagate the error by responding with an error message to each of the request messages contained in the nested message.< /t>
<t>In case a PKI management entity detects an error condition o n the downstream nested message received in response to a nested message sent be fore and the body of the received nested message still parses, it MAY ignore thi s error condition and handle the included responses as described in <xref target ="RA_AddBatch" format="default"/>. Otherwise, it MUST propagate the error by res ponding with an error message to each of the requests contained in the nested me ssage it sent originally.</t> <t>In case a PKI management entity detects an error condition o n the downstream nested message received in response to a nested message sent be fore and the body of the received nested message still parses, it <bcp14>MAY</bc p14> ignore this error condition and handle the included responses as described in <xref target="RA_AddBatch" format="default"/>. Otherwise, it <bcp14>MUST</bcp 14> propagate the error by responding with an error message to each of the reque sts contained in the nested message it sent originally.</t>
</section> </section>
<section anchor="Error_reporting" numbered="true" toc="default"> <section anchor="Error_reporting" numbered="true" toc="default">
<name>PKIStatusInfo and Error Messages</name> <name>PKIStatusInfo and Error Messages</name>
<t>When sending any kind of negative response, including error <t>When sending any kind of negative response, including error
messages, a PKI entity MUST indicate the error condition in the PKIStatusInfo st messages, a PKI entity <bcp14>MUST</bcp14> indicate the error condition in the P
ructure of the respective message as described below. It then MUST regard the c KIStatusInfo structure of the respective message as described below. Then it <b
urrent PKI management operation as terminated with failure.</t> cp14>MUST</bcp14> regard the current PKI management operation as terminated with
<t keepWithNext="true">The PKIStatusInfo structure is used to r failure.</t>
eport errors. It may be part of various message types, in particular: ip, cp, k <t keepWithNext="true">The PKIStatusInfo structure is used to r
up, certConf, and error. The PKIStatusInfo structure consists of the following f eport errors. It may be part of various message types, in particular, ip, cp, k
ields:</t> up, certConf, and error. The PKIStatusInfo structure consists of the following f
<ul spacing="normal"> ields:</t>
<li>status: Here the PKIStatus value "rejection" MUST be used in cas
e an error was detected. When a PKI management entity indicates delayed deliver <dl spacing="normal">
y of a CMP response message to the EE with an error message as described in <xre <dt>status:</dt>
f target="EE_Polling" format="default"/>, the status "waiting" MUST be used ther <dd>Here, the PKIStatus value "rejection" <bcp14>MUST</bcp14> be used
e.</li> in case an error was detected. When a PKI management entity indicates delayed
<li>statusString: Here any human-readable valid value for logging or delivery of a CMP response message to the EE with an error message as described
to display via a user interface should be added.</li> in <xref target="EE_Polling" format="default"/>, the status "waiting" <bcp14>MUS
<li> T</bcp14> be used there.</dd>
<t>failInfo: Here the PKIFailureInfo bits MAY be used in the way e <dt>statusString:</dt>
xplained in <xref target="RFC4210" format="default">Appendix F of RFC&nbsp;4210< <dd>Here, any human-readable valid value for logging or to display vi
/xref>. PKIFailureInfo bits regarding the validation described in <xref target= a a user interface should be added.</dd>
"Validation" format="default"/> are referenced there. The PKIFailureInfo bits re
ferenced in Sections <xref target="RA_response" format="counter"/> and <xref tar <dt>failInfo:</dt>
get="Transfer_types" format="counter"/> are described here:</t> <dd>
<ul spacing="normal"> <t>Here, the PKIFailureInfo bits <bcp14>MAY</bcp14> be used in the
<li>badCertId: A kur, certConf, or rr message references an unkn way explained in <xref target="RFC4210" format="default" sectionFormat="of" sect
own certificate</li> ion="F"/>. PKIFailureInfo bits regarding the validation described in <xref targ
<li>badPOP: An ir/cr/kur/p10cr contains an invalid proof-of-poss et="Validation" format="default"/> are referenced there. The PKIFailureInfo bits
ession</li> referenced in Sections <xref target="RA_response" format="counter"/> and <xref
<li>certRevoked: Revocation requested for a certificate already target="Transfer_types" format="counter"/> are described here:</t>
revoked</li>
<li>badCertTemplate: The contents of a certificate request are n <dl spacing="normal">
ot accepted, e.g., a field is missing or has a non-acceptable value or the given <dt>badCertId:</dt><dd>A kur, certConf, or rr message references
public key is already in use in some other certificate (depending on policy).</ an unknown certificate.</dd>
li> <dt>badPOP:</dt><dd>An ir/cr/kur/p10cr contains an invalid proof
<li>transactionIdInUse: This is sent by a PKI management entity -of-possession.</dd>
in case the received request contains a transactionID that is currently in use f <dt>certRevoked:</dt><dd>Revocation is requested for a certifica
or another transaction. An EE receiving such error message should resend the re te that is already revoked.</dd>
quest in a new transaction using a different transactionID.</li> <dt>badCertTemplate:</dt><dd>The contents of a certificate reque
<li>notAuthorized: The sender of a request messag st are not accepted, e.g., a field is missing or has an unacceptable value or th
e is not authorized for requesting the operation.</li> e given public key is already in use in some other certificate (depending on pol
<li>systemUnavail: This is sent by a PKI management entity in ca icy).</dd>
se a back-end system is not available.</li> <dt>transactionIdInUse:</dt><dd> This is sent by a PKI managemen
<li>systemFailure: This is sent by a PKI management entity in ca t entity in case the received request contains a transactionID that is currently
se a back-end system is currently not functioning correctly.</li> in use for another transaction. An EE receiving such an error message should r
</ul> esend the request in a new transaction using a different transactionID.</dd>
</li> <dt>notAuthorized:</dt><dd> The sender of a reque
</ul> st message is not authorized for requesting the operation.</dd>
<dt>systemUnavail:</dt><dd>This is sent by a PKI management enti
ty in case a back-end system is not available.</dd>
<dt>systemFailure:</dt><dd>This is sent by a PKI management enti
ty in case a back-end system is currently not functioning correctly.</dd>
</dl>
</dd>
</dl>
<t>An EE receiving a systemUnavail or systemFailure failInfo sh ould resend the request in a new transaction after some time.</t> <t>An EE receiving a systemUnavail or systemFailure failInfo sh ould resend the request in a new transaction after some time.</t>
<t keepWithNext="true">Detailed Message Description:</t> <t keepWithNext="true">Detailed Message Description:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
Error Message -- error Error Message -- error
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The message indicating the error that occurred -- The message indicating the error that occurred
error REQUIRED error REQUIRED
pKIStatusInfo REQUIRED pKIStatusInfo REQUIRED
status REQUIRED status REQUIRED
-- MUST have the value "rejection" -- MUST have the value "rejection"
statusString OPTIONAL statusString OPTIONAL
-- This field should contain any human-readable text for -- This field should contain any human-readable text for
-- debugging, logging or to display in a GUI -- debugging, for logging, or to display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MAY be present and contain the relevant PKIFailureInfo bits -- MAY be present and contain the relevant PKIFailureInfo bits
protection RECOMMENDED protection RECOMMENDED
-- As described in Section 3.2 -- As described in Section 3.2
extraCerts RECOMMENDED extraCerts RECOMMENDED
-- As described in Section 3.3 -- As described in Section 3.3
]]></artwork> ]]></sourcecode>
<t>Protecting the error message may not be technically fe <t>Protecting the error message may not be technically fe
asible if it is not clear which credential the recipient will be able to use whe asible if it is not clear which credential the recipient will be able to use whe
n validating this protection, e.g., in case the request message was fundamentall n validating this protection, e.g., in case the request message was fundamentall
y broken. In these exceptional cases the protection of the error message MAY be y broken. In these exceptional cases, the protection of the error message <bcp1
omitted.</t> 4>MAY</bcp14> be omitted.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="EE_UseCases" numbered="true" toc="default"> <section anchor="EE_UseCases" numbered="true" toc="default">
<name>PKI Management Operations</name> <name>PKI Management Operations</name>
<t>This chapter focuses on the communication of an EE with the PKI managem ent entity it directly talks to. Depending on the network and PKI solution, thi s can be an RA or directly a CA. Handling of a message by a PKI management entit y is described in <xref target="RA_UseCases" format="default"/>.</t> <t>This section focuses on the communication of an EE with the PKI managem ent entity it directly talks to. Depending on the network and PKI solution, thi s can be an RA or directly a CA. Handling of a message by a PKI management entit y is described in <xref target="RA_UseCases" format="default"/>.</t>
<t keepWithNext="true">The PKI management operations specified in this sec tion cover the following:</t> <t keepWithNext="true">The PKI management operations specified in this sec tion cover the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Requesting a certificate with variations like initial enrollment, ce <li>requesting a certificate with variations like initial enrollment, ce
rtificate updates, central key generation, and MAC-based protection</li> rtificate updates, central key generation, and MAC-based protection</li>
<li>Revoking a certificate</li> <li>revoking a certificate</li>
<li>Support messages</li> <li>support messages</li>
<li>Polling for delayed response messages</li> <li>polling for delayed response messages</li>
</ul> </ul>
<t>These operations mainly specify the message body of the CMP messages an <t>These operations mainly specify the message body of the CMP messages an
d utilize the specification of the message header, protection and extraCerts as d utilize the specification of the message header, protection, and extraCerts, a
specified in <xref target="GenericParts" format="default"/>. The messages are na s specified in <xref target="GenericParts" format="default"/>. The messages are
med by the respective field names in PKIBody like ir, ip, cr, cp, etc., see <xre named by the respective field names in PKIBody, like ir, ip, cr, cp, etc.; see <
f target="RFC4210" format="default">RFC&nbsp;4210 Section 5.1.2</xref>.</t> xref target="RFC4210" format="default" sectionFormat="of" section="5.1.2"/>.</t>
<t>The following diagram shows the EE state machine covering all PKI manag <t>The following diagram shows the EE state machine covering all PKI manag
ement operations described in this section, including negative responses, error ement operations described in this section, including negative responses, error
messages described in <xref target="Error_reporting" format="default"/>, as well messages described in <xref target="Error_reporting" format="default"/>, ip/cp/k
as ip/cp/kup/error messages with status "waiting", pollReq, and pollRep message up/error messages with status "waiting", and pollReq and pollRep messages as des
s as described in <xref target="EE_Polling" format="default"/>.</t> cribed in <xref target="EE_Polling" format="default"/>.</t>
<t>On receiving messages from upstream, the EE MUST perform the general <t>On receiving messages from upstream, the EE <bcp14>MUST</bcp14> perform
validation checks described in <xref target="Validation" format="default"/>. Th the general validation checks described in <xref target="Validation" format="de
e behavior in case an error occurs is described in <xref target="Error" format=" fault"/>. In case an error occurs, the behavior is described in <xref target="Er
default"/>.</t> ror" format="default"/>.</t>
<t keepWithNext="true">End Entity State Machine:</t>
<artwork anchor="EE_State_Machine" align="left" name="" type="" alt=""><![ CDATA[ <artwork anchor="EE_State_Machine" align="left" name="" type="" alt=""><![ CDATA[
End Entity State Machine:
start start
| |
| send ir/cr/kur/p10cr/rr/genm | send ir/cr/kur/p10cr/rr/genm
v v
waiting for response waiting for response
v v
+--------------------------+--------------------------+ +--------------------------+--------------------------+
| | | | | |
| receives ip/cp/kup with | received ip/cp/kup/error | received | receives ip/cp/kup with | received ip/cp/kup/error | received
| status "accepted" or | with status "waiting" | rp/genp or | status "accepted" or | with status "waiting" | rp/genp or
skipping to change at line 680 skipping to change at line 646
| | send certConf | | | | send certConf | |
| v | | | v | |
| waiting for pkiConf*) | | | waiting for pkiConf*) | |
| | | | | | | |
| | received | | | | received | |
| v pkiConf v | | v pkiConf v |
+---------------->+------->+<-------+<----------------+ +---------------->+------->+<-------+<----------------+
| |
v v
end end
]]></artwork>
*) In case of a delayed delivery of pkiConf responses the same <dl newline="false" spacing="normal">
polling mechanism is initiated as for rp or genp messages, by <dt>*)</dt>
sending an error message with status "waiting". <dd>In case of a delayed delivery of pkiConf responses, the same
]]></artwork> polling mechanism is initiated as for rp or genp messages by
<t>Note: All CMP messages belonging to the same PKI management operation M sending an error message with status "waiting".</dd>
UST have the same transactionID because the message receiver identifies the elem </dl>
ents of the operation in this way.</t> <t>Note: All CMP messages belonging to the same PKI management operation <
<t>This section is aligned with <xref target="RFC4210" format="default">CM bcp14>MUST</bcp14> have the same transactionID because the message receiver iden
P</xref>, <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates tifies the elements of the operation in this way.</t>
</xref>, and <xref target="I-D.ietf-lamps-cmp-algorithms" format="default">CMP A <t>This section is aligned with <xref target="RFC4210" format="default">CM
lgorithms</xref>.</t> P</xref>, <xref target="RFC9480" format="default">CMP Updates</xref>, and <xref
<t>Guidelines as well as an algorithm use profile for this document are av target="RFC9481" format="default">CMP Algorithms</xref>.</t>
ailable in <xref target="I-D.ietf-lamps-cmp-algorithms" format="default">CMP Alg <t>Guidelines as well as an algorithm use profile for this document are av
orithms</xref>.</t> ailable in <xref target="RFC9481" format="default">CMP Algorithms</xref>.</t>
<section anchor="EE_request" numbered="true" toc="default"> <section anchor="EE_request" numbered="true" toc="default">
<name>Enrolling End Entities</name> <name>Enrolling End Entities</name>
<t>There are various approaches for requesting a certificate from a PKI. </t> <t>There are various approaches for requesting a certificate from a PKI. </t>
<t keepWithNext="true">These approaches differ in the way the EE authent icates itself to the PKI, in the form of the request being used, and how the key pair to be certified is generated. The authentication mechanisms may be as foll ows:</t> <t keepWithNext="true">These approaches differ in the way the EE authent icates itself to the PKI, in the form of the request being used, and how the key pair to be certified is generated. The authentication mechanisms may be as foll ows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Using a certificate from an external PKI, e.g., a manufacturer-iss <li>using a certificate from an external PKI, e.g., a manufacturer-iss
ued device certificate, and the corresponding private key</li> ued device certificate, and the corresponding private key</li>
<li>Using a private key and certificate issued from the same PK <li>using a private key and certificate issued from the same PKI that i
I that is addressed for requesting a certificate</li> s addressed for requesting a certificate</li>
<li>Using the certificate to be updated and the corresponding private <li>using the certificate to be updated and the corresponding private
key</li> key</li>
<li>Using shared secret information known to the EE and the PKI manage <li>using shared secret information known to the EE and the PKI manage
ment entity</li> ment entity</li>
</ul> </ul>
<t>An EE requests a certificate indirectly or directly from a CA. When <t>An EE requests a certificate indirectly or directly from a CA. When
the PKI management entity handles the request as described in <xref target="RA_r the PKI management entity handles the request as described in <xref target="RA_r
esponse_enrollment" format="default"/> and responds with a message containing th esponse_enrollment" format="default"/> and responds with a message containing th
e requested certificate, the EE MUST reply with a confirmation message unless im e requested certificate, the EE <bcp14>MUST</bcp14> reply with a confirmation me
plicitConfirm was granted. The PKI management entity then MUST handle it as desc ssage unless implicitConfirm was granted. The PKI management entity <bcp14>MUST<
ribed in <xref target="RA_response_confirmation" format="default"/> and respond /bcp14> then handle it as described in <xref target="RA_response_confirmation"
with a confirmation, closing the PKI management operation.</t> format="default"/> and respond with a confirmation, closing the PKI management o
<t>The message sequences described in this section allow the EE to reque peration.</t>
st certification of a locally or centrally generated public-private key pair. Ty <t>The message sequences described in this section allow the EE to reque
pically, the EE provides a signature-based proof-of-possession of the private k st certification of a locally or centrally generated public-private key pair.
ey associated with the public key contained in the certificate request as define The public key and the subject name identifying the EE <bcp14>MUS
d by <xref target="RFC4211" format="default">RFC&nbsp;4211 Section 4.1</xref> ca T</bcp14> be present in the certTemplate of the certificate request message.</t>
se 3. To this end it is assumed that the private key can technically be used for <t>Note: If the EE does not know for which subject name to reques
signing. This is the case for the most common algorithms RSA, ECDSA, and EdDSA t the certificate, it can use the subject name from the CMP protection certifica
regardless of potentially intended restrictions of the key usage.</t> te in case of signature-based protection or the identifier of the shared secret
<t>Note: <xref target="RFC4211" format="default">RFC&nbsp;4211 Section 4 in case of MAC-based protection.</t>
</xref> allows for providing proof-of-possession using any method that a key can <t>Typically, the EE provides a signature-based proof-of-possess
be used for. In conformance with <xref target="NIST.SP.800-57p1r5" format="defa ion of the private key associated with the public key contained in the certifica
ult">NIST&nbsp;SP&nbsp;800-57 Part&nbsp;1 Section 8.1.5.1.1.2</xref> the newly g te request, as defined by <xref target="RFC4211" format="default" sectionFormat=
enerated private key may be used for self-signature, if technically possible, ev "comma" section="4.1"/>, clause 3. To this end, it is assumed that the private k
en if the keyUsage extension requested in the certificate request prohibits gene ey can technically be used for signing. This is the case for the most common al
ration of digital signatures.</t> gorithms RSA, ECDSA, and EdDSA, regardless of potentially intended restrictions
of the key usage.</t>
<t>Note: <xref target="RFC4211" format="default" sectionFormat="of" sect
ion="4"/> allows for providing proof-of-possession using any method that a key c
an be used for. In conformance with Section 8.1.5.1.1.2 of <xref target="NIST.SP
.800-57p1r5" format="default"/>, the newly generated private key may be used for
self-signature, if technically possible, even if the keyUsage extension request
ed in the certificate request prohibits generation of digital signatures.</t>
<t>The requesting EE provides the binding of the proof-of-possession to its identity by signature-based or MAC-based protection of the CMP request messa ge containing that POP. An upstream PKI management entity should verify whether this EE is authorized to obtain a certificate with the requested subject and oth er fields and extensions.</t> <t>The requesting EE provides the binding of the proof-of-possession to its identity by signature-based or MAC-based protection of the CMP request messa ge containing that POP. An upstream PKI management entity should verify whether this EE is authorized to obtain a certificate with the requested subject and oth er fields and extensions.</t>
<t>The EE MAY indicate the certificate profile to use in the cert <t>The proof-of-possession is provided by signing the certReq con
Profile extension of the generalInfo field in the PKIHeader of the certificate r taining the certTemplate with the subject name and public key. To bind this pro
equest message as described in <xref target="Header" format="default"/>.</t> of-of-possession to the proof-of-identity of the requesting EE, the subject name
<t>In case the EE receives a CA certificate in the caPubs field for inst in the certTemplate needs to identify the same entity as the subject name in th
allation as a new trust anchor, it MUST properly authenticate the message and au e CMP protection certificate or match the identifier used with MAC-based protect
thorize the sender as trusted source of the new trust anchor. This authorizatio ion.</t>
n is typically indicated using shared secret information for protecting an initi <t>Note: This binding may be lost if a PKI management entity repr
alization response (ir) message. Authorization can also be signature-based using otects this request message.</t>
a certificate issued by another PKI that is explicitly authorized for this purp <t>The EE <bcp14>MAY</bcp14> indicate the certificate profile to
ose. A certificate received in caPubs MUST NOT be accepted as a trust anchor if use in the certProfile extension of the generalInfo field in the PKIHeader of th
it is the root CA certificate of the certificate used for protecting the messag e certificate request message as described in <xref target="Header" format="defa
e.</t> ult"/>.</t>
<t>In case the EE receives a CA certificate in the caPubs field f
or installation as a new trust anchor, it <bcp14>MUST</bcp14> properly authentic
ate the message and authorize the sender as a trusted source of the new trust an
chor.
This authorization is typically indicated using shared secret inf
ormation for protecting an Initialization Response (ip) message. Authorization c
an also be signature-based, using a certificate issued by another PKI that is ex
plicitly authorized for this purpose. A certificate received in caPubs <bcp14>M
UST NOT</bcp14> be accepted as a trust anchor if it is the root CA certificate o
f the certificate used for protecting the message.</t>
<section anchor="EE_newPKI" numbered="true" toc="default"> <section anchor="EE_newPKI" numbered="true" toc="default">
<name>Enrolling an End Entity to a New PKI</name> <name>Enrolling an End Entity to a New PKI</name>
<t>This PKI management operation should be used by an EE to request a certificate from a new PKI using an existing certificate from an external PKI, e .g., a manufacturer-issued IDevID certificate <xref target="IEEE.802.1AR_2018" f ormat="default"/>, to authenticate itself to the new PKI.</t> <t>This PKI management operation should be used by an EE to request a certificate from a new PKI using an existing certificate from an external PKI, e .g., a manufacturer-issued IDevID certificate <xref target="IEEE.802.1AR_2018" f ormat="default"/>, to authenticate itself to the new PKI.</t>
<t>Note: In <xref target="RFC8995" format="default">Bootstrappi <t>Note: In <xref target="RFC8995" format="default">Bootstrappi
ng Remote Secure Key Infrastructure (BRSKI)</xref> environments, <xref target="I ng Remote Secure Key Infrastructure (BRSKI)</xref> environments, <xref target="I
-D.ietf-anima-brski-ae" format="default">BRSKI-AE: Alternative Enrollment Protoc -D.ietf-anima-brski-ae" format="default">"BRSKI-AE: Alternative Enrollment Proto
ols in BRSKI</xref> describes a generalization regarding enrollment protocols al cols in BRSKI"</xref> describes a generalization regarding enrollment protocols
ternative to <xref target="RFC7030" format="default">EST</xref>. As replacement alternative to <xref target="RFC7030" format="default">EST</xref>. As replaceme
of EST simpleenroll, BRSKI-AE uses this PKI management operation for bootstrapp nt of EST simpleenroll, BRSKI-AE uses this PKI management operation for bootstra
ing LDevID certificates.</t> pping LDevID certificates.</t>
<t keepWithNext="true">Specific prerequisites augmenting the prerequis <t keepWithNext="true">Specific prerequisites augmenting the prerequis
ites in <xref target="Prereq" format="default"/>:</t> ites in <xref target="Prereq" format="default"/> are as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The certificate of the EE MUST have been enrolled by an e <li>The certificate of the EE <bcp14>MUST</bcp14> have been e
xternal PKI, e.g., a manufacturer-issued device certificate.</li> nrolled by an external PKI, e.g., a manufacturer-issued device certificate.</li>
<li>The PKI management entity MUST have the trust anchor of the exte <li>The PKI management entity <bcp14>MUST</bcp14> have the trust anc
rnal PKI.</li> hor of the external PKI.</li>
<li>When using the generalInfo field certProfile, the EE MUST know t <li>When using the generalInfo field certProfile, the EE <bcp14>MUST
he identifier needed to indicate the requested certificate profile.</li> </bcp14> know the identifier needed to indicate the requested certificate profil
e.</li>
</ul> </ul>
<t keepWithNext="true">Message Flow:</t> <t keepWithNext="true">Message Flow:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
Step# EE PKI management entity Step# EE PKI management entity
1 format ir 1 format ir
2 -> ir -> 2 -> ir ->
3 handle or 3 handle or
forward ir forward ir
4 format or receive ip 4 format or receive ip
5 possibly grant 5 possibly grant
skipping to change at line 737 skipping to change at line 711
----------------- if implicitConfirm not granted ----------------- ----------------- if implicitConfirm not granted -----------------
8 format certConf 8 format certConf
9 -> certConf -> 9 -> certConf ->
10 handle or 10 handle or
forward certConf forward certConf
11 format or receive pkiConf 11 format or receive pkiConf
12 <- pkiConf <- 12 <- pkiConf <-
13 handle pkiConf 13 handle pkiConf
]]></artwork> ]]></artwork>
<t>For this PKI management operation, the EE MUST include a sequence o <t>For this PKI management operation, the EE <bcp14>MUST</bcp14> inclu
f one CertReqMsg in the ir. If more certificates are required, further requests de a sequence of one CertReqMsg in the ir. If more certificates are required, f
MUST be sent using separate PKI management operations.</t> urther requests <bcp14>MUST</bcp14> be sent using separate PKI management operat
<t>The EE MUST include the generalInfo field implicitConfirm in ions.</t>
the header of the ir message as described in <xref target="Header" format="defa <t>The EE <bcp14>MUST</bcp14> include the generalInfo field implicitCon
ult"/>, unless it requires certificate confirmation. This leaves the choice to firm in the header of the ir message as described in <xref target="Header" forma
the PKI management entities whether the EE must send a certConf message on recei t="default"/>, unless it requires certificate confirmation.
ving a new certificate. Depending on the PKI policy and requirements for managi This leaves the PKI management entities the choice of whether or not th
ng EE certificates, it can be important for PKI management entities to learn if e EE must send a certConf message upon receiving a new certificate. Depending o
the EE accepted the new certificate. In such cases, when responding with an ip n the PKI policy and requirements for managing EE certificates, it can be import
message, the PKI management entity MUST NOT include the implicitConfirm extensio ant for PKI management entities to learn if the EE accepted the new certificate.
n. In case the EE included the generalInfo field implicitConfirm in the request In such cases, when responding with an ip message, the PKI management entity <
message and the PKI management entity does not need any explicit confirmation f bcp14>MUST NOT</bcp14> include the implicitConfirm extension. In case the EE in
rom the EE, the PKI management entity MUST include the generalInfo field implici cluded the generalInfo field implicitConfirm in the request message and the PKI
tConfirm in the response message. This prevents explicit certificate confirmati management entity does not need any explicit confirmation from the EE, the PKI m
on and saves the overhead of a further message round-trip. Otherwise, the PKI m anagement entity <bcp14>MUST</bcp14> include the generalInfo field implicitConfi
anagement entity SHOULD include confirmWaitTime as described in <xref target="He rm in the response message. This prevents explicit certificate confirmation and
ader" format="default"/>.</t> saves the overhead of a further message round trip. Otherwise, the PKI managem
<t>If the EE did not request implicit confirmation or implicit confirm ent entity <bcp14>SHOULD</bcp14> include confirmWaitTime as described in <xref t
ation was not granted by the PKI management entity, certificate confirmation MUS arget="Header" format="default"/>.</t>
T be performed as follows. If the EE successfully received the certificate, it <t>If the EE did not request implicit confirmation or implicit confirm
MUST send a certConf message in due time. On receiving a valid certConf message, ation was not granted by the PKI management entity, certificate confirmation <bc
the PKI management entity MUST respond with a pkiConf message. If the PKI manag p14>MUST</bcp14> be performed as follows. If the EE successfully received the c
ement entity does not receive the expected certConf message in time it MUST hand ertificate, it <bcp14>MUST</bcp14> send a certConf message in due time. On recei
le this like a rejection by the EE. In case of rejection, depending on its poli ving a valid certConf message, the PKI management entity <bcp14>MUST</bcp14> res
cy the PKI management entity MAY revoke the newly issued certificate, notify a m pond with a pkiConf message. If the PKI management entity does not receive the e
onitoring system, or log the event internally.</t> xpected certConf message in time, it <bcp14>MUST</bcp14> handle this like a reje
<t>Note: Depending on PKI policy, a new certificate may be publ ction by the EE. In case of rejection, depending on its policy, the PKI managem
ished by a PKI management entity, and explicit confirmation may be required. In ent entity <bcp14>MAY</bcp14> revoke the newly issued certificate, notify a moni
this case it is advisable not to do the publication until a positive certificate toring system, or log the event internally.</t>
confirmation has been received. This way the need to revoke the certificate on <t>Note: Depending on PKI policy, a new certificate may be publ
negative confirmation can be avoided.</t> ished by a PKI management entity, and explicit confirmation may be required. In
<t>If the certificate request was rejected by the CA, the PKI manageme this case, it is advisable not to do the publication until a positive certificat
nt entity MUST return an ip message containing the status code "rejection" as de e confirmation has been received. This way, the need to revoke the certificate
scribed in <xref target="Error" format="default"/> and the certifiedKeyPair fiel on negative confirmation can be avoided.</t>
d SHALL be omitted. The EE MUST NOT react to such an ip message with a certConf <t>If the certificate request was rejected by the CA, the PKI manageme
message and the PKI management operation MUST be terminated.</t> nt entity <bcp14>MUST</bcp14> return an ip message containing the status code "r
ejection" as described in <xref target="Error" format="default"/>, and the certi
fiedKeyPair field <bcp14>SHALL</bcp14> be omitted. The EE <bcp14>MUST NOT</bcp1
4> react to such an ip message with a certConf message, and the PKI management o
peration <bcp14>MUST</bcp14> be terminated.</t>
<t keepWithNext="true">Detailed Message Description:</t> <t keepWithNext="true">Detailed Message Description:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
Initialization Request -- ir Initialization Request -- ir
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The request of the EE for a new certificate -- The request of the EE for a new certificate
ir REQUIRED ir REQUIRED
-- MUST contain a sequence of one CertReqMsg -- MUST contain a sequence of one CertReqMsg
-- If more certificates are required, further PKI management -- If more certificates are required, further PKI management
-- operations needs to be initiated -- operations needs to be initiated
certReq REQUIRED certReq REQUIRED
certReqId REQUIRED certReqId REQUIRED
-- MUST be 0 -- MUST be 0
certTemplate REQUIRED certTemplate REQUIRED
version OPTIONAL version OPTIONAL
-- MUST be 2 if supplied -- MUST be 2 if supplied
subject REQUIRED subject REQUIRED
-- The EE subject name MUST be carried in the subject field -- The EE's identity MUST be carried in the subject field
-- and/or the subjectAltName extension. -- and/or the subjectAltName extension.
-- If subject name is present only in the subjectAltName -- If subject name is present only in the subjectAltName
-- extension, then the subject field MUST be a NULL-DN -- extension, then the subject field MUST be NULL-DN
publicKey OPTIONAL publicKey OPTIONAL
-- MUST be present if local key generation is used -- MUST be present if local key generation is used
-- MAY be absent if central key generation is requested -- MAY be absent if central key generation is requested
algorithm OPTIONAL algorithm OPTIONAL
-- MUST be present if local key generation is used and MUST -- MUST be present if local key generation is used and MUST
-- include the subject public key algorithm identifier -- include the subject public key algorithm identifier
-- MAY be present if central key generation is requested and -- MAY be present if central key generation is requested and,
-- if present, informs the KGA of algorithm and parameter -- if present, informs the KGA of algorithm and parameter
-- preferences regarding the to-be-generated key pair -- preferences regarding the to-be-generated key pair
subjectPublicKey REQUIRED subjectPublicKey REQUIRED
-- MUST contain the public key to be certified in case of local -- MUST contain the public key to be certified in case of local
-- key generation -- key generation
-- MUST be a zero-length BIT STRING if central key generation -- MUST be a zero-length BIT STRING if central key generation
-- is requested -- is requested
extensions OPTIONAL extensions OPTIONAL
-- MAY include end-entity-specific X.509 extensions of the -- MAY include end-entity-specific X.509 extensions of the
-- requested certificate like subject alternative name, key -- requested certificate, like subject alternative name, key
-- usage, and extended key usage -- usage, and extended key usage
-- The subjectAltName extension MUST be present if the EE subject -- The subjectAltName extension MUST be present if the EE subject
-- name includes a subject alternative name. -- name includes a subject alternative name.
popo OPTIONAL popo OPTIONAL
-- MUST be present if local key generation is used -- MUST be present if local key generation is used
-- MUST be absent if central key generation is requested -- MUST be absent if central key generation is requested
signature OPTIONAL signature OPTIONAL
-- MUST be used by an EE if the key can be used for signing and -- MUST be used by an EE if the key can be used for signing, and
-- if used it MUST have the type POPOSigningKey -- if used, it MUST have the type POPOSigningKey
poposkInput PROHIBITED poposkInput PROHIBITED
-- MUST NOT be used; it is not needed because subject and -- MUST NOT be used; it is not needed because subject and
-- publicKey are both present in the certTemplate -- publicKey are both present in the certTemplate
algorithmIdentifier REQUIRED algorithmIdentifier REQUIRED
-- The signature algorithm MUST be consistent with the publicKey -- The signature algorithm MUST be consistent with the publicKey
-- algorithm field of the certTemplate -- algorithm field of the certTemplate
signature REQUIRED signature REQUIRED
-- MUST contain the signature value computed over the DER-encoded -- MUST contain the signature value computed over the DER-encoded
-- certTemplate -- certReq
raVerified OPTIONAL raVerified OPTIONAL
-- MAY be used by an RA after verifying the proof-of-possession -- MAY be used by an RA after verifying the proof-of-possession
-- provided by the EE -- provided by the EE
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
skipping to change at line 825 skipping to change at line 800
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The response of the CA to the request as appropriate -- The response of the CA to the request as appropriate
ip REQUIRED ip REQUIRED
caPubs OPTIONAL caPubs OPTIONAL
-- MAY be used if the certifiedKeyPair field is present -- MAY be used if the certifiedKeyPair field is present
-- If used it MUST contain only a trust anchor, e.g., root -- If used, it MUST contain only a trust anchor, e.g., root
-- certificate, of the certificate contained in certOrEncCert -- certificate, of the certificate contained in certOrEncCert
response REQUIRED response REQUIRED
-- MUST contain a sequence of one CertResponse -- MUST contain a sequence of one CertResponse
certReqId REQUIRED certReqId REQUIRED
-- MUST be 0 -- MUST be 0
status REQUIRED status REQUIRED
-- PKIStatusInfo structure MUST be present -- PKIStatusInfo structure MUST be present
status REQUIRED status REQUIRED
-- positive values allowed: "accepted", "grantedWithMods" -- positive values allowed: "accepted", "grantedWithMods"
-- negative values allowed: "rejection" -- negative values allowed: "rejection"
-- "waiting" only allowed with polling use case as described in -- "waiting" only allowed with a polling use case as described
-- Section 4.4 -- in Section 4.4
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging or to -- MAY be any human-readable text for debugging, for logging, or
-- display in a GUI -- to display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MAY be present if status is "rejection" -- MAY be present if status is "rejection"
-- MUST be absent if status is "accepted" or "grantedWithMods" -- MUST be absent if status is "accepted" or "grantedWithMods"
certifiedKeyPair OPTIONAL certifiedKeyPair OPTIONAL
-- MUST be present if status is "accepted" or "grantedWithMods" -- MUST be present if status is "accepted" or "grantedWithMods"
-- MUST be absent if status is "rejection" -- MUST be absent if status is "rejection"
certOrEncCert REQUIRED certOrEncCert REQUIRED
-- MUST be present if status is "accepted" or "grantedWithMods" -- MUST be present if status is "accepted" or "grantedWithMods"
certificate REQUIRED certificate REQUIRED
-- MUST be present when certifiedKeyPair is present -- MUST be present when certifiedKeyPair is present
-- MUST contain the newly enrolled X.509 certificate -- MUST contain the newly enrolled X.509 certificate
privateKey OPTIONAL privateKey OPTIONAL
-- MUST be absent in case of local key generation or "rejection" -- MUST be absent in case of local key generation or "rejection"
-- MUST contain the encrypted private key in an EnvelopedData -- MUST contain the encrypted private key in an EnvelopedData
-- structure as specified in Section 4.1.6 in case the private -- structure as specified in Section 4.1.6 in case the
-- key was generated centrally -- private key was generated centrally
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
-- MUST contain the chain of the certificate present in -- MUST contain the chain of the certificate present in
-- certOrEncCert -- certOrEncCert
-- Duplicate certificates MAY be omitted -- Duplicate certificates MAY be omitted
Certificate Confirmation -- certConf Certificate Confirmation -- certConf
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The message of the EE sends as confirmation to the PKI -- The message of the EE sends a confirmation to the PKI
-- management entity to accept or reject the issued -- management entity to accept or reject the issued
-- certificates -- certificates
certConf REQUIRED certConf REQUIRED
-- MUST contain a sequence of one CertStatus -- MUST contain a sequence of one CertStatus
CertStatus REQUIRED CertStatus REQUIRED
certHash REQUIRED certHash REQUIRED
-- MUST be the hash value of the certificate.
-- The hash algorithm to use MUST be the hash algorithm indicated -- The hash algorithm to use MUST be the hash algorithm indicated
-- in the below hashAlg field. If the hashAlg field is not -- in the below hashAlg field. If the hashAlg field is not
-- set, it MUST be the hash algorithm defined by the algorithm -- set, it MUST be the hash algorithm defined by the algorithm
-- identifier of the certificate signature or the dedicated -- identifier of the certificate signature or the dedicated
-- hash algorithm defined in RFCBBBB for the used certificate -- hash algorithm defined in [RFC9481] for the used certificate
-- signature algorithm. -- signature algorithm.
certReqId REQUIRED certReqId REQUIRED
-- MUST be 0 -- MUST be 0
statusInfo OPTIONAL statusInfo OPTIONAL
-- PKIStatusInfo structure should be present -- PKIStatusInfo structure should be present
-- Omission indicates acceptance of the indicated certificate -- Omission indicates acceptance of the indicated certificate
status REQUIRED status REQUIRED
-- positive values allowed: "accepted" -- positive values allowed: "accepted"
-- negative values allowed: "rejection" -- negative values allowed: "rejection"
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging, or to -- MAY be any human-readable text for debugging, for logging, or
-- display in a GUI -- to display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MAY be present if status is "rejection" -- MAY be present if status is "rejection"
-- MUST be absent if status is "accepted" -- MUST be absent if status is "accepted"
hashAlg OPTIONAL hashAlg OPTIONAL
-- The hash algorithm to use for calculating the above certHash -- The hash algorithm to use for calculating the above certHash
-- If used, the pvno field in the header MUST be cmp2021 (3). For -- If used, the pvno field in the header MUST be cmp2021 (3).
-- backward compatibility it is NOT RECOMMENDED to use this -- For backward compatibility, use of this field is
-- field, if the hash algorithm to use can be identified by -- NOT RECOMMENDED if the hash algorithm to use can be
-- other means, see above. -- identified by other means; see above.
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
-- MUST use the same credentials as in the first request message -- MUST use the same credentials as in the first request message
-- of this PKI management operation -- of this PKI management operation
extraCerts RECOMMENDED extraCerts RECOMMENDED
-- As described in Section 3.3 -- As described in Section 3.3
-- MAY be omitted if the message size is critical and the PKI -- MAY be omitted if the message size is critical and the PKI
-- management entity caches the CMP protection certificate from -- management entity caches the CMP protection certificate from
skipping to change at line 942 skipping to change at line 916
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
-- MUST use the same credentials as in the first response -- MUST use the same credentials as in the first response
-- message of this PKI management operation -- message of this PKI management operation
extraCerts RECOMMENDED extraCerts RECOMMENDED
-- As described in Section 3.3 -- As described in Section 3.3
-- MAY be omitted if the message size is critical and the EE has -- MAY be omitted if the message size is critical and the EE has
-- cached the CMP protection certificate from the first -- cached the CMP protection certificate from the first
-- response message of this PKI management operation -- response message of this PKI management operation
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="EE_trustedPKI" numbered="true" toc="default"> <section anchor="EE_trustedPKI" numbered="true" toc="default">
<name>Enrolling an End Entity to a Known PKI</name> <name>Enrolling an End Entity to a Known PKI</name>
<t>This PKI management operation should be used by an EE to request an additional certificate of the same PKI it already has certificates from. The E E uses one of these existing certificates to authenticate itself by signing its request messages using the respective private key.</t> <t>This PKI management operation should be used by an EE to request an additional certificate of the same PKI it already has certificates from. The E E uses one of these existing certificates to authenticate itself by signing its request messages using the respective private key.</t>
<t keepWithNext="true">Specific prerequisites augmenting the prerequis <t keepWithNext="true">Specific prerequisites augmenting the prerequis
ites in <xref target="Prereq" format="default"/>:</t> ites in <xref target="Prereq" format="default"/> are as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The certificate used by the EE MUST have been enrolled by <li>The certificate used by the EE <bcp14>MUST</bcp14> have been enro
the PKI it requests another certificate from.</li> lled by the PKI it requests another certificate from.</li>
<li>When using the generalInfo field certProfile, the EE MUST know t <li>When using the generalInfo field certProfile, the EE <bcp14>MUST
he identifier needed to indicate the requested certificate profile.</li> </bcp14> know the identifier needed to indicate the requested certificate profil
e.</li>
</ul> </ul>
<t keepWithNext="true">The message sequence for this PKI management op eration is identical to that given in <xref target="EE_newPKI" format="default"/ >, with the following changes:</t> <t keepWithNext="true">The message sequence for this PKI management op eration is identical to that given in <xref target="EE_newPKI" format="default"/ >, with the following changes:</t>
<ol spacing="normal" type="%d"> <ol spacing="normal" type="1">
<li> <li>
<t>The body of the first request and response SHOULD be <t>The body of the first request and response <bcp14>SHOULD</bcp14>
cr and cp. Otherwise ir and ip MUST be used.</t> be cr and cp. Otherwise, ir and ip <bcp14>MUST</bcp14> be used.</t>
<t>Note: Since the difference between ir/ip and cr/cp i <t>Note: Since the difference between ir/ip and cr/cp is syntactica
s syntactically not essential, an ir/ip may be used in this PKI management opera lly not essential, an ir/ip may be used in this PKI management operation.</t>
tion.</t> </li>
</li> <li>The caPubs field in the certificate response message <bcp14>MUST
<li>The caPubs field in the certificate response message MUST be abs </bcp14> be absent.</li>
ent.</li>
</ol> </ol>
</section> </section>
<section anchor="EE_Update" numbered="true" toc="default"> <section anchor="EE_Update" numbered="true" toc="default">
<name>Updating a Valid Certificate</name> <name>Updating a Valid Certificate</name>
<t>This PKI management operation should be used by an EE to request an update for one of its certificates that is still valid. The EE uses the certif icate it wishes to update as the CMP protection certificate. Both for authentica ting itself and for proving ownership of the certificate to be updated, it signs the request messages with the corresponding private key.</t> <t>This PKI management operation should be used by an EE to request an update for one of its certificates that is still valid. The EE uses the certif icate it wishes to update as the CMP protection certificate. Both for authentica ting itself and for proving ownership of the certificate to be updated, it signs the request messages with the corresponding private key.</t>
<t keepWithNext="true">Specific prerequisites augmenting the prerequis ites in <xref target="Prereq" format="default"/>:</t> <t keepWithNext="true">Specific prerequisites augmenting the prerequis ites in <xref target="Prereq" format="default"/> are as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The certificate the EE wishes to update MUST NOT be expir ed or revoked and MUST have been issued by the addressed CA.</li> <li>The certificate the EE wishes to update <bcp14>MUST NOT</ bcp14> be expired or revoked and <bcp14>MUST</bcp14> have been issued by the add ressed CA.</li>
<li>A new public-private key pair should be used.</li> <li>A new public-private key pair should be used.</li>
<li>When using the generalInfo field certProfile, the EE MUST know t he identifier needed to indicate the requested certificate profile.</li> <li>When using the generalInfo field certProfile, the EE <bcp14>MUST </bcp14> know the identifier needed to indicate the requested certificate profil e.</li>
</ul> </ul>
<t keepWithNext="true">The message sequence for this PKI management op eration is identical to that given in <xref target="EE_newPKI" format="default"/ >, with the following changes:</t> <t keepWithNext="true">The message sequence for this PKI management op eration is identical to that given in <xref target="EE_newPKI" format="default"/ >, with the following changes:</t>
<ol spacing="normal" type="%d"> <ol spacing="normal" type="1">
<li>The body of the first request and response MUST be kur an <li>The body of the first request and response <bcp14>MUST</b
d kup, respectively.</li> cp14> be kur and kup, respectively.</li>
<li>Protection of the kur MUST be performed using the certificate to <li>Protection of the kur <bcp14>MUST</bcp14> be performed using the
be updated.</li> certificate to be updated.</li>
<li>The subject field and/or the subjectAltName extension of the cer <li>The subject field and/or the subjectAltName extension of the cer
tTemplate MUST contain the EE subject name of the existing certificate to be upd tTemplate <bcp14>MUST</bcp14> contain the EE subject name of the existing certif
ated, without modifications.</li> icate to be updated, without modifications.</li>
<li>The certTemplate SHOULD contain the subject and/or subjectAltNam <li>The certTemplate <bcp14>SHOULD</bcp14> contain the subject and/o
e extension and publicKey of the EE only.</li> r subjectAltName extension and publicKey of the EE only.</li>
<li>The oldCertId control MAY be used to make clear which certificat <li>The oldCertId control <bcp14>MAY</bcp14> be used to make clear w
e is to be updated.</li> hich certificate is to be updated.</li>
<li>The caPubs field in the kup message MUST be absent.</li> <li>The caPubs field in the kup message <bcp14>MUST</bcp14> be absen
t.</li>
</ol> </ol>
<t keepWithNext="true">As part of the certReq structure of the kur the <t keepWithNext="true">As part of the certReq structure of the kur, th
oldCertId control is added after the certTemplate field.</t> e oldCertId control is added after the certTemplate field.</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
controls controls
type RECOMMENDED type RECOMMENDED
-- MUST be the value id-regCtrl-oldCertID, if present -- MUST be the value id-regCtrl-oldCertID, if present
value value
issuer REQUIRED issuer REQUIRED
serialNumber REQUIRED serialNumber REQUIRED
-- MUST contain the issuer and serialNumber of the certificate -- MUST contain the issuer and serialNumber of the certificate
-- to be updated -- to be updated
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="EE_P10" numbered="true" toc="default"> <section anchor="EE_P10" numbered="true" toc="default">
<name>Enrolling an End Entity Using a PKCS#10 Request</name> <name>Enrolling an End Entity Using a PKCS #10 Request</name>
<t>This PKI management operation can be used by an EE to reques <t>This PKI management operation can be used by an EE to reques
t a certificate using <xref target="RFC2986" format="default">PKCS#10</xref> for t a certificate using the <xref target="RFC2986" format="default">PKCS #10</xref
mat to interoperate with CAs not supporting <xref target="RFC4211" format="defau > format to interoperate with CAs not supporting <xref target="RFC4211" format="
lt">CRMF</xref>. This offers a variation of the PKI management operations specif default">CRMF</xref>. This offers a variation of the PKI management operations s
ied in Sections <xref target="EE_newPKI" format="counter"/> to <xref target="EE_ pecified in Sections <xref target="EE_newPKI" format="counter"/> to <xref target
Update" format="counter"/>.</t> ="EE_Update" format="counter"/>.</t>
<t>In this PKI management operation, the public key and all further ce <t>In this PKI management operation, the public key and all further ce
rtificate template data MUST be contained in the subjectPKInfo and other certifi rtificate template data <bcp14>MUST</bcp14> be contained in the subjectPKInfo an
cationRequestInfo fields of the PKCS#10 structure.</t> d other certificationRequestInfo fields of the PKCS #10 structure.</t>
<t>The prerequisites are the same as given in <xref target="EE_trusted PKI" format="default"/>.</t> <t>The prerequisites are the same as given in <xref target="EE_trusted PKI" format="default"/>.</t>
<t keepWithNext="true">The message sequence for this PKI management op eration is identical to that given in Sections <xref target="EE_newPKI" format=" counter"/> to <xref target="EE_Update" format="counter"/>, with the following ch anges:</t> <t keepWithNext="true">The message sequence for this PKI management op eration is identical to that given in Sections <xref target="EE_newPKI" format=" counter"/> to <xref target="EE_Update" format="counter"/>, with the following ch anges:</t>
<ol spacing="normal" type="%d"> <ol spacing="normal" type="1">
<li>The body of the first request and response MUST be p1 <li>The body of the first request and response <bcp14>MUS
0cr and cp, respectively.</li> T</bcp14> be p10cr and cp, respectively.</li>
<li>The certReqId in the cp message MUST be -1.</li> <li>The certReqId in the cp message <bcp14>MUST</bcp14> be -1.</li>
</ol> </ol>
<t keepWithNext="true">Detailed Message Description:</t> <t keepWithNext="true">Detailed Message Description:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
Certification Request -- p10cr Certification Request -- p10cr
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The request of the EE for a new certificate using a PKCS#10 -- The request of the EE for a new certificate using a PKCS #10
-- certificate request -- certificate request
p10cr REQUIRED p10cr REQUIRED
certificationRequestInfo REQUIRED certificationRequestInfo REQUIRED
version REQUIRED version REQUIRED
-- MUST be 0 to indicate PKCS#10 V1.7 -- MUST be 0 to indicate PKCS #10 v1.7
subject REQUIRED subject REQUIRED
-- The EE subject name MUST be carried in the subject field -- The EE subject name MUST be carried in the subject field
-- and/or the subjectAltName extension. -- and/or the subjectAltName extension.
-- If subject name is present only in the subjectAltName -- If subject name is present only in the subjectAltName
-- extension, then the subject field MUST be a NULL-DN -- extension, then the subject field MUST be NULL-DN
subjectPKInfo REQUIRED subjectPKInfo REQUIRED
algorithm REQUIRED algorithm REQUIRED
-- MUST include the subject public key algorithm identifier -- MUST include the subject public key algorithm identifier
subjectPublicKey REQUIRED subjectPublicKey REQUIRED
-- MUST include the public key to be certified -- MUST include the public key to be certified
attributes OPTIONAL attributes OPTIONAL
-- MAY include end-entity-specific X.509 extensions of the -- MAY include end-entity-specific X.509 extensions of the
-- requested certificate like subject alternative name, -- requested certificate like subject alternative name,
-- key usage, and extended key usage -- key usage, and extended key usage
-- The subjectAltName extension MUST be present if the EE -- The subjectAltName extension MUST be present if the EE
skipping to change at line 1044 skipping to change at line 1019
-- The signature algorithm MUST be consistent with the -- The signature algorithm MUST be consistent with the
-- subjectPKInfo field. -- subjectPKInfo field.
signature REQUIRED signature REQUIRED
-- MUST contain the self-signature for proof-of-possession -- MUST contain the self-signature for proof-of-possession
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described for the underlying PKI management operation -- As described for the underlying PKI management operation
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="EE_MAC" numbered="true" toc="default"> <section anchor="EE_MAC" numbered="true" toc="default">
<name>Using MAC-Based Protection for Enrollment</name> <name>Using MAC-Based Protection for Enrollment</name>
<t>This is a variant of the PKI management operations described <t>This is a variant of the PKI management operations described
in Sections <xref target="EE_newPKI" format="counter"/>, <xref target="EE_trust in Sections <xref target="EE_newPKI" format="counter"/>, <xref target="EE_trust
edPKI" format="counter"/> and <xref target="EE_P10" format="counter"/>. It shou edPKI" format="counter"/>, and <xref target="EE_P10" format="counter"/>. It sho
ld be used by an EE to request a certificate of a new PKI in case it does not ha uld be used by an EE to request a certificate of a new PKI in case it does not h
ve a certificate to prove its identity to the target PKI, but has some secret in ave a certificate to prove its identity to the target PKI but has some secret in
formation shared with the PKI management entity. Therefore, the request and res formation shared with the PKI management entity. Therefore, the request and res
ponse messages are MAC-protected using this shared secret information. The dist ponse messages are MAC-protected using this shared secret information. The dist
ribution of this shared secret is out of scope for this document. The PKI manage ribution of this shared secret is out of scope for this document. The PKI manage
ment entity checking the MAC-based protection MUST replace this protection accor ment entity checking the MAC-based protection <bcp14>MUST</bcp14> replace this p
ding to <xref target="RA_Replace" format="default"/> as the next hop may not kno rotection according to <xref target="RA_Replace" format="default"/>, as the next
w the shared secret information.</t> hop may not know the shared secret information.</t>
<t>Note: The entropy of the shared secret information is crucia <t>Note: The entropy of the shared secret information is crucia
l for the level of protection when using MAC-based protection. Further guidance l for the level of protection when using MAC-based protection. Further guidance
is available in the security considerations of CMP updated by <xref target="I-D is available in the security considerations updated by <xref target="RFC9480" f
.ietf-lamps-cmp-updates" format="default"/>.</t> ormat="default">CMP Updates</xref>.</t>
<t keepWithNext="true">Specific prerequisites augmenting the prerequis <t keepWithNext="true">Specific prerequisites augmenting the prerequis
ites in <xref target="Prereq" format="default"/>:</t> ites in <xref target="Prereq" format="default"/> are as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Rather than using private keys, certificates, and tr <t>Rather than using private keys, certificates, and tr
ust anchors, the EE and the PKI management entity MUST share secret information. ust anchors, the EE and the PKI management entity <bcp14>MUST</bcp14> share secr
</t> et information.</t>
<t>Note: The shared secret information MUST be establis <t>Note: The shared secret information <bcp14>MUST</bcp
hed out-of-band, e.g., by a service technician during initial local configuratio 14> be established out of band, e.g., by a service technician during initial loc
n.</t> al configuration.</t>
</li> </li>
<li>When using the generalInfo field certProfile, the EE MUST know t he identifier needed to indicate the requested certificate profile.</li> <li>When using the generalInfo field certProfile, the EE <bcp14>MUST </bcp14> know the identifier needed to indicate the requested certificate profil e.</li>
</ul> </ul>
<t keepWithNext="true">The message sequence for this PKI management op <t keepWithNext="true">The message sequence for this PKI management op
eration is identical to that given in Sections <xref target="EE_newPKI" format=" eration is identical to that given in Sections <xref target="EE_newPKI" format="
counter"/>, <xref target="EE_trustedPKI" format="counter"/> and <xref target="EE counter"/>, <xref target="EE_trustedPKI" format="counter"/>, and <xref target="E
_P10" format="counter"/>, with the following changes:</t> E_P10" format="counter"/>, with the following changes:</t>
<ol spacing="normal" type="%d"> <ol spacing="normal" type="1">
<li>The protection of all messages MUST be MAC-based. Therefo <li>The protection of all messages <bcp14>MUST</bcp14> be MAC
re, extraCerts fields of all messages do not contain CMP protection certificates -based. Therefore, extraCerts fields of all messages do not contain CMP protecti
and associated chains.</li> on certificates and associated chains.</li>
<li>In case the sending entity does not know its own name by now, it <li>The sender field <bcp14>MUST</bcp14> contain a name the PKI mana
MUST put the NULL-DN into the sender field. The senderKID MUST contain a refere gement entity can use to identify the shared secret information used for message
nce the recipient can use to identify the shared secret information used for the protection. This name <bcp14>MUST</bcp14> be placed in the commonName field of
protection, e.g., the username of the EE.</li> the directoryName choice. The senderKID <bcp14>MUST</bcp14> contain the same nam
e as in the commonName field of the sender field. In case the sending entity doe
s not yet know for which name to request the certificate, it can use this common
Name in the subject field of the certTemplate.</li>
</ol> </ol>
<t>See <xref target="Transfer_types" format="default"/> of <xref targe t="I-D.ietf-lamps-cmp-algorithms" format="default"> CMP Algorithms</xref> for de tails on message authentication code algorithms (MSG_MAC_ALG) to use. Typically, parameters are part of the protectionAlg field, e.g., used for key derivation, like a salt and an iteration count. Such parameters should remain constant for message protection throughout this PKI management operation to reduce the comput ational overhead.</t> <t>See <xref target="RFC9481" format="default" sectionFormat="of" sect ion="6">CMP Algorithms</xref> for details on message authentication code algorit hms (MSG_MAC_ALG) to use. Typically, parameters are part of the protectionAlg fi eld, e.g., used for key derivation, like a salt and an iteration count. Such pa rameters should remain constant for message protection throughout this PKI manag ement operation to reduce the computational overhead.</t>
</section> </section>
<section anchor="EE_centralKeyGeneration" numbered="true" toc="default"> <section anchor="EE_centralKeyGeneration" numbered="true" toc="default">
<name>Adding Central Key Pair Generation to Enrollment</name> <name>Adding Central Key Pair Generation to Enrollment</name>
<t>This is a variant of the PKI management operations described in <xr ef target="EE_newPKI" format="default"/> to <xref target="EE_P10" format="defaul t"/> and the variant described in <xref target="EE_MAC" format="default"/>. It n eeds to be used in case an EE is not able to generate its new public-private key pair itself or central generation of the EE key material is preferred. It is a matter of the local implementation which PKI management entity will act as Key Generation Authority (KGA) and performs the key generation. This PKI management entity MUST use a certificate containing the additional extended key usage exte nsion id-kp-cmKGA in order to be accepted by the EE as a legitimate key generati on authority.</t> <t>This is a variant of the PKI management operations described in Sec tions <xref target="EE_newPKI" format="counter"/> to <xref target="EE_P10" forma t="counter"/> and the variant described in <xref target="EE_MAC" format="default "/>. It needs to be used in case an EE is not able to generate its new public-pr ivate key pair itself or central generation of the EE key material is preferred. Which PKI management entity will act as Key Generation Authority (KGA) and perf orm the key generation is a matter of the local implementation. This PKI manage ment entity <bcp14>MUST</bcp14> use a certificate containing the additional exte nded key usage extension id-kp-cmKGA in order to be accepted by the EE as a legi timate key generation authority.</t>
<t>Note: As described in <xref target="RA_on-behalf_request" fo rmat="default"/>, the KGA can use the PKI management operation described in <xre f target="EE_trustedPKI" format="default"/> to request the certificate for this key pair on behalf of the EE.</t> <t>Note: As described in <xref target="RA_on-behalf_request" fo rmat="default"/>, the KGA can use the PKI management operation described in <xre f target="EE_trustedPKI" format="default"/> to request the certificate for this key pair on behalf of the EE.</t>
<t>When an EE requests central key generation for a certificate update using a kur message, the KGA cannot use a kur message to request the cer tificate on behalf of the EE as the old EE credential is not available to the KG A for protecting this message. Therefore, if the EE uses the PKI management ope ration described in <xref target="EE_Update" format="default"/>, the KGA MUST ac t as described in <xref target="EE_trustedPKI" format="default"/> to request the certificate for the newly generated key pair on behalf of the EE from the CA.</ t> <t>When an EE requests central key generation for a certificate update using a kur message, the KGA cannot use a kur message to request the cer tificate on behalf of the EE, as the old EE credential is not available to the K GA for protecting this message. Therefore, if the EE uses the PKI management op eration described in <xref target="EE_Update" format="default"/>, the KGA <bcp14 >MUST</bcp14> act as described in <xref target="EE_trustedPKI" format="default"/ > to request the certificate for the newly generated key pair on behalf of the E E from the CA.</t>
<t>Generally speaking, it is strongly preferable to generate public-pr ivate key pairs locally at the EE. This is advisable to make sure that the enti ty identified in the newly issued certificate is the only entity that knows the private key.</t> <t>Generally speaking, it is strongly preferable to generate public-pr ivate key pairs locally at the EE. This is advisable to make sure that the enti ty identified in the newly issued certificate is the only entity that knows the private key.</t>
<t keepWithNext="true">Reasons for central key generation may include the following:</t> <t keepWithNext="true">Reasons for central key generation may include the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Lack of sufficient initial entropy.</t> <t>lack of sufficient initial entropy</t>
<t>Note: Good random numbers are needed not only for ke <t>Note: Good random numbers are not only needed for ke
y generation but also for session keys and nonces in any security protocol. Ther y generation but also for session keys and nonces in any security protocol. Ther
efore, a decent security architecture should anyways support good random number efore, a decent security architecture should anyways support good random number
generation on the EE side or provide enough initial entropy for the RNG seed to generation on the EE side or provide enough initial entropy for the random numbe
guarantee good pseudo-random number generation. Yet maybe this is not the case r generator seed to guarantee good pseudorandom number generation. Yet maybe th
at the time of requesting an initial certificate during manufacturing.</t> is is not the case at the time of requesting an initial certificate during manuf
acturing.</t>
</li> </li>
<li> <li>
<t>Lack of computational resources, in particular for R SA key generation.</t> <t>lack of computational resources, in particular, for RSA key generation</t>
<t>Note: Since key generation could be performed in adv ance to the certificate enrollment communication, it is often not time critical. </t> <t>Note: Since key generation could be performed in adv ance to the certificate enrollment communication, it is often not time critical. </t>
</li> </li>
</ul> </ul>
<t>Note: As mentioned in <xref target="Architecture" format="default"/ >, central key generation may be required in a push model, where the certificate response message is transferred by the PKI management entity to the EE without a previous request message.</t> <t>Note: As mentioned in <xref target="Architecture" format="default"/ >, central key generation may be required in a push model, where the certificate response message is transferred by the PKI management entity to the EE without a previous request message.</t>
<t>The EE requesting central key generation MUST omit the publicKey fi <t>The EE requesting central key generation <bcp14>MUST</bcp14> omit t
eld from the certTemplate or, in case it has a preference on the key type to be he publicKey field from the certTemplate or, in case it has a preference on the
generated, provide this preference in the algorithm sub-field and fill the subje key type to be generated, provide this preference in the algorithm sub-field and
ctPublicKey sub-field with a zero-length BIT STRING. Both variants indicate to fill the subjectPublicKey sub-field with a zero-length BIT STRING. Both varian
the PKI management entity that a new key pair shall be generated centrally on be ts indicate to the PKI management entity that a new key pair shall be generated
half of the EE.</t> centrally on behalf of the EE.</t>
<t>Note: As the protection of centrally generated keys in the r <t>Note: As the protection of centrally generated keys in the response
esponse message has been extended to EncryptedKey by <xref target="I-D.ietf-lamp message has been extended to EncryptedKey by <xref target="RFC9480" format="defa
s-cmp-updates" format="default">CMP Updates Section 2.7</xref>, EnvelopedData is ult" sectionFormat="of" section="2.7">CMP Updates</xref>, EnvelopedData is the p
the preferred alternative to EncryptedValue. In <xref target="RFC4211" format= referred alternative to EncryptedValue.
"default">CRMF Section 2.1.9</xref> the use of EncryptedValue has been deprecate In <xref target="RFC4211" format="default" sectionFormat="comma" sectio
d in favor of the EnvelopedData structure. Therefore, this profile requires usi n="2.1">CRMF</xref>, point 9, the use of EncryptedValue has been deprecated in f
ng EnvelopedData as specified in <xref target="RFC5652" format="default">CMS Sec avor of the EnvelopedData structure. Therefore, this profile requires using Env
tion 6</xref>. When EnvelopedData is to be used in a PKI management operation, elopedData, as specified in <xref target="RFC5652" format="default" sectionForma
CMP v3 MUST be indicated in the message header already for the initial request m t="of" section="6">CMS</xref>. When EnvelopedData is to be used in a PKI manage
essage, see <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updat ment operation, CMP v3 <bcp14>MUST</bcp14> be indicated in the message header al
es Section 2.20</xref>.</t> ready for the initial request message; see <xref target="RFC9480" format="defaul
t" sectionFormat="of" section="2.20">CMP Updates</xref>.</t>
<figure anchor="CMP_envelop"> <figure anchor="CMP_envelop">
<name>Encrypted Private Key Container</name> <name>Encrypted Private Key Container</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+----------------------------------+ +----------------------------------+
| EnvelopedData | | EnvelopedData |
| [RFC5652] Section 6 | | [RFC5652], Section 6 |
| +------------------------------+ | | +------------------------------+ |
| | SignedData | | | | SignedData | |
| | [RFC5652] Section 5 | | | | [RFC5652], Section 5 | |
| | +--------------------------+ | | | | +--------------------------+ | |
| | | AsymmetricKeyPackage | | | | | | AsymmetricKeyPackage | | |
| | | [RFC5958] | | | | | | [RFC5958] | | |
| | | +----------------------+ | | | | | | +----------------------+ | | |
| | | | private key | | | | | | | | private key | | | |
| | | +----------------------+ | | | | | | +----------------------+ | | |
| | +--------------------------+ | | | | +--------------------------+ | |
| +------------------------------+ | | +------------------------------+ |
+----------------------------------+ +----------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The PKI management entity delivers the private key in the privateKe y field in the certifiedKeyPair structure of the response message also containin g the newly issued certificate.</t> <t>The PKI management entity delivers the private key in the privateKe y field in the certifiedKeyPair structure of the response message also containin g the newly issued certificate.</t>
<t>The private key MUST be provided as an AsymmetricKeyPackage structu <t>The private key <bcp14>MUST</bcp14> be provided as an AsymmetricKey
re as defined in <xref target="RFC5958" format="default">RFC&nbsp;5958</xref>.</ Package structure as defined in <xref target="RFC5958" format="default"/>.</t>
t> <t>This AsymmetricKeyPackage structure <bcp14>MUST</bcp14> be wrapped
<t>This AsymmetricKeyPackage structure MUST be wrapped in a SignedData in a SignedData structure, as specified in <xref target="RFC5652" format="defaul
structure, as specified in <xref target="RFC5652" format="default">CMS Section t" sectionFormat="of" section="5">CMS</xref> and <xref target="RFC8933" format="
5</xref> and <xref target="RFC8933" format="default"/>, signed by the KGA genera default"/>, and signed by the KGA generating the key pair. The signature <bcp14>
ting the key pair. The signature MUST be performed using a private key related t MUST</bcp14> be performed using a private key related to a certificate asserting
o a certificate asserting the extended key usage id-kp-cmKGA as described in <xr the extended key usage id-kp-cmKGA, as described in <xref target="RFC9480" form
ef target="I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 2.2< at="default" sectionFormat="of" section="2.2">CMP Updates</xref>, to demonstrate
/xref> to demonstrate authorization to generate key pairs on behalf of an EE. F authorization to generate key pairs on behalf of an EE. For response messages
or response messages using signature-based protection, the EE MUST validate the using signature-based protection, the EE <bcp14>MUST</bcp14> validate the signer
signer certificate contained in the SignedData structure and SHOULD authorize th certificate contained in the SignedData structure and <bcp14>SHOULD</bcp14> aut
e KGA considering any given id-kp-cmKGA extended key usage in the signer certifi horize the KGA considering any given id-kp-cmKGA extended key usage in the signe
cate. For response messages using MAC-based protection the EE MAY omit the vali r certificate. For response messages using MAC-based protection, the EE <bcp14>
dation as it may not be possible or meaningful to the EE. In this case the EE a MAY</bcp14> omit the validation as it may not be possible or meaningful to the E
uthorizes the KGA using the shard secret information.</t> E. In this case, the EE authorizes the KGA using the shard secret information.<
<t>The SignedData structure MUST be wrapped in an EnvelopedData struct /t>
ure, as specified in <xref target="RFC5652" format="default">CMS Section 6</xref <t>The SignedData structure <bcp14>MUST</bcp14> be wrapped in an Envel
>, encrypting it using a newly generated symmetric content-encryption key.</t> opedData structure, as specified in <xref target="RFC5652" format="default" sect
<t>This content-encryption key MUST be securely provided as part of th ionFormat="of" section="6">CMS</xref>, encrypting it using a newly generated sym
e EnvelopedData structure to the EE using one of three key management techniques metric content-encryption key.</t>
. The choice of the key management technique to be used by the PKI management en <t>This content-encryption key <bcp14>MUST</bcp14> be securely provide
tity depends on the authentication mechanism the EE chose to protect the request d as part of the EnvelopedData structure to the EE using one of three key manage
message. See <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Upd ment techniques. The choice of the key management technique to be used by the PK
ates Section 2.7</xref> for details on which key management technique to use.</t I management entity depends on the authentication mechanism the EE chose to prot
> ect the request message. See <xref target="RFC9480" format="default" sectionForm
at="of" section="2.7">CMP Updates</xref> for details on which key management tec
hnique to use.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Signature-based protection of the request message:</t> <t>Signature-based protection of the request message:</t>
<t>In this case the choice depends on the type of the p ublic key in the CMP protection certificate used by the EE in its request.</t> <t>In this case, the choice depends on the type of publ ic key in the CMP protection certificate used by the EE in its request.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The content-encryption key SHALL be protected using the key <li>The content-encryption key <bcp14>SHALL</bcp14> be protected
transport key management technique, see <xref target="EE_KGTrans" format="defaul using the key transport key management technique (see <xref target="EE_KGTrans"
t"/>, if the key type supports this.</li> format="default"/>) if the key type supports this.</li>
<li>The content-encryption key SHALL be protected using the key <li>The content-encryption key <bcp14>SHALL</bcp14> be protected
agreement key management technique, see <xref target="EE_KGAgree" format="defaul using the key agreement key management technique (see <xref target="EE_KGAgree"
t"/>, if the key type supports this.</li> format="default"/>) if the key type supports this.</li>
</ul> </ul>
</li> </li>
<li> <li>
<t>MAC-based protected of the request message:</t> <t>MAC-based protection of the request message:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The content-encryption key SHALL be protected using the pass word-based key management technique, see <xref target="EE_KGPB" format="default" />, if and only if the EE used MAC-based protection for the request message.</li > <li>The content-encryption key <bcp14>SHALL</bcp14> be protected using the password-based key management technique (see <xref target="EE_KGPB" f ormat="default"/>) if and only if the EE used MAC-based protection for the reque st message.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t keepWithNext="true">Specific prerequisites augmenting those of the respective certificate enrollment PKI management operations:</t> <t keepWithNext="true">Specific prerequisites augmenting those of the respective certificate enrollment PKI management operations are as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If signature-based protection is used, the EE MUST be abl <li>If signature-based protection is used, the EE <bcp14>MUST
e to authenticate and authorize the KGA, using suitable information, which inclu </bcp14> be able to authenticate and authorize the KGA using suitable informatio
des a trust anchor.</li> n, which includes a trust anchor.</li>
<li>If MAC-based protection is used, the KGA MUST also kn <li>If MAC-based protection is used, the KGA <bcp14>MUST<
ow the shared secret information to protect the encrypted transport of the newly /bcp14> also know the shared secret information to protect the encrypted transpo
generated key pair. Consequently, the EE can also authorize the KGA.</li> rt of the newly generated key pair. Consequently, the EE can also authorize the
<li>The PKI management entity MUST have a certificate containing the KGA.</li>
additional extended key usage extension id-kp-cmKGA for signing the SignedData <li>The PKI management entity <bcp14>MUST</bcp14> have a certificate
structure containing the private key package.</li> containing the additional extended key usage extension id-kp-cmKGA for signing
the SignedData structure containing the private key package.</li>
<li> <li>
<t>For encrypting the SignedData structure a fresh cont ent-encryption key to be used by the symmetric encryption algorithm MUST be gene rated with sufficient entropy.</t> <t>For encrypting the SignedData structure, a fresh con tent-encryption key to be used by the symmetric encryption algorithm <bcp14>MUST </bcp14> be generated with sufficient entropy.</t>
<t>Note: The security strength of the protection of the generated private key should be similar or higher than the security strength of the generated private key.</t> <t>Note: The security strength of the protection of the generated private key should be similar or higher than the security strength of the generated private key.</t>
</li> </li>
</ul> </ul>
<t keepWithNext="true">Detailed Description of privateKey Field:</t> <t keepWithNext="true">Detailed Description of the privateKey Field:</
<artwork align="left" name="" type="" alt=""><![CDATA[ t>
<sourcecode type="pseudocode"><![CDATA[
privateKey REQUIRED privateKey REQUIRED
-- MUST be an EnvelopedData structure as specified in CMS -- MUST be an EnvelopedData structure, as specified in
-- Section 6 [RFC5652] -- Section 6 of CMS [RFC5652]
version REQUIRED version REQUIRED
-- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and -- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and
-- KeyTransRecipientInfo -- KeyTransRecipientInfo
-- MUST be 0 for recipientInfo type PasswordRecipientInfo -- MUST be 0 for recipientInfo type PasswordRecipientInfo
recipientInfos REQUIRED recipientInfos REQUIRED
-- MUST contain a sequence of one RecipientInfo, which MUST be -- MUST contain a sequence of one RecipientInfo, which MUST be
-- kari of type KeyAgreeRecipientInfo (see section 4.1.6.1), -- ktri of type KeyTransRecipientInfo (see Section 4.1.6.1),
-- ktri of type KeyTransRecipientInfo (see section 4.1.6.2), or -- kari of type KeyAgreeRecipientInfo (see Section 4.1.6.2), or
-- pwri of type PasswordRecipientInfo (see section 4.1.6.3) -- pwri of type PasswordRecipientInfo (see Section 4.1.6.3)
encryptedContentInfo encryptedContentInfo
REQUIRED REQUIRED
contentType REQUIRED contentType REQUIRED
-- MUST be id-signedData -- MUST be id-signedData
contentEncryptionAlgorithm contentEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the algorithm used for -- MUST be the algorithm identifier of the algorithm used for
-- content encryption -- content encryption
-- The algorithm type MUST be a PROT_SYM_ALG as specified in -- The algorithm type MUST be PROT_SYM_ALG as specified in
-- RFCBBBB Section 5 -- [RFC9481], Section 5
encryptedContent REQUIRED encryptedContent REQUIRED
-- MUST be the SignedData structure as specified in CMS -- MUST be the SignedData structure, as specified in Section 5
-- Section 5 [RFC5652] and [RFC8933] in encrypted form -- of CMS [RFC5652] and [RFC8933], in encrypted form
version REQUIRED version REQUIRED
-- MUST be 3 -- MUST be 3
digestAlgorithms digestAlgorithms
REQUIRED REQUIRED
-- MUST contain a sequence of one AlgorithmIdentifier element -- MUST contain a sequence of one AlgorithmIdentifier element
-- MUST be the algorithm identifier of the digest algorithm -- MUST be the algorithm identifier of the digest algorithm
-- used for generating the signature and match the signature -- used for generating the signature and match the signature
-- algorithm specified in signatureAlgorithm, see [RFC8933] -- algorithm specified in signatureAlgorithm; see [RFC8933]
encapContentInfo encapContentInfo
REQUIRED REQUIRED
-- MUST contain the content that is to be signed -- MUST contain the content that is to be signed
eContentType REQUIRED eContentType REQUIRED
-- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958] -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958]
eContent REQUIRED eContent REQUIRED
-- MUST be of type AsymmetricKeyPackage and -- MUST be of type AsymmetricKeyPackage and
-- MUST contain a sequence of one OneAsymmetricKey element -- MUST contain a sequence of one OneAsymmetricKey element
version REQUIRED version REQUIRED
-- MUST be 1 (indicating v2) -- MUST be 1 (indicating v2)
skipping to change at line 1214 skipping to change at line 1190
digestAlgorithm digestAlgorithm
REQUIRED REQUIRED
-- MUST be the same as in the digestAlgorithms field of -- MUST be the same as in the digestAlgorithms field of
-- encryptedContent -- encryptedContent
signedAttrs REQUIRED signedAttrs REQUIRED
-- MUST contain an id-contentType attribute containing the value -- MUST contain an id-contentType attribute containing the value
-- id-ct-KP-aKeyPackage -- id-ct-KP-aKeyPackage
-- MUST contain an id-messageDigest attribute containing the -- MUST contain an id-messageDigest attribute containing the
-- message digest of eContent -- message digest of eContent
-- MAY contain an id-signingTime attribute containing the time -- MAY contain an id-signingTime attribute containing the time
-- of signature. It SHOULD be omitted if the transactionTime -- of a signature. It SHOULD be omitted if the transactionTime
-- field is not present in the PKIHeader. -- field is not present in the PKIHeader.
-- For details on the signed attributes see CMS Section 5.3 and -- For details on the signed attributes, see Sections 5.3 and
-- Section 11 [RFC5652] and [RFC8933] -- 11 of CMS [RFC5652] and [RFC8933]
signatureAlgorithm signatureAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the signature algorithm -- MUST be the algorithm identifier of the signature algorithm
-- used for calculation of the signature bits -- used for calculation of the signature bits
-- The signature algorithm type MUST be a MSG_SIG_ALG as -- The signature algorithm type MUST be MSG_SIG_ALG, as
-- specified in RFCBBBB Section 3 and MUST be consistent -- specified in [RFC9481], Section 3, and MUST be consistent
-- with the subjectPublicKeyInfo field of the KGA certificate -- with the subjectPublicKeyInfo field of the KGA certificate
signature REQUIRED signature REQUIRED
-- MUST be the digital signature of the encapContentInfo -- MUST be the digital signature of the encapContentInfo
]]></artwork> ]]></sourcecode>
<t>As stated in Section 1.5, all fields of the ASN.1 syntax tha <t>As stated in <xref target="Scope"/>, all fields of the ASN.1
t are defined in RFC 5652 [RFC5652] but are not explicitly specified here SHOULD syntax that are defined in <xref target="RFC5652"/> but are not explicitly spec
NOT be used.</t> ified here <bcp14>SHOULD NOT</bcp14> be used.</t>
<section anchor="EE_KGTrans" numbered="true" toc="default"> <section anchor="EE_KGTrans" numbered="true" toc="default">
<name>Using Key Transport Key Management Technique</name> <name>Using the Key Transport Key Management Technique</name>
<t>This variant can be applied in combination with the PKI managemen <t>This variant can be applied in combination with the PKI managemen
t operations specified in <xref target="EE_newPKI" format="default"/> to <xref t t operations specified in Sections <xref target="EE_newPKI" format="counter"/> t
arget="EE_Update" format="default"/> using signature-based protection of CMP mes o <xref target="EE_Update" format="counter"/> using signature-based protection o
sages. The EE certificate used for the signature-based protection of the reques f CMP messages. The EE certificate used for the signature-based protection of t
t message MUST contain a public key supporting key transport and allow for the k he request message <bcp14>MUST</bcp14> contain a public key supporting key trans
ey usage "keyEncipherment". The related key pair MUST be used for encipherment port and allow for the key usage "keyEncipherment". The related key pair <bcp14
of the content-encryption key. For this key management technique, the KeyTransR >MUST</bcp14> be used for encipherment of the content-encryption key. For this
ecipientInfo structure MUST be used in the contentInfo field.</t> key management technique, the KeyTransRecipientInfo structure <bcp14>MUST</bcp14
<t>The KeyTransRecipientInfo structure included into the EnvelopedDa > be used in the contentInfo field.</t>
ta structure is specified in <xref target="RFC5652" format="default">CMS Section <t>The KeyTransRecipientInfo structure included into the EnvelopedDa
6.2.1</xref>.</t> ta structure is specified in <xref target="RFC5652" format="default" sectionForm
<t keepWithNext="true">Detailed Description of KeyTransRecipientInfo at="of" section="6.2.1">CMS</xref>.</t>
Structure:</t> <t keepWithNext="true">Detailed Description of the KeyTransRecipient
<artwork align="left" name="" type="" alt=""><![CDATA[ Info Structure:</t>
<sourcecode type="pseudocode"><![CDATA[
ktri REQUIRED ktri REQUIRED
-- MUST be a KeyTransRecipientInfo as specified in CMS -- MUST be KeyTransRecipientInfo as specified in Section 6.2.1
-- Section 6.2.1 [RFC5652] -- of CMS [RFC5652]
version REQUIRED version REQUIRED
-- MUST be 2 -- MUST be 2
rid REQUIRED rid REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection -- MUST contain the subjectKeyIdentifier of the CMP protection
-- certificate, if available, in the rKeyId choice and the -- certificate, if available, in the rKeyId choice, and the
-- subjectKeyIdentifier MUST equal the senderKID in the -- subjectKeyIdentifier MUST equal the senderKID in the
-- PKIHeader. -- PKIHeader.
-- If the CMP protection certificate does not contain a -- If the CMP protection certificate does not contain a
-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST -- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
-- be used. -- be used.
keyEncryptionAlgorithm keyEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the key transport -- MUST be the algorithm identifier of the key transport
-- algorithm. The algorithm type MUST be a KM_KT_ALG as -- algorithm. The algorithm type MUST be KM_KT_ALG as
-- specified in RFCBBBB Section 4.2 -- specified in [RFC9481], Section 4.2
encryptedKey REQUIRED encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key -- MUST be the encrypted content-encryption key
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="EE_KGAgree" numbered="true" toc="default"> <section anchor="EE_KGAgree" numbered="true" toc="default">
<name>Using Key Agreement Key Management Technique</name> <name>Using the Key Agreement Key Management Technique</name>
<t>This variant can be applied in combination with the PKI managemen <t>This variant can be applied in combination with the PKI managemen
t operations specified in <xref target="EE_newPKI" format="default"/> to <xref t t operations specified in Sections <xref target="EE_newPKI" format="counter"/> t
arget="EE_Update" format="default"/> using signature-based protection of CMP mes o <xref target="EE_Update" format="counter"/>, using signature-based protection
sages. The EE certificate used for the signature-based protection of the reques of CMP messages. The EE certificate used for the signature-based protection of
t message MUST contain a public key supporting key agreement and allow for the k the request message <bcp14>MUST</bcp14> contain a public key supporting key agre
ey usage "keyAgreement". The related key pair MUST be used for establishment of ement and allow for the key usage "keyAgreement". The related key pair <bcp14>MU
the content-encryption key. For this key management technique the KeyAgreeRecip ST</bcp14> be used for establishment of the content-encryption key. For this ke
ientInfo structure MUST be used in the contentInfo field.</t> y management technique, the KeyAgreeRecipientInfo structure <bcp14>MUST</bcp14>
<t>The KeyAgreeRecipientInfo structure included into the EnvelopedDa be used in the contentInfo field.</t>
ta structure is specified in <xref target="RFC5652" format="default">CMS Section <t>The KeyAgreeRecipientInfo structure included into the EnvelopedDa
6.2.2</xref>.</t> ta structure is specified in <xref target="RFC5652" format="default" sectionForm
<t keepWithNext="true">Detailed Description of KeyAgreeRecipientInfo at="of" section="6.2.2">CMS</xref>.</t>
Structure:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <t keepWithNext="true">Detailed Description of the KeyAgreeRecipientInfo Structu
re:</t>
<sourcecode type="pseudocode"><![CDATA[
kari REQUIRED kari REQUIRED
-- MUST be a KeyAgreeRecipientInfo as specified in CMS Section -- MUST be KeyAgreeRecipientInfo as specified in Section
-- 6.2.2 [RFC5652] -- 6.2.2 of CMS [RFC5652]
version REQUIRED version REQUIRED
-- MUST be 3 -- MUST be 3
originator REQUIRED originator REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection -- MUST contain the subjectKeyIdentifier of the CMP protection
-- certificate, if available, in the subjectKeyIdentifier -- certificate, if available, in the subjectKeyIdentifier
-- choice and the subjectKeyIdentifier MUST equal the senderKID -- choice, and the subjectKeyIdentifier MUST equal the
-- in the PKIHeader. -- senderKID in the PKIHeader.
-- If the CMP protection certificate does not contain a -- If the CMP protection certificate does not contain a
-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST -- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
-- be used. -- be used.
ukm RECOMMENDED ukm RECOMMENDED
-- MUST be used when 1-pass ECMQV is used, see [RFC5753] -- MUST be used when 1-Pass Elliptic Curve Menezes-Qu-Vanstone
-- (ECMQV) is used; see [RFC5753]
-- SHOULD be present to ensure uniqueness of the key -- SHOULD be present to ensure uniqueness of the key
-- encryption key -- encryption key
keyEncryptionAlgorithm keyEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the key agreement -- MUST be the algorithm identifier of the key agreement
-- algorithm -- algorithm
-- The algorithm type MUST be a KM_KA_ALG as specified in -- The algorithm type MUST be KM_KA_ALG as specified in
-- RFCBBBB Section 4.1 -- [RFC9481], Section 4.1
-- The parameters field of the key agreement algorithm MUST -- The parameters field of the key agreement algorithm MUST
-- contain the key wrap algorithm. The algorithm type -- contain the key wrap algorithm. The algorithm type
-- MUST be a KM_KW_ALG as specified in RFCBBBB Section 4.3 -- MUST be KM_KW_ALG as specified in [RFC9481], Section 4.3
recipientEncryptedKeys recipientEncryptedKeys
REQUIRED REQUIRED
-- MUST contain a sequence of one RecipientEncryptedKey -- MUST contain a sequence of one RecipientEncryptedKey
rid REQUIRED rid REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection -- MUST contain the subjectKeyIdentifier of the CMP protection
-- certificate, if available, in the rKeyId choice and the -- certificate, if available, in the rKeyId choice, and the
-- subjectKeyIdentifier MUST equal the senderKID in the -- subjectKeyIdentifier MUST equal the senderKID in the
-- PKIHeader. -- PKIHeader.
-- If the CMP protection certificate does not contain a -- If the CMP protection certificate does not contain a
-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST -- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
-- be used -- be used
encryptedKey encryptedKey
REQUIRED REQUIRED
-- MUST be the encrypted content-encryption key -- MUST be the encrypted content-encryption key
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="EE_KGPB" numbered="true" toc="default"> <section anchor="EE_KGPB" numbered="true" toc="default">
<name>Using Password-Based Key Management Technique</name> <name>Using the Password-Based Key Management Technique</name>
<t>This variant can be applied in combination with the PKI managemen <t>This variant can be applied in combination with the PKI managemen
t operation specified in <xref target="EE_MAC" format="default"/> using MAC-base t operation specified in <xref target="EE_MAC" format="default"/>, using MAC-bas
d protection of CMP messages. The shared secret information used for the MAC-ba ed protection of CMP messages. The shared secret information used for the MAC-b
sed protection MUST also be used for the encryption of the content-encryption ke ased protection <bcp14>MUST</bcp14> also be used for the encryption of the conte
y but with a different salt value applied in the key derivation algorithm. For nt-encryption key but with a different salt value applied in the key derivation
this key management technique, the PasswordRecipientInfo structure MUST be used algorithm. For this key management technique, the PasswordRecipientInfo structu
in the contentInfo field.</t> re <bcp14>MUST</bcp14> be used in the contentInfo field.</t>
<t>Note: The entropy of the shared secret information is <t>Note: The entropy of the shared secret information is
crucial for the level of protection when using a password-based key management t crucial for the level of protection when using a password-based key management t
echnique. For centrally generated key pairs, the entropy of the shared secret i echnique. For centrally generated key pairs, the entropy of the shared secret i
nformation SHALL NOT be less than the security strength of the centrally generat nformation <bcp14>SHALL NOT</bcp14> be less than the security strength of the ce
ed key pair. Further guidance is available in <xref target="Security" format="d ntrally generated key pair. Further guidance is available in <xref target="Secu
efault"/>.</t> rity" format="default"/>.</t>
<t>The PasswordRecipientInfo structure included into the EnvelopedDa <t>The PasswordRecipientInfo structure included into the EnvelopedDa
ta structure is specified in <xref target="RFC5652" format="default">CMS Section ta structure is specified in <xref target="RFC5652" format="default" sectionForm
6.2.4</xref>.</t> at="of" section="6.2.4">CMS</xref>.</t>
<t keepWithNext="true">Detailed Description of PasswordRecipientInfo <t keepWithNext="true">Detailed Description of the PasswordRecipient
Structure:</t> Info Structure:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
pwri REQUIRED pwri REQUIRED
-- MUST be a PasswordRecipientInfo as specified in CMS -- MUST be PasswordRecipientInfo as specified in
-- Section 6.2.4 [RFC5652] -- Section 6.2.4 of CMS [RFC5652]
version REQUIRED version REQUIRED
-- MUST be 0 -- MUST be 0
keyDerivationAlgorithm keyDerivationAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the key derivation -- MUST be the algorithm identifier of the key derivation
-- algorithm -- algorithm
-- The algorithm type MUST be a KM_KD_ALG as specified in -- The algorithm type MUST be KM_KD_ALG as specified in
-- RFCBBBB Section 4.4 -- [RFC9481], Section 4.4
keyEncryptionAlgorithm keyEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the key wrap algorithm -- MUST be the algorithm identifier of the key wrap algorithm
-- The algorithm type MUST be a KM_KW_ALG as specified in -- The algorithm type MUST be KM_KW_ALG as specified in
-- RFCBBBB Section 4.3 -- [RFC9481], Section 4.3
encryptedKey REQUIRED encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key -- MUST be the encrypted content-encryption key
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="EE_Revoke" numbered="true" toc="default"> <section anchor="EE_Revoke" numbered="true" toc="default">
<name>Revoking a Certificate</name> <name>Revoking a Certificate</name>
<t>This PKI management operation should be used by an entity to request <t>This PKI management operation should be used by an entity to request
revocation of a certificate. Here the revocation request is used by an EE to rev revocation of a certificate. Here, the revocation request is used by an EE to re
oke one of its own certificates.</t> voke one of its own certificates.</t>
<t>The revocation request message MUST be signed using the certificate t <t>The revocation request message <bcp14>MUST</bcp14> be signed using th
hat is to be revoked to prove the authorization to revoke. The revocation reques e certificate that is to be revoked to prove the authorization to revoke. The re
t message is signature-protected using this certificate. This requires, that the vocation request message is signature-protected using this certificate. This req
EE still possesses the private key. If this is not the case the revocation has uires that the EE still possesses the private key. If this is not the case, the
to be initiated by other means, e.g., revocation by the RA as specified in <xref revocation has to be initiated by other means, e.g., revocation by the RA, as sp
target="RA_on-behalf_revoke" format="default"/>.</t> ecified in <xref target="RA_on-behalf_revoke" format="default"/>.</t>
<t>An EE requests revoking a certificate of its own at the CA that issue <t>An EE requests revoking a certificate of its own at the CA that issue
d this certificate. The PKI management entity handles the request as described i d this certificate. The PKI management entity handles the request as described i
n <xref target="RA_response_revocation" format="default"/> and responds with a m n <xref target="RA_response_revocation" format="default"/>, and responds with a
essage that contains the status of the revocation from the CA.</t> message that contains the status of the revocation from the CA.</t>
<t keepWithNext="true">Specific prerequisites augmenting the prerequisit <t keepWithNext="true">The specific prerequisite augmenting the prerequi
es in <xref target="Prereq" format="default"/>:</t> sites in <xref target="Prereq" format="default"/> is as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The certificate the EE wishes to revoke is not yet expired or revoked.</li> <li>The certificate the EE wishes to revoke is not yet expired or revoked.</li>
</ul> </ul>
<t keepWithNext="true">Message Flow:</t> <t keepWithNext="true">Message Flow:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
Step# EE PKI management entity Step# EE PKI management entity
1 format rr 1 format rr
2 -> rr -> 2 -> rr ->
3 handle or forward rr 3 handle or forward rr
4 format or receive rp 4 format or receive rp
5 <- rp <- 5 <- rp <-
6 handle rp 6 handle rp
]]></artwork> ]]></artwork>
<t>For this PKI management operation, the EE MUST include a sequence of one RevDetails structure in the rr message body. In the case no generic error oc curred, the response to the rr MUST be an rp message containing a single status field.</t> <t>For this PKI management operation, the EE <bcp14>MUST</bcp14> include a sequence of one RevDetails structure in the rr message body. In the case no g eneric error occurred, the response to the rr <bcp14>MUST</bcp14> be an rp messa ge containing a single status field.</t>
<t keepWithNext="true">Detailed Message Description:</t> <t keepWithNext="true">Detailed Message Description:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
Revocation Request -- rr Revocation Request -- rr
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The request of the EE to revoke its certificate -- The request of the EE to revoke its certificate
rr REQUIRED rr REQUIRED
skipping to change at line 1379 skipping to change at line 1357
certDetails REQUIRED certDetails REQUIRED
-- MUST be present and is of type CertTemplate -- MUST be present and is of type CertTemplate
serialNumber REQUIRED serialNumber REQUIRED
-- MUST contain the certificate serialNumber attribute of the -- MUST contain the certificate serialNumber attribute of the
-- certificate to be revoked -- certificate to be revoked
issuer REQUIRED issuer REQUIRED
-- MUST contain the issuer attribute of the certificate to be -- MUST contain the issuer attribute of the certificate to be
-- revoked -- revoked
crlEntryDetails REQUIRED crlEntryDetails REQUIRED
-- MUST contain a sequence of one reasonCode of type CRLReason -- MUST contain a sequence of one reasonCode of type CRLReason
-- (see [RFC5280] section 5.3.1) -- (see [RFC5280], Section 5.3.1)
-- If the reason for this revocation is not known or shall not -- If the reason for this revocation is not known or shall not
-- be published the reasonCode MUST be 0 (unspecified) -- be published, the reasonCode MUST be 0 (unspecified)
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 and using the private key related -- As described in Section 3.2 and using the private key related
-- to the certificate to be revoked -- to the certificate to be revoked
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
Revocation Response -- rp Revocation Response -- rp
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The responds of the PKI management entity to the request as -- The response of the PKI management entity to the request as
-- appropriate -- appropriate
rp REQUIRED rp REQUIRED
status REQUIRED status REQUIRED
-- MUST contain a sequence of one element of type PKIStatusInfo -- MUST contain a sequence of one element of type PKIStatusInfo
status REQUIRED status REQUIRED
-- positive value allowed: "accepted" -- positive value allowed: "accepted"
-- negative value allowed: "rejection" -- negative value allowed: "rejection"
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging or to -- MAY be any human-readable text for debugging, for logging, or
-- display in a GUI -- to display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MAY be present if status is "rejection" -- MAY be present if the status is "rejection"
-- MUST be absent if the status is "accepted" -- MUST be absent if the status is "accepted"
protection REQUIRED protection REQUIRED
-- As described in section 3.2 -- As described in Section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 3.3 -- As described in Section 3.3
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="EE_GeneralMessage" numbered="true" toc="default"> <section anchor="EE_GeneralMessage" numbered="true" toc="default">
<name>Support Messages</name> <name>Support Messages</name>
<t>The following support messages offer on demand in-band delivery of co <t>The following support messages offer on-demand, in-band delivery of c
ntent relevant to the EE provided by a PKI management entity. CMP general messa ontent relevant to the EE provided by a PKI management entity. CMP general mess
ges and general response are used for this purpose. Depending on the environmen ages and general response are used for this purpose. Depending on the environme
t, these requests may be answered by an RA or CA (see also <xref target="RA_resp nt, these requests may be answered by an RA or CA (see also <xref target="RA_res
onse_support" format="default"/>).</t> ponse_support" format="default"/>).</t>
<t>The general messages and general response messages contain InfoTypeAn <t>The general messages and general response messages contain InfoTypeAn
dValue structures. In addition to those infoType values defined in <xref target= dValue structures. In addition to those infoType values defined in <xref target=
"RFC4210" format="default">RFC&nbsp;4210</xref> and <xref target="I-D.ietf-lamps "RFC4210" format="default"/> and <xref target="RFC9480" format="default">CMP Upd
-cmp-updates" format="default">CMP Updates</xref> further OIDs MAY be used to de ates</xref>, further OIDs <bcp14>MAY</bcp14> be used to define new PKI managemen
fine new PKI management operations or new general-purpose support messages as ne t operations or new general-purpose support messages as needed in specific envir
eded in specific environments.</t> onments.</t>
<t keepWithNext="true">The following contents are specified in this docu ment:</t> <t keepWithNext="true">The following contents are specified in this docu ment:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Get CA certificates</li> <li>Get CA certificates.</li>
<li>Get root CA certificate update</li> <li>Get root CA certificate update.</li>
<li>Get certificate request template</li> <li>Get certificate request template.</li>
<li>Get new CRLs</li> <li>Get new Certificate Revocation Lists (CRLs).</li>
</ul> </ul>
<t>The following message flow and contents are common to all general mes sage (genm) and general response (genp) messages.</t> <t>The following message flow and contents are common to all general mes sage (genm) and general response (genp) messages.</t>
<t keepWithNext="true">Message Flow:</t> <t keepWithNext="true">Message Flow:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
Step# EE PKI management entity Step# EE PKI management entity
1 format genm 1 format genm
2 -> genm -> 2 -> genm ->
3 handle or forward genm 3 handle or forward genm
4 format or receive genp 4 format or receive genp
5 <- genp <- 5 <- genp <-
6 handle genp 6 handle genp
]]></artwork> ]]></artwork>
<t keepWithNext="true">Detailed Message Description:</t> <t keepWithNext="true">Detailed Message Description:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
General Message -- genm General Message -- genm
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- A request by the EE for information -- A request by the EE for information
genm REQUIRED genm REQUIRED
skipping to change at line 1491 skipping to change at line 1469
-- MUST be the OID identifying the specific PKI management -- MUST be the OID identifying the specific PKI management
-- operation described below -- operation described below
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be as specified for the specific PKI management operation -- MUST be as specified for the specific PKI management operation
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
]]></artwork> ]]></sourcecode>
<section anchor="EE_CACerts" numbered="true" toc="default"> <section anchor="EE_CACerts" numbered="true" toc="default">
<name>Get CA Certificates</name> <name>Get CA Certificates</name>
<t>This PKI management operation can be used by an EE to request CA ce rtificates from the PKI management entity.</t> <t>This PKI management operation can be used by an EE to request CA ce rtificates from the PKI management entity.</t>
<t>An EE requests CA certificates, e.g., for chain construction, from an PKI management entity by sending a general message with OID id-it-caCerts as specified in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Upda tes Section 2.14</xref>. The PKI management entity responds with a general respo nse with the same OID that either contains a SEQUENCE of certificates populated with the available intermediate and issuing CA certificates or with no content i n case no CA certificate is available.</t> <t>An EE requests CA certificates, e.g., for chain construction, from a PKI management entity by sending a general message with OID id-it-caCerts, as specified in <xref target="RFC9480" format="default" sectionFormat="of" section= "2.14">CMP Updates</xref>. The PKI management entity responds with a general res ponse with the same OID that either contains a SEQUENCE of certificates populate d with the available intermediate and issuing CA certificates or no content in c ase no CA certificate is available.</t>
<t>No specific prerequisites apply in addition to those specifi ed in <xref target="Prereq" format="default"/>.</t> <t>No specific prerequisites apply in addition to those specifi ed in <xref target="Prereq" format="default"/>.</t>
<t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t> <t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t>
<ol spacing="normal" type="%d"> <ol spacing="normal" type="1">
<li>the infoType OID to use is id-it-caCerts</li> <li>the infoType OID to use is id-it-caCerts</li>
<li>the infoValue of the request MUST be absent</li> <li>the infoValue of the request <bcp14>MUST</bcp14> be absent</li>
<li>if present, the infoValue of the response MUST contain a sequenc <li>if present, the infoValue of the response <bcp14>MUST</bcp14> co
e of certificates</li> ntain a sequence of certificates</li>
</ol> </ol>
<t keepWithNext="true">Detailed Description of infoValue Field of genp <t keepWithNext="true">Detailed Description of the infoValue Field of
:</t> genp:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no CA certificate is available -- MUST be absent if no CA certificate is available
-- MUST be present if CA certificates are available -- MUST be present if CA certificates are available
-- if present, MUST be a sequence of CMPCertificate -- if present, MUST be a sequence of CMPCertificate
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="EE_RootCAUpdate" numbered="true" toc="default"> <section anchor="EE_RootCAUpdate" numbered="true" toc="default">
<name>Get Root CA Certificate Update</name> <name>Get Root CA Certificate Update</name>
<t>This PKI management operation can be used by an EE to request an up <t>This PKI management operation can be used by an EE to request an up
dated root CA Certificate as described in <xref target="RFC4210" format="default dated root CA certificate as described in <xref target="RFC4210" format="default
">Section 4.4 of RFC&nbsp;4210</xref>.</t> " sectionFormat="of" section="4.4"/>.</t>
<t>An EE requests an update of a root CA certificate from the P <t>An EE requests an update of a root CA certificate from the PKI manag
KI management entity by sending a general message with OID id-it-rootCaCert. If ement entity by sending a general message with OID id-it-rootCaCert. If needed f
needed for unique identification, the EE MUST include the old root CA certificat or unique identification, the EE <bcp14>MUST</bcp14> include the old root CA cer
e in the message body, as specified in <xref target="I-D.ietf-lamps-cmp-updates" tificate in the message body as specified in <xref target="RFC9480" format="defa
format="default">CMP Updates Section 2.15</xref>. The PKI management entity re ult" sectionFormat="of" section="2.15">CMP Updates</xref>. The PKI management e
sponds with a general response with OID id-it-rootCaKeyUpdate that either contai ntity responds with a general response with OID id-it-rootCaKeyUpdate that eithe
ns the update of the root CA certificate consisting of up to three certificates, r contains the update of the root CA certificate consisting of up to three certi
or with no content in case no update is available.</t> ficates or no content in case no update is available.</t>
<t>Note: This mechanism may also be used to update trusted non- <t>Note: This mechanism may also be used to update trusted non-
root certificates, i.e., directly trusted intermediate CA or issuing CA certific root certificates, e.g., directly trusted intermediate or issuing CA certificate
ates.</t> s.</t>
<t>The newWithNew certificate is the new root CA certificate and is RE <t>The newWithNew certificate is the new root CA certificate and is <b
QUIRED to be present if available. The newWithOld certificate is REQUIRED to be cp14>REQUIRED</bcp14> to be present if available. The newWithOld certificate is
present in the response message because it is needed for the receiving entity t <bcp14>REQUIRED</bcp14> to be present in the response message because it is nee
rusting the old root CA certificate to gain trust in the new root CA certificate ded for the receiving entity trusting the old root CA certificate to gain trust
. The oldWithNew certificate is OPTIONAL because it is only needed in rare scen in the new root CA certificate. The oldWithNew certificate is <bcp14>OPTIONAL</
arios where other entities may not already trust the old root CA.</t> bcp14> because it is only needed in rare scenarios where other entities may not
already trust the old root CA.</t>
<t>No specific prerequisites apply in addition to those specifi ed in <xref target="Prereq" format="default"/>.</t> <t>No specific prerequisites apply in addition to those specifi ed in <xref target="Prereq" format="default"/>.</t>
<t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t> <t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t>
<ol spacing="normal" type="%d"> <ol spacing="normal" type="1">
<li>the infoType OID to use is id-it-rootCaCert in the reques <li>the infoType OID to use is id-it-rootCaCert in the request and id
t and id-it-rootCaKeyUpdate in the response</li> -it-rootCaKeyUpdate in the response</li>
<li>the infoValue of the request SHOULD contain the root CA certific <li>the infoValue of the request <bcp14>SHOULD</bcp14> contain the r
ate the update is requested for</li> oot CA certificate the update is requested for</li>
<li>if present, the infoValue of the response MUST be a RootCaKeyUpd <li>if present, the infoValue of the response <bcp14>MUST</bcp14> be
ateContent structure</li> a RootCaKeyUpdateContent structure</li>
</ol> </ol>
<t keepWithNext="true">Detailed Description of infoValue Field of genm <t keepWithNext="true">Detailed Description of the infoValue Field of
:</t> genm:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
infoValue RECOMMENDED infoValue RECOMMENDED
-- MUST contain the root CA certificate to be updated if needed -- MUST contain the root CA certificate to be updated if needed
-- for unique identification -- for unique identification
]]></artwork> ]]></sourcecode>
<t keepWithNext="true">Detailed Description of infoValue Field of genp <t keepWithNext="true">Detailed Description of the infoValue Field of
:</t> genp:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no update of the root CA certificate is -- MUST be absent if no update of the root CA certificate is
-- available -- available
-- MUST be present if an update of the root CA certificate -- MUST be present if an update of the root CA certificate
-- is available and MUST be of type RootCaKeyUpdateContent -- is available and MUST be of type RootCaKeyUpdateContent
newWithNew REQUIRED newWithNew REQUIRED
-- MUST be present if infoValue is present -- MUST be present if infoValue is present
-- MUST contain the new root CA certificate -- MUST contain the new root CA certificate
newWithOld REQUIRED newWithOld REQUIRED
-- MUST be present if infoValue is present -- MUST be present if infoValue is present
-- MUST contain a certificate containing the new public -- MUST contain a certificate containing the new public
-- root CA key signed with the old private root CA key -- root CA key signed with the old private root CA key
oldWithNew OPTIONAL oldWithNew OPTIONAL
-- MAY be present if infoValue is present -- MAY be present if infoValue is present
-- MUST contain a certificate containing the old public -- MUST contain a certificate containing the old public
-- root CA key signed with the new private root CA key -- root CA key signed with the new private root CA key
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="EE_Temp" numbered="true" toc="default"> <section anchor="EE_Temp" numbered="true" toc="default">
<name>Get Certificate Request Template</name> <name>Get Certificate Request Template</name>
<t>This PKI management operation can be used by an EE to request a tem plate with parameters for future certificate requests.</t> <t>This PKI management operation can be used by an EE to request a tem plate with parameters for future certificate requests.</t>
<t>An EE requests certificate request parameters from the PKI m <t>An EE requests certificate request parameters from the PKI m
anagement entity by sending a general message with OID id-it-certReqTemplate as anagement entity by sending a general message with OID id-it-certReqTemplate as
specified in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Upda specified in <xref target="RFC9480" format="default" sectionFormat="of" section=
tes Section 2.16</xref>. The EE MAY indicate the certificate profile to use in "2.16">CMP Updates</xref>. The EE <bcp14>MAY</bcp14> indicate the certificate p
the id-it-certProfile extension of the generalInfo field in the PKIHeader of the rofile to use in the id-it-certProfile extension of the generalInfo field in the
general message as described in <xref target="Header" format="default"/>. The PKIHeader of the general message as described in <xref target="Header" format="
PKI management entity responds with a general response with the same OID that ei default"/>. The PKI management entity responds with a general response with the
ther contains requirements on the certificate request template, or with no conte same OID that either contains requirements on the certificate request template
nt in case no specific requirements are imposed by the PKI. The CertReqTemplateV or no content in case no specific requirements are imposed by the PKI. The CertR
alue contains requirements on certificate fields and extensions in a certTemplat eqTemplateValue contains requirements on certificate fields and extensions in a
e. Optionally it contains a keySpec field containing requirements on algorithms certTemplate. Optionally, it contains a keySpec field containing requirements on
acceptable for key pair generation.</t> algorithms acceptable for key pair generation.</t>
<t>The EE SHOULD follow the requirements from the received CertTemplat <t>The EE <bcp14>SHOULD</bcp14> follow the requirements from the recei
e, by including in the certificate requests all the fields requested, taking ove ved CertTemplate by including in the certificate requests all the fields request
r all the field values provided and filling in any remaining fields values. The ed, taking over all the field values provided and filling in any remaining field
EE SHOULD NOT add further fields, name components, and extensions or their (sub- s values. The EE <bcp14>SHOULD NOT</bcp14> add further fields, name components,
)components. If deviating from the recommendations of the template, the certifi and extensions or their (sub)components. If deviating from the recommendations
cate request might be rejected.</t> of the template, the certificate request might be rejected.</t>
<t>Note: We deliberately do not use "MUST" or "MUST NOT" here in order <t>Note: We deliberately do not use "<bcp14>MUST</bcp14>" or "<bcp14>M
to allow more flexibility in case the rules given here are not sufficient for s UST NOT</bcp14>" here in order to allow more flexibility in case the rules given
pecific scenarios. The EE can populate the certificate request as wanted and ign here are not sufficient for specific scenarios. The EE can populate the certifi
ore any of the requirements contained in the CertReqTemplateValue. On the other cate request as wanted and ignore any of the requirements contained in the CertR
hand, a PKI management entity is free to ignore or replace any parts of the cont eqTemplateValue. On the other hand, a PKI management entity is free to ignore or
ent of the certificate request provided by the EE. The CertReqTemplate PKI manag replace any parts of the content of the certificate request provided by the EE.
ement operation offers means to ease a joint understanding which fields and/or w The CertReqTemplate PKI management operation offers means to ease a joint under
hich field values should be used. An example is provided in <xref target="Param_ standing of which fields and/or which field values should be used. An example is
Example" format="default"/>.</t> provided in <xref target="Param_Example" format="default"/>.</t>
<t>In case a field of type Name, e.g., subject, is present in the Cert <t>In case a field of type Name, e.g., subject, is present in the Cert
Template but has the value NULL-DN (i.e., has an empty list of RDN components), Template but has the value NULL-DN (i.e., has an empty list of relative distingu
the field SHOULD be included in the certificate request and filled with content ished name (RDN) components), the field <bcp14>SHOULD</bcp14> be included in the
provided by the EE. Similarly, in case an X.509v3 extension is present but its e certificate request and filled with content provided by the EE. Similarly, in c
xtnValue is empty, this means that the extension SHOULD be included and filled w ase an X.509v3 extension is present but its extnValue is empty, this means that
ith content provided by the EE. In case a Name component, for instance a common the extension <bcp14>SHOULD</bcp14> be included and filled with content provided
name or serial number, is given but has an empty string value, the EE SHOULD fil by the EE. In case a Name component, for instance, a common name or serial numb
l in a value. Similarly, in case an extension has sub-components (e.g., an IP ad er, is given but has an empty string value, the EE <bcp14>SHOULD</bcp14> fill in
dress in a SubjectAltName field) with empty value, the EE SHOULD fill in a value a value. Similarly, in case an extension has subcomponents (e.g., an IP address
.</t> in a SubjectAltName field) with empty values, the EE <bcp14>SHOULD</bcp14> fill
<t>The EE MUST ignore (i.e., not include and fill in) empty fields, ex in a value.</t>
tensions, and sub-components that it does not understand or does not know suitab <t>The EE <bcp14>MUST</bcp14> ignore (i.e., not include) empty fields,
le values to be filled in.</t> extensions, and subcomponents that it does not understand or does not know suit
<t>The publicKey field of type SubjectPublicKeyInfo in the CertTemplat able values to fill in.</t>
e of the CertReqTemplateValue MUST be omitted. In case the PKI management entity <t>The publicKey field of type SubjectPublicKeyInfo in the CertTemplat
wishes to make stipulation on algorithms the EE may use for key generation, thi e of the CertReqTemplateValue <bcp14>MUST</bcp14> be omitted. In case the PKI ma
s MUST be specified using the keySpec field as specified in <xref target="I-D.ie nagement entity wishes to make a stipulation on algorithms the EE may use for ke
tf-lamps-cmp-updates" format="default">CMP Updates Section 2.16</xref>.</t> y generation, this <bcp14>MUST</bcp14> be specified using the keySpec field as s
<t>The keySpec field, if present, specifies the public key types optio pecified in <xref target="RFC9480" format="default" sectionFormat="of" section="
nally with parameters, and/or RSA key lengths for which a certificate may be req 2.16">CMP Updates</xref>.</t>
uested.</t> <t>The keySpec field, if present, specifies the public key types optio
<t>The value of a keySpec element with the OID id-regCtrl-algId, as sp nally with parameters and/or RSA key lengths for which a certificate may be requ
ecified in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Update ested.</t>
s Section 2.16</xref>, MUST be of type AlgorithmIdentifier and give an algorithm <t>The value of a keySpec element with the OID id-regCtrl-algId, as sp
other than RSA. For EC keys the curve information MUST be specified as describ ecified in <xref target="RFC9480" format="default" sectionFormat="of" section="2
ed in the respective standard documents.</t> .16">CMP Updates</xref>, <bcp14>MUST</bcp14> be of type AlgorithmIdentifier and
<t>The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, a give an algorithm other than RSA. For Elliptic Curve (EC) keys, the curve infor
s specified in <xref target="I-D.ietf-lamps-cmp-updates" format="default">CMP Up mation <bcp14>MUST</bcp14> be specified as described in the respective standard
dates Section 2.16</xref>, MUST be a positive integer value and give an RSA key documents.</t>
length.</t> <t>The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, a
<t>In the CertTemplate of the CertReqTemplateValue the serialNumber, s s specified in <xref target="RFC9480" format="default" sectionFormat="of" sectio
igningAlg, issuerUID, and subjectUID fields MUST be omitted.</t> n="2.16">CMP Updates</xref>, <bcp14>MUST</bcp14> be a positive integer value and
<t keepWithNext="true">Specific prerequisites augmenting the prerequis give an RSA key length.</t>
ites in <xref target="Prereq" format="default"/>:</t> <t>In the CertTemplate of the CertReqTemplateValue, the serialNumber,
signingAlg, issuerUID, and subjectUID fields <bcp14>MUST</bcp14> be omitted.</t>
<t keepWithNext="true">The specific prerequisites augmenting the prere
quisites in <xref target="Prereq" format="default"/> is as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile.</li> <li>When using the generalInfo field certProfile, the EE <bcp14>MUST< /bcp14> know the identifier needed to indicate the requested certificate profile .</li>
</ul> </ul>
<t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t> <t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t>
<ol spacing="normal" type="%d"> <ol spacing="normal" type="1">
<li>the infoType OID to use is id-it-certReqTemplate</li> <li>the infoType OID to use is id-it-certReqTemplate</li>
<li>the id-it-certProfile generalInfo field in the header of the req <li>the id-it-certProfile generalInfo field in the header of the req
uest MAY contain the name of the requested certificate request template</li> uest <bcp14>MAY</bcp14> contain the name of the requested certificate request te
<li>the infoValue of the request MUST be absent</li> mplate</li>
<li>if present, the infoValue of the response MUST be a CertReqTempl <li>the infoValue of the request <bcp14>MUST</bcp14> be absent</li>
ateValue containing a CertTemplate structure and an optional keySpec field</li> <li>if present, the infoValue of the response <bcp14>MUST</bcp14> be
a CertReqTemplateValue containing a CertTemplate structure and an optional keyS
pec field</li>
</ol> </ol>
<t keepWithNext="true">Detailed Description of infoValue Field of genp <t keepWithNext="true">Detailed Description of the infoValue Field of
:</t> genp:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
InfoValue OPTIONAL InfoValue OPTIONAL
-- MUST be absent if no requirements are available -- MUST be absent if no requirements are available
-- MUST be present if the PKI management entity has any -- MUST be present if the PKI management entity has any
-- requirements on the contents of the certificate template -- requirements on the contents of the certificate template
certTemplate REQUIRED certTemplate REQUIRED
-- MUST be present if infoValue is present -- MUST be present if infoValue is present
-- MUST contain the required CertTemplate structure elements -- MUST contain the required CertTemplate structure elements
-- The SubjectPublicKeyInfo field MUST be absent -- The SubjectPublicKeyInfo field MUST be absent
keySpec OPTIONAL keySpec OPTIONAL
-- MUST be absent if no requirements on the public key are -- MUST be absent if no requirements on the public key are
-- available -- available
-- MUST be present if the PKI management entity has any -- MUST be present if the PKI management entity has any
-- requirements on the keys generated -- requirements on the keys generated
-- MUST contain a sequence of one AttributeTypeAndValue per -- MUST contain a sequence of one AttributeTypeAndValue per
-- supported algorithm with attribute id-regCtrl-algId or -- supported algorithm with attribute id-regCtrl-algId or
-- id-regCtrl-rsaKeyLen -- id-regCtrl-rsaKeyLen
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="EE_CRLs" numbered="true" toc="default"> <section anchor="EE_CRLs" numbered="true" toc="default">
<name>CRL Update Retrieval</name> <name>CRL Update Retrieval</name>
<t>This PKI management operation can be used by an EE to request a new <t>This PKI management operation can be used by an EE to request a new
CRL. If a CA offers methods to access a CRL, it may include CRL distribution p CRL. If a CA offers methods to access a CRL, it may include CRL distribution p
oints or authority information access extensions as specified in <xref target="R oints or authority information access extensions into the issued certificates as
FC5280" format="default">RFC&nbsp;5280</xref> into the issued certificates. In specified in <xref target="RFC5280" format="default"/>. In addition, CMP offer
addition, CMP offers CRL provisioning functionality as part of the PKI managemen s CRL provisioning functionality as part of the PKI management operation.</t>
t operation.</t> <t>An EE requests a CRL update from the PKI management entity by sendi
<t>An EE requests a CRL update from the PKI management entity by sendi ng a general message with OID id-it-crlStatusList. The EE <bcp14>MUST</bcp14> i
ng a general message with OID id-it-crlStatusList. The EE MUST include the CRL nclude the CRL source identifying the requested CRL and, if available, the thisU
source identifying the requested CRL and, if available, the thisUpdate time of t pdate time of the most current CRL instance it already has, as specified in <xre
he most current CRL instance it already has, as specified in <xref target="I-D.i f target="RFC9480" format="default" sectionFormat="of" section="2.17">CMP Update
etf-lamps-cmp-updates" format="default">CMP Updates Section 2.17</xref>. The PK s</xref>. The PKI management entity <bcp14>MUST</bcp14> respond with a general
I management entity MUST respond with a general response with OID id-it-crls.</t response with OID id-it-crls.</t>
> <t>The EE <bcp14>MUST</bcp14> identify the requested CRL either
<t>The EE MUST identify the requested CRL either by a CRL distr by a CRL distribution point name or issuer name.</t>
ibution point name or issuer name.</t>
<t>Note: CRL distribution point names can be obtained from a cR LDistributionPoints extension of a certificate to be validated or from an issuin gDistributionPoint extension of the CRL to be updated. CRL issuer names can be o btained from the cRLDistributionPoints extension of a certificate, from the issu er field of the authority key identifier extension of a certificate or CRL, and from the issuer field of a certificate or CRL.</t> <t>Note: CRL distribution point names can be obtained from a cR LDistributionPoints extension of a certificate to be validated or from an issuin gDistributionPoint extension of the CRL to be updated. CRL issuer names can be o btained from the cRLDistributionPoints extension of a certificate, from the issu er field of the authority key identifier extension of a certificate or CRL, and from the issuer field of a certificate or CRL.</t>
<t>If a thisUpdate value was given, the PKI management entity M UST return the latest CRL available from the referenced source if this CRL is mo re recent than the given thisUpdate time. If no thisUpdate value was given, it MUST return the latest CRL available from the referenced source. In all other c ases the infoValue in the response message MUST be absent.</t> <t>If a thisUpdate value was given, the PKI management entity < bcp14>MUST</bcp14> return the latest CRL available from the referenced source if this CRL is more recent than the given thisUpdate time. If no thisUpdate value was given, it <bcp14>MUST</bcp14> return the latest CRL available from the refe renced source. In all other cases, the infoValue in the response message <bcp14 >MUST</bcp14> be absent.</t>
<t>The PKI management entity should treat a CRL distribution po int name as an internal pointer to identify a CRL that is directly available at the PKI management entity. It is not intended as a way to fetch an arbitrary CR L from an external location, as this location may be unavailable to that PKI man agement entity.</t> <t>The PKI management entity should treat a CRL distribution po int name as an internal pointer to identify a CRL that is directly available at the PKI management entity. It is not intended as a way to fetch an arbitrary CR L from an external location, as this location may be unavailable to that PKI man agement entity.</t>
<t>In addition to the prerequisites specified in <xref target="Prereq" <t>In addition to the prerequisites specified in <xref target="Prereq"
format="default"/>, the EE MUST know which CRL to request.</t> format="default"/>, the EE <bcp14>MUST</bcp14> know which CRL to request.</t>
<t>Note: If the EE does not want to request a specific CRL it MAY use <t>Note: If the EE does not want to request a specific CRL, it <bcp14>
instead a general message with OID id-it-currentCrl as specified in <xref target MAY</bcp14> instead use a general message with OID id-it-currentCrl as specified
="RFC4210" format="default">RFC&nbsp;4210 Section 5.3.19.6</xref>.</t> in <xref target="RFC4210" format="default" sectionFormat="of" section="5.3.19.6
"/>.</t>
<t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t> <t keepWithNext="true">The message sequence for this PKI management op eration is as given above, with the following specific content:</t>
<ol spacing="normal" type="%d"> <ol spacing="normal" type="1">
<li>the infoType OID to use is id-it-crlStatusList in the req uest and id-it-crls in the response</li> <li>the infoType OID to use is id-it-crlStatusList in the req uest and id-it-crls in the response</li>
<li>the infoValue of the request MUST be present and contain <li>the infoValue of the request <bcp14>MUST</bcp14> be prese
a sequence of one CRLStatus structure</li> nt and contain a sequence of one CRLStatus structure</li>
<li>if present, the infoValue of the response MUST contain a <li>if present, the infoValue of the response <bcp14>MUST</bc
sequence of one CRL</li> p14> contain a sequence of one CRL</li>
</ol> </ol>
<t keepWithNext="true">Detailed Description of infoValue Field of genm <t keepWithNext="true">Detailed Description of the infoValue Field of
:</t> genm:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
infoValue REQUIRED infoValue REQUIRED
-- MUST contain a sequence of one CRLStatus element -- MUST contain a sequence of one CRLStatus element
source REQUIRED source REQUIRED
-- MUST contain the dpn choice of type DistributionPointName if -- MUST contain the dpn choice of type DistributionPointName if
-- the CRL distribution point name is available -- the CRL distribution point name is available
-- Otherwise, MUST contain the issuer choice identifying the CA -- Otherwise, MUST contain the issuer choice identifying the CA
-- that issues the CRL. It MUST contain the issuer DN in the -- that issues the CRL. It MUST contain the issuer DN in the
-- directoryName field of a GeneralName element. -- directoryName field of a GeneralName element.
thisUpdate OPTIONAL thisUpdate OPTIONAL
-- MUST contain the thisUpdate field of the latest CRL the EE -- MUST contain the thisUpdate field of the latest CRL the EE
-- has got from the issuer specified in the given dpn or -- has gotten from the issuer specified in the given dpn or
-- issuer field -- issuer field
-- MUST be omitted if the EE does not have any instance of the -- MUST be omitted if the EE does not have any instance of the
-- requested CRL -- requested CRL
]]></artwork> ]]></sourcecode>
<t keepWithNext="true">Detailed Description of infoValue Field of genp <t keepWithNext="true">Detailed Description of the infoValue Field of
:</t> genp:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no CRL to be returned is available -- MUST be absent if no CRL to be returned is available
-- MUST contain a sequence of one CRL update from the referenced -- MUST contain a sequence of one CRL update from the referenced
-- source, if a thisUpdate value was not given or a more recent -- source if a thisUpdate value was not given or a more recent
-- CRL is available -- CRL is available
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="EE_Polling" numbered="true" toc="default"> <section anchor="EE_Polling" numbered="true" toc="default">
<name>Handling Delayed Delivery</name> <name>Handling Delayed Delivery</name>
<t>This is a variant of all PKI management operations described in this d ocument. It is initiated in case a PKI management entity cannot respond to a re quest message in a timely manner, typically due to offline or asynchronous upstr eam communication, or due to delays in handling the request. The polling mechani sm has been specified in <xref target="RFC4210" format="default">RFC&nbsp;4210 S ection 5.3.22</xref> and updated by <xref target="I-D.ietf-lamps-cmp-updates" fo rmat="default"/>.</t> <t>This is a variant of all PKI management operations described in this d ocument. It is initiated in case a PKI management entity cannot respond to a re quest message in a timely manner, typically due to offline or asynchronous upstr eam communication or due to delays in handling the request. The polling mechanis m has been specified in <xref target="RFC4210" format="default" sectionFormat="o f" section="5.3.22"/> and updated by <xref target="RFC9480" format="default"/>.< /t>
<t>Depending on the PKI architecture, the entity initiating delayed deliv ery is not necessarily the PKI management entity directly addressed by the EE.</ t> <t>Depending on the PKI architecture, the entity initiating delayed deliv ery is not necessarily the PKI management entity directly addressed by the EE.</ t>
<t>When initiating delayed delivery of a message received from an EE, the <t>When initiating delayed delivery of a message received from an EE, the
PKI management entity MUST respond with a message including the status "waiting PKI management entity <bcp14>MUST</bcp14> respond with a message including the
". In response to an ir/cr/kur/p10cr message it must place the status "waiting" status "waiting". In response to an ir/cr/kur/p10cr message, it must place the s
in an ip/cp/kup message, otherwise in an error message. On receiving this resp tatus "waiting" in an ip/cp/kup message and for responses to other request messa
onse, the EE MUST store in its transaction context the senderNonce of the preced ge types in an error message. On receiving this response, the EE <bcp14>MUST</b
ing request message because this value will be needed for checking the recipNonc cp14> store in its transaction context the senderNonce of the preceding request
e of the final response to be received after polling. It sends a poll request wi message because this value will be needed for checking the recipNonce of the fin
th certReqId 0 if referring to the CertResponse element contained in the ip/cp/k al response to be received after polling. It sends a poll request with certReqId
up message, else -1 to refer to the whole message. In case the final response i 0 if referring to the CertResponse element contained in the ip/cp/kup message,
s not yet available, the PKI management entity that initiated the delayed delive else -1 to refer to the whole message. In case the final response is not yet av
ry MUST answer with a poll response, with the same certReqId. The included chec ailable, the PKI management entity that initiated the delayed delivery <bcp14>MU
kAfter time value indicates the minimum number of seconds that should elapse bef ST</bcp14> answer with a poll response with the same certReqId. The included ch
ore the EE sends a new pollReq message to the PKI management entity. Polling ea eckAfter time value indicates the minimum number of seconds that should elapse b
rlier than indicated by the checkAfter value may increase the number of messages efore the EE sends a new pollReq message to the PKI management entity. Polling
roundtrips. This is repeated until a final response is available or any party earlier than indicated by the checkAfter value may increase the number of messag
involved gives up on the current PKI management operation, i.e., a timeout occur e round trips. This is repeated until a final response is available or any part
s.</t> y involved gives up on the current PKI management operation, i.e., a timeout occ
<t>When the PKI management entity that initiated delayed delivery can urs.</t>
provide the final response for the original request message of the EE, it MUST s <t>When the PKI management entity that initiated delayed delivery can
end this response to the EE. Using this response, the EE can continue the curre provide the final response for the original request message of the EE, it <bcp14
nt PKI management operation as usual.</t> >MUST</bcp14> send this response to the EE. Using this response, the EE can con
tinue the current PKI management operation as usual.</t>
<t>No specific prerequisites apply in addition to those of the respective PKI management operation.</t> <t>No specific prerequisites apply in addition to those of the respective PKI management operation.</t>
<t keepWithNext="true">Message Flow:</t> <t keepWithNext="true">Message Flow:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
Step# EE PKI management entity Step# EE PKI management entity
1 format request 1 format request
message message
2 -> request -> 2 -> request ->
3 handle or forward 3 handle or forward
request request
4 format ip/cp/kup/error 4 format ip/cp/kup/error
with status "waiting" with status "waiting"
response in case no response in case no
immediate final response immediate final response
is available, is available
5 <- ip/cp/kup/error <- 5 <- ip/cp/kup/error <-
6 handle 6 handle
ip/cp/kup/error ip/cp/kup/error
with status with status
"waiting" "waiting"
-------------------------- start polling -------------------------- -------------------------- start polling --------------------------
7 format pollReq 7 format pollReq
8 -> pollReq -> 8 -> pollReq ->
skipping to change at line 1686 skipping to change at line 1664
12 handle pollRep 12 handle pollRep
13 let checkAfter 13 let checkAfter
time elapse and time elapse and
continue with continue with
step 7 step 7
----------------- end polling, continue as usual ------------------ ----------------- end polling, continue as usual ------------------
14 format or receive 14 format or receive
final response on final response on
original request the original request
15 <- response <- 15 <- response <-
16 handle final 16 handle final
response response
]]></artwork> ]]></artwork>
<t keepWithNext="true">Detailed Message Description:</t> <t keepWithNext="true">Detailed Message Description:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
Response with Status "waiting" -- ip/cp/kup/error Response with Status "waiting" -- ip/cp/kup/error
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- As described for the respective PKI management operation, with -- As described for the respective PKI management operation, with
-- the following adaptations: -- the following adaptations:
status REQUIRED -- in case of ip/cp/kup status REQUIRED -- in case of ip/cp/kup
pKIStatusInfo REQUIRED -- in case of error response pKIStatusInfo REQUIRED -- in case of error response
-- PKIStatusInfo structure MUST be present -- PKIStatusInfo structure MUST be present
status REQUIRED status REQUIRED
-- MUST be status "waiting" -- MUST be status "waiting"
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging or to -- MAY be any human-readable text for debugging, for logging, or
-- display in a GUI -- to display in a GUI
failInfo PROHIBITED failInfo PROHIBITED
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
extraCerts OPTIONAL extraCerts OPTIONAL
-- As described in Section 3.3 -- As described in Section 3.3
Polling Request -- pollReq Polling Request -- pollReq
skipping to change at line 1761 skipping to change at line 1739
body body
-- The message indicates the delay after which the EE SHOULD -- The message indicates the delay after which the EE SHOULD
-- send another pollReq message for this transaction -- send another pollReq message for this transaction
pollRep REQUIRED pollRep REQUIRED
certReqId REQUIRED certReqId REQUIRED
-- MUST be 0 if referring to a CertResponse element, else -1 -- MUST be 0 if referring to a CertResponse element, else -1
checkAfter REQUIRED checkAfter REQUIRED
-- MUST be the time in seconds to elapse before a new pollReq -- MUST be the time in seconds to elapse before a new pollReq
-- should be sent -- should be sent
reason OPTIONAL reason OPTIONAL
-- MAY be any human-readable text for debugging, logging or to -- MAY be any human-readable text for debugging, for logging, or
-- display in a GUI -- to display in a GUI
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
-- MUST use the same credentials as in the first response -- MUST use the same credentials as in the first response
-- message of the PKI management operation -- message of the PKI management operation
extraCerts RECOMMENDED extraCerts RECOMMENDED
-- As described in Section 3.3 -- As described in Section 3.3
-- MAY be omitted if the message size is critical and the EE has -- MAY be omitted if the message size is critical and the EE has
-- cached the CMP protection certificate from the first -- cached the CMP protection certificate from the first
-- response message of the PKI management operation -- response message of the PKI management operation
Final Response - Any Type of Response Message Final Response - Any Type of Response Message
Field Value Field Value
header header
-- MUST be the header as described for the response message -- MUST be the header, as described for the response message
-- of the respective PKI management operation -- of the respective PKI management operation
body body
-- The response of the PKI management entity to the initial -- The response of the PKI management entity to the initial
-- request as described in the respective PKI management -- request, as described in the respective PKI management
-- operation -- operation
protection REQUIRED protection REQUIRED
-- MUST be as described for the response message of the -- MUST be as described for the response message of the
-- respective PKI management operation -- respective PKI management operation
extraCerts REQUIRED extraCerts REQUIRED
-- MUST be as described for the response message of the -- MUST be as described for the response message of the
-- respective PKI management operation -- respective PKI management operation
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="RA_UseCases" numbered="true" toc="default"> <section anchor="RA_UseCases" numbered="true" toc="default">
<name>PKI Management Entity Operations</name> <name>PKI Management Entity Operations</name>
<t>This section focuses on request processing by a PKI management entity. Depending on the network and PKI solution design, this can be an RA or CA, any of which may include protocol conversion or central key generation (i.e., acting as a KGA).</t> <t>This section focuses on request processing by a PKI management entity. Depending on the network and PKI solution design, this can be an RA or CA, any of which may include protocol conversion or central key generation (i.e., acting as a KGA).</t>
<t>A PKI management entity may directly respond to request messages from d ownstream and report errors. In case the PKI management entity is an RA it typic ally forwards the received request messages upstream after checking them and for wards respective response messages downstream. Besides responding to messages o r forwarding them, a PKI management entity may request or revoke certificates on behalf of EEs. A PKI management entity may also need to manage its own certific ates and thus act as an EE using the PKI management operations specified in <xre f target="EE_UseCases" format="default"/>.</t> <t>A PKI management entity may directly respond to request messages from d ownstream and report errors. In case the PKI management entity is an RA, it typi cally forwards the received request messages upstream after checking them and fo rwards respective response messages downstream. Besides responding to messages or forwarding them, a PKI management entity may request or revoke certificates o n behalf of EEs. A PKI management entity may also need to manage its own certifi cates and thus act as an EE using the PKI management operations specified in <xr ef target="EE_UseCases" format="default"/>.</t>
<section anchor="RA_response" numbered="true" toc="default"> <section anchor="RA_response" numbered="true" toc="default">
<name>Responding to Requests</name> <name>Responding to Requests</name>
<t>The PKI management entity terminating the PKI management operation at <t>The PKI management entity terminating the PKI management operation at
CMP level MUST respond to all received requests by returning a related CMP resp CMP level <bcp14>MUST</bcp14> respond to all received requests by returning a r
onse message or an error. Any intermediate PKI management entity MAY respond dep elated CMP response message or an error. Any intermediate PKI management entity
ending on the PKI configuration and policy.</t> <bcp14>MAY</bcp14> respond, depending on the PKI configuration and policy.</t>
<t>In addition to the checks described in <xref target="Validation" form <t>In addition to the checks described in <xref target="Validation" form
at="default"/>, the responding PKI management entity MUST check that a request t at="default"/>, the responding PKI management entity <bcp14>MUST</bcp14> check t
hat initiates a new PKI management operation does not use a transactionID that i hat a request that initiates a new PKI management operation does not use a trans
s currently in use. The failInfo bit value to use is transactionIdInUse as desc actionID that is currently in use. The failInfo bit value to use is transaction
ribed in <xref target="Error_reporting" format="default"/>. If any of these ver IdInUse as described in <xref target="Error_reporting" format="default"/>. If a
ification steps or any of the essential checks described in <xref target="Valida ny of these verification steps or any of the essential checks described in <xref
tion" format="default"/> and in the following subsections fails, the PKI managem target="Validation" format="default"/> and in the following subsections fails,
ent entity MUST proceed as described in <xref target="Error" format="default"/>. the PKI management entity <bcp14>MUST</bcp14> proceed as described in <xref targ
</t> et="Error" format="default"/>.</t>
<t>The responding PKI management entity MUST copy the sender field of th <t>The responding PKI management entity <bcp14>MUST</bcp14> copy the sen
e request to the recipient field of the response, MUST copy the senderNonce of t der field of the request to the recipient field of the response, <bcp14>MUST</bc
he request to the recipNonce of the response, and MUST use the same transactionI p14> copy the senderNonce of the request to the recipNonce of the response, and
D for the response.</t> <bcp14>MUST</bcp14> use the same transactionID for the response.</t>
<section anchor="RA_response_enrollment" numbered="true" toc="def ault"> <section anchor="RA_response_enrollment" numbered="true" toc="def ault">
<name>Responding to a Certificate Request</name> <name>Responding to a Certificate Request</name>
<t>An ir/cr/kur/p10cr message is used to request a certif <t>An ir/cr/kur/p10cr message is used to request a certif
icate as described in <xref target="EE_request" format="default"/>. The respondi icate as described in <xref target="EE_request" format="default"/>. The respondi
ng PKI management entity MUST proceed as follows unless it initiates delayed del ng PKI management entity <bcp14>MUST</bcp14> proceed as follows unless it initia
ivery as described in <xref target="RA_response_polling" format="default"/>.</t> tes delayed delivery as described in <xref target="RA_response_polling" format="
<t>The PKI management entity MUST check the message body default"/>.</t>
according to the applicable requirements from <xref target="EE_request" format=" <t>The PKI management entity <bcp14>MUST</bcp14> check th
default"/>. Possible failInfo bit values used for error reporting in case a chec e message body according to the applicable requirements from <xref target="EE_re
k failed include badCertId and badCertTemplate. It MUST verify the presence and quest" format="default"/>. Possible failInfo bit values used for error reporting
value of the proof-of-possession (failInfo bit: badPOP), unless central key gene in case a check failed include badCertId and badCertTemplate. It <bcp14>MUST</b
ration is requested. In case the special POP value "raVerified" is given, it sho cp14> verify the presence and value of the proof-of-possession (failInfo bit: ba
uld check that the request message was signed using a certificate containing the dPOP) unless central key generation is requested. If a signature-based proof-of-
cmcRA extended key usage (failInfo bit: notAuthorized). The PKI management enti possession is present, the PKI management entity <bcp14>MUST</bcp14> verify, bas
ty should also perform any further checks on the certTemplate contents (failInfo ed on local PKI policy, that the subject name in the certTemplate identifies the
: badCertTemplate) according to any applicable PKI policy and certificate profil same entity as the subject name in the CMP protection certificate or matches th
e.</t> e identifier used with MAC-based protection. In case this verification fails, t
<t>If the requested certificate is available, the PKI man he message <bcp14>MUST</bcp14> have been protected by an authorized PKI manageme
agement entity MUST respond with a positive ip/cp/kup message as described in <x nt entity (failInfo bit: notAuthorized). If the special POP value "raVerified"
ref target="EE_request" format="default"/>.</t> is given, the PKI management entity should check that the request message was si
<t>Note: If central key generation is performed by the re gned using a certificate containing the cmcRA extended key usage (failInfo bit:
sponding PKI management entity, the responding PKI management entity MUST includ notAuthorized). The PKI management entity should also perform any further checks
e the private key in encrypted form in the response as specified in <xref target on the certTemplate contents (failInfo: badCertTemplate) according to any appli
="EE_centralKeyGeneration" format="default"/>.</t> cable PKI policy and certificate profile.</t>
<t keepWithNext="true">The prerequisites of the respective PKI manag <t>If the requested certificate is available, the PKI man
ement operation as specified in <xref target="EE_request" format="default"/> app agement entity <bcp14>MUST</bcp14> respond with a positive ip/cp/kup message as
ly.</t> described in <xref target="EE_request" format="default"/>.</t>
<t>If the EE requested omission of the certConf message, <t>Note: If central key generation is performed by the re
the PKI management entity MUST handle it as described in <xref target="EE_newPKI sponding PKI management entity, the responding PKI management entity <bcp14>MUST
" format="default"/>. Therefore, it MAY grant this by including the implicitCon </bcp14> include the private key in encrypted form in the response as specified
firm generalInfo field or include the confirmWaitTime field in the response head in <xref target="EE_centralKeyGeneration" format="default"/>.</t>
er.</t> <t keepWithNext="true">The prerequisites of the respective PKI manag
ement operation specified in <xref target="EE_request" format="default"/> apply.
</t>
<t>If the EE requested omission of the certConf message,
the PKI management entity <bcp14>MUST</bcp14> handle it as described in <xref ta
rget="EE_newPKI" format="default"/>. Therefore, it <bcp14>MAY</bcp14> grant thi
s by including the implicitConfirm generalInfo field or including the confirmWai
tTime field in the response header.</t>
</section> </section>
<section anchor="RA_response_confirmation" numbered="true" toc="d efault"> <section anchor="RA_response_confirmation" numbered="true" toc="d efault">
<name>Responding to a Confirmation Message</name> <name>Responding to a Confirmation Message</name>
<t>A PKI management entity MUST handle a certConf message <t>A PKI management entity <bcp14>MUST</bcp14> handle a c
if it has responded before with a positive ip/cp/kup message not granting impli ertConf message if it has responded before with a positive ip/cp/kup message not
cit confirmation. It should check the message body according to the requirement granting implicit confirmation. It should check the message body according to
s given in <xref target="EE_newPKI" format="default"/> (failInfo bit: badCertId) the requirements given in <xref target="EE_newPKI" format="default"/> (failInfo
and MUST react as described there.</t> bit: badCertId) and <bcp14>MUST</bcp14> react as described there.</t>
<t>The prerequisites of the respective PKI management ope <t>The prerequisites of the respective PKI management ope
ration as specified in <xref target="EE_request" format="default"/> apply.</t> ration specified in <xref target="EE_request" format="default"/> apply.</t>
</section> </section>
<section anchor="RA_response_revocation" numbered="true" toc="def ault"> <section anchor="RA_response_revocation" numbered="true" toc="def ault">
<name>Responding to a Revocation Request</name> <name>Responding to a Revocation Request</name>
<t>An rr message is used to request revocation of a certi ficate. The responding PKI management entity should check the message body accor ding to the requirements in <xref target="EE_Revoke" format="default"/>. It MUST make sure that the referenced certificate exists (failInfo bit: badCertId), has been issued by the addressed CA, and is not already expired or revoked (failInf o bit: certRevoked). On success it MUST respond with a positive rp message as d escribed in <xref target="EE_Revoke" format="default"/>.</t> <t>An rr message is used to request revocation of a certi ficate. The responding PKI management entity should check the message body accor ding to the requirements in <xref target="EE_Revoke" format="default"/>. It <bcp 14>MUST</bcp14> make sure that the referenced certificate exists (failInfo bit: badCertId), has been issued by the addressed CA, and is not already expired or r evoked (failInfo bit: certRevoked). On success, it <bcp14>MUST</bcp14> respond with a positive rp message, as described in <xref target="EE_Revoke" format="def ault"/>.</t>
<t>No specific prerequisites apply in addition to those s pecified in <xref target="Prereq" format="default"/>.</t> <t>No specific prerequisites apply in addition to those s pecified in <xref target="Prereq" format="default"/>.</t>
</section> </section>
<section anchor="RA_response_support" numbered="true" toc="defaul t"> <section anchor="RA_response_support" numbered="true" toc="defaul t">
<name>Responding to a Support Message</name> <name>Responding to a Support Message</name>
<t>A genm message is used to retrieve extra content. The responding PKI management entity should check the message body according to the applicable requirements in <xref target="EE_GeneralMessage" format="default"/> a nd perform any further checks depending on the PKI policy. On success it MUST r espond with a genp message as described there.</t> <t>A genm message is used to retrieve extra content. The responding PKI management entity should check the message body according to the applicable requirements in <xref target="EE_GeneralMessage" format="default"/> a nd perform any further checks depending on the PKI policy. On success, it <bcp1 4>MUST</bcp14> respond with a genp message as described there.</t>
<t>Note: The responding PKI management entity may generat e the response from scratch or reuse the contents of previous responses. Theref ore, it may be worth caching the body of the response message as long as the con tained information is valid and current, such that further requests for the same contents can be answered immediately.</t> <t>Note: The responding PKI management entity may generat e the response from scratch or reuse the contents of previous responses. Theref ore, it may be worth caching the body of the response message as long as the con tained information is valid and current, such that further requests for the same contents can be answered immediately.</t>
<t>No specific prerequisites apply in addition to those s pecified in <xref target="Prereq" format="default"/>.</t> <t>No specific prerequisites apply in addition to those s pecified in <xref target="Prereq" format="default"/>.</t>
</section> </section>
<section anchor="RA_response_polling" numbered="true" toc="default"> <section anchor="RA_response_polling" numbered="true" toc="default">
<name>Initiating Delayed Delivery</name> <name>Initiating Delayed Delivery</name>
<t>This functional extension can be used by a PKI management entity in <t>This functional extension can be used by a PKI management entity in
case the response to a request takes longer than usual. In this case the PKI m case the response to a request takes longer than usual. In this case, the PKI
anagement entity should completely validate the request as usual and then start management entity should completely validate the request as usual and then start
processing the request itself or forward it further upstream as soon as possible processing the request itself or forward it further upstream as soon as possibl
. In the meantime, it MUST respond with an ip/cp/kup/error message including th e. In the meantime, it <bcp14>MUST</bcp14> respond with an ip/cp/kup/error mess
e status "waiting" and handle subsequent polling as described in <xref target="E age including the status "waiting" and handle subsequent polling as described in
E_Polling" format="default"/>.</t> <xref target="EE_Polling" format="default"/>.</t>
<t>Typically, as stated in <xref target="RA_Replace" format="default"/ <t>Typically, as stated in <xref target="RA_Replace" format="default"/
>, an intermediate PKI management entity should not change the sender and recipi >, an intermediate PKI management entity should not change the sender and recipi
ent nonces even in case it modifies a request or a response message. In the spe ent nonces even in case it modifies a request or a response message. In the spe
cial case of delayed delivery initiated by an intermediate PKI management entity cial case of delayed delivery initiated by an intermediate PKI management entity
, there is an exception. Between the EE and this PKI management entity, pollReq , there is an exception. Between the EE and this PKI management entity, pollReq
and pollRep messages are exchanged handling the nonces as usual. Yet when the and pollRep messages are exchanged handling the nonces as usual. Yet when the
final response from upstream has arrived at the PKI management entity, this resp final response from upstream has arrived at the PKI management entity, this resp
onse contains the recipNonce copied (as usual) from the senderNonce in the origi onse contains the recipNonce copied (as usual) from the senderNonce in the origi
nal request message. The PKI management entity that initiated the delayed deliv nal request message. The PKI management entity that initiated the delayed deliv
ery MAY replace the recipNonce in the response message with the senderNonce of t ery <bcp14>MAY</bcp14> replace the recipNonce in the response message with the s
he last received pollReq because the downstream entities, including the EE, migh enderNonce of the last received pollReq because the downstream entities, includi
t expect it in this way. Yet the check specified in Section 3.5 allows to alter ng the EE, might expect it in this way. Yet the check specified in <xref target
natively use the senderNonce of the original request.</t> ="Validation"/> allows alternate use of the senderNonce of the original request.
</t>
<t>No specific prerequisites apply in addition to those of the respective PKI management operation.</t> <t>No specific prerequisites apply in addition to those of the respective PKI management operation.</t>
</section> </section>
</section> </section>
<section anchor="RA_forwarde_messages" numbered="true" toc="default"> <section anchor="RA_forwarde_messages" numbered="true" toc="default">
<name>Forwarding Messages</name> <name>Forwarding Messages</name>
<t>In case the PKI solution consists of intermediate PKI management enti <t>In case the PKI solution consists of intermediate PKI management enti
ties (i.e., LRA or RA), each CMP request message coming from an EE or any other ties (i.e., LRA or RA), each CMP request message coming from an EE or any other
downstream PKI management entity MUST either be forwarded to the next (upstream) downstream PKI management entity <bcp14>MUST</bcp14> either be forwarded to the
PKI management entity as described in this section or answered as described in next (upstream) PKI management entity as described in this section, or answered
<xref target="RA_response" format="default"/>. Any received response message or as described in <xref target="RA_response" format="default"/>. Any received resp
a locally generated error message MUST be forwarded to the next (downstream) PKI onse message or a locally generated error message <bcp14>MUST</bcp14> be forward
entity.</t> ed to the next (downstream) PKI entity.</t>
<t>In addition to the checks described in <xref target="Validation" form <t>In addition to the checks described in <xref target="Validation" form
at="default"/>, the forwarding PKI management entity MAY verify the proof-of-pos at="default"/>, the forwarding PKI management entity <bcp14>MAY</bcp14> verify t
session for ir/cr/kur/p10cr messages. If one of these verification procedures f he proof-of-possession for ir/cr/kur/p10cr messages. If one of these verificati
ails, the RA proceeds as described in <xref target="Error" format="default"/>.</ on procedures fails, the RA proceeds as described in <xref target="Error" format
t> ="default"/>.</t>
<t>A PKI management entity SHOULD NOT change the received message unless <t>A PKI management entity <bcp14>SHOULD NOT</bcp14> change the received
its role in the PKI system requires it. This is because changes to the message message unless its role in the PKI system requires it. This is because changes
header or body imply re-protection. Changes to the protection breaks end-to-end to the message header or body imply reprotection. Changes to the protection bre
authentication of the message source. Changes to the certificate template in a aks end-to-end authentication of the message source. Changes to the certificate
certificate request breaks proof-of-possession. More details are available in t template in a certificate request breaks proof-of-possession. More details are
he following sub-sections. Concrete PKI system specifications may define in mor available in the following subsections. Concrete PKI system specifications may
e detail when to do so.</t> define when to do so in more detail.</t>
<t>This is particularly relevant in the upstream communication of a requ est message.</t> <t>This is particularly relevant in the upstream communication of a requ est message.</t>
<t keepWithNext="true">Each forwarding PKI management entity has one or more functionalities. It may</t> <t keepWithNext="true">Each forwarding PKI management entity has one or more functionalities. It may:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>verify the identities of EEs and make authorization decisions for certification request processing based on local PKI policy,</li> <li>verify the identities of EEs and make authorization decisions for certification request processing based on local PKI policy,</li>
<li>add or modify fields of certificate request messages,</li> <li>add or modify fields of certificate request messages,</li>
<li>replace a MAC-based protection by a signature-based protection tha t can be verified also further upstream, and vice versa,</li> <li>replace a MAC-based protection with a signature-based protection t hat can also be verified further upstream and vice versa,</li>
<li>double-check if the messages transferred back and forth are proper ly protected and well-formed,</li> <li>double-check if the messages transferred back and forth are proper ly protected and well-formed,</li>
<li>provide an authentic indication that it has performed all required checks,</li> <li>provide an authentic indication that it has performed all required checks,</li>
<li>initiate a delayed delivery due to delays transferring messages or handling requests, or</li> <li>initiate a delayed delivery due to delays transferring messages or handling requests, or</li>
<li>collect messages from multiple RAs and forward them jointly.</li> <li>collect messages from multiple RAs and forward them jointly.</li>
</ul> </ul>
<t>Note: PKI management entities forwarding messages may also sto re data from a message in a database for later usage or audit purposes. They may also support traversal of a network boundary.</t> <t>Note: PKI management entities forwarding messages may also sto re data from a message in a database for later usage or audit purposes. They may also support traversal of a network boundary.</t>
<t keepWithNext="true">The decision if a message should be forwarded</t> <t keepWithNext="true">The decision if a message should be forwarded is: </t>
<ul spacing="normal"> <ul spacing="normal">
<li>unchanged with the original protection,</li> <li>unchanged with the original protection,</li>
<li>unchanged with an additional protection, or</li> <li>unchanged with an additional protection, or</li>
<li>changed with an additional protection</li> <li>changed with an additional protection</li>
</ul> </ul>
<t>depends on the PKI solution design and the associated security policy <t>depending on the PKI solution design and the associated security poli
(<xref target="RFC3647" format="default">CP/CPS</xref>).</t> cy, e.g., as defined in the <xref target="RFC3647" format="default">certificate
<t keepWithNext="true">A PKI management entity SHOULD add or MAY replace policy (CP) / certification practice statement (CPS) documents</xref>.</t>
a protection of a message if it</t> <t keepWithNext="true">A PKI management entity <bcp14>SHOULD</bcp14> add
or <bcp14>MAY</bcp14> replace a protection of a message if it</t>
<ul spacing="normal"> <ul spacing="normal">
<li>needs to securely indicate that it has done checks or validations on the message to one of the next (upstream) PKI management entity or</li> <li>needs to securely indicate that it has done checks or validations on the message to one of the next (upstream) PKI management entities or</li>
<li>needs to protect the message using a key and certificate from a di fferent PKI.</li> <li>needs to protect the message using a key and certificate from a di fferent PKI.</li>
</ul> </ul>
<t>If remaining end-to-end message authentication is required, an <t>If retaining end-to-end message authentication is required, an
additional protection SHALL be added instead of replacing the original protecti additional protection <bcp14>SHALL</bcp14> be added instead of replacing the or
on.</t> iginal protection.</t>
<t keepWithNext="true">A PKI management entity MUST replace a protection <t keepWithNext="true">A PKI management entity <bcp14>MUST</bcp14> repla
of a message if it</t> ce a protection of a message if it</t>
<ul spacing="normal"> <ul spacing="normal">
<li>performs changes to the header or the body of the message or</li> <li>performs changes to the header or the body of the message or</li>
<li>needs to convert from or to a MAC-based protection.</li> <li>needs to convert from or to a MAC-based protection.</li>
</ul> </ul>
<t>This is particularly relevant in the upstream communication of certif icate request messages.</t> <t>This is particularly relevant in the upstream communication of certif icate request messages.</t>
<t>Note that the message protection covers only the header and the body and not the extraCerts. The PKI management entity MAY change the extraCerts in any of the following message adaptations, e.g., to sort, add, or delete certific ates to support subsequent PKI entities. This may be particularly helpful to au gment upstream messages with additional certificates or to reduce the number of certificates in downstream messages when forwarding to constrained devices.</t> <t>Note that the message protection covers only the header and the body and not the extraCerts. The PKI management entity <bcp14>MAY</bcp14> change the extraCerts in any of the following message adaptations, e.g., to sort, add, or delete certificates to support subsequent PKI entities. This may be particularl y helpful to augment upstream messages with additional certificates or to reduce the number of certificates in downstream messages when forwarding to constraine d devices.</t>
<section anchor="RA_noChange" numbered="true" toc="default"> <section anchor="RA_noChange" numbered="true" toc="default">
<name>Not Changing Protection</name> <name>Not Changing Protection</name>
<t>This variant means that a PKI management entity forwards a CMP mess <t>This variant means that a PKI management entity forwards a CMP mess
age without changing the header, body, or protection. In this case the PKI mana age without changing the header, body, or protection. In this case, the PKI man
gement entity acts more like a proxy, e.g., on a network boundary, implementing agement entity acts more like a proxy, e.g., on a network boundary, implementing
no specific RA-like security functionality that requires an authentic indication no specific RA-like security functionality that requires an authentic indicatio
to the PKI. Still the PKI management entity might implement checks that result n to the PKI. Still, the PKI management entity might implement checks that resul
in refusing to forward the request message and instead responding as specified i t in refusing to forward the request message and instead responding as specified
n <xref target="Error" format="default"/>.</t> in <xref target="Error" format="default"/>.</t>
<t>This variant of forwarding a message or the one described in <xref <t>This variant of forwarding a message or the one described in <xref
target="RA_AddSingel" format="default"/> MUST be used for kur messages and for c target="RA_AddSingel" format="default"/> <bcp14>MUST</bcp14> be used for kur mes
entral key generation. </t> sages and for central key generation. </t>
<t>No specific prerequisites apply in addition to those specifi ed in <xref target="Prereq" format="default"/>.</t> <t>No specific prerequisites apply in addition to those specifi ed in <xref target="Prereq" format="default"/>.</t>
</section> </section>
<section anchor="RA_Add" numbered="true" toc="default"> <section anchor="RA_Add" numbered="true" toc="default">
<name>Adding Protection and Batching of Messages</name> <name>Adding Protection and Batching of Messages</name>
<t>This variant of forwarding a message means that a PKI management en tity adds another protection to PKI management messages before forwarding them.< /t> <t>This variant of forwarding a message means that a PKI management en tity adds another protection to PKI management messages before forwarding them.< /t>
<t>The nested message is a PKI management message containing a PKIMess <t>The nested message is a PKI management message containing a PKIMess
ages sequence as its body containing one or more CMP messages.</t> ages sequence as its body, containing one or more CMP messages.</t>
<t>As specified in the updated <xref target="RFC4210" format="default" <t>As specified in the updated <xref target="RFC4210" format="default"
>Section 5.1.3.4 of RFC&nbsp;4210</xref> (see also <xref target="I-D.ietf-lamps- sectionFormat="of" section="5.1.3.4"/> (also see <xref target="RFC9480" format=
cmp-updates" format="default">CMP Updates Section 2.6</xref>) there are various "default" sectionFormat="of" section="2.6">CMP Updates</xref>), there are variou
use cases for adding another protection by a PKI management entity. Specific pro s use cases for adding another protection by a PKI management entity. Specific p
cedures are described in more detail in the following sections.</t> rocedures are described in more detail in the following sections.</t>
<t keepWithNext="true">Detailed Message Description:</t> <t keepWithNext="true">Detailed Message Description:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
Nested Message - nested Nested Message - nested
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- Container to provide additional protection to original -- Container to provide additional protection to original
-- messages and to bundle request messages or alternatively -- messages and to bundle request messages or alternatively
-- response messages -- response messages
PKIMessages REQUIRED PKIMessages REQUIRED
-- MUST be a sequence of one or more CMP messages -- MUST be a sequence of one or more CMP messages
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 using the CMP protection key of -- As described in Section 3.2, using the CMP protection key of
-- the PKI management entity -- the PKI management entity
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
]]></artwork> ]]></sourcecode>
<section anchor="RA_AddSingel" numbered="true" toc="default"> <section anchor="RA_AddSingel" numbered="true" toc="default">
<name>Adding Protection to a Request Message</name> <name>Adding Protection to a Request Message</name>
<t>This variant means that a PKI management entity forwards a CMP me ssage while authentically indicating successful validation and approval of a req uest message without changing the original message authentication.</t> <t>This variant means that a PKI management entity forwards a CMP me ssage while authentically indicating successful validation and approval of a req uest message without changing the original message authentication.</t>
<t>By adding a protection using its own CMP protection ke <t>By adding a protection using its own CMP protection ke
y the PKI management entity provides a proof of verifying and approving the mess y, the PKI management entity provides a proof of verifying and approving the mes
age as described above. Thus, the PKI management entity acts as an actual Regist sage, as described above. Thus, the PKI management entity acts as an actual regi
ration Authority (RA), which implements important security functionality of the stration authority (RA), which implements important security functionality of th
PKI. Applying an additional protection is specifically relevant when forwarding e PKI. Applying an additional protection is specifically relevant when forwardin
a message that requests a certificate update or central key generation. This is g a message that requests a certificate update or central key generation. This
because the original protection of the EE needs to be preserved while adding an is because the original protection of the EE needs to be preserved while adding
indication of approval by the PKI management entity.</t> an indication of approval by the PKI management entity.</t>
<t>The PKI management entity wrapping the original request message i <t>The PKI management entity wrapping the original request message i
n a nested message structure MUST copy the values of the recipient, recipNonce, n a nested message structure <bcp14>MUST</bcp14> copy the values of the senderNo
and transactionID header fields of the original message to the respective header nce and transactionID header fields of the original message to the respective he
fields of the nested message and apply signature-based protection. The additio ader fields of the nested message and apply signature-based protection. The add
nal signature serves as proof of verification and authorization by this PKI mana itional signature serves as proof of verification and authorization by this PKI
gement entity.</t> management entity.</t>
<t>The PKI management entity receiving such a nested message that co <t>The PKI management entity receiving such a nested message that co
ntains a single request message MUST validate the additional protection signatur ntains a single request message <bcp14>MUST</bcp14> validate the additional prot
e on the nested message and check the authorization for the approval it implies. ection signature on the nested message and check the authorization for the appro
</t> val it implies. Other fields in the header of the nested message can be ignored
.</t>
<t>The PKI management entity responding to the request co ntained in the nested message sends the response message as described in <xref t arget="RA_response" format="default"/>, without wrapping it in a nested message. </t> <t>The PKI management entity responding to the request co ntained in the nested message sends the response message as described in <xref t arget="RA_response" format="default"/>, without wrapping it in a nested message. </t>
<t>Note: When responding to the inner request message, it must be considered that the verification and approval activity described in thi s section has already been performed by the PKI management entity that protected the nested message.</t>
<t>Note: This form of nesting messages is characterized by the fact that the transactionID in the header of the nested message is the same as the on e used in the included message.</t> <t>Note: This form of nesting messages is characterized by the fact that the transactionID in the header of the nested message is the same as the on e used in the included message.</t>
<t keepWithNext="true">Specific prerequisites augmenting the prerequ isites in <xref target="Prereq" format="default"/>:</t> <t keepWithNext="true">The specific prerequisite augmenting the prer equisites in <xref target="Prereq" format="default"/> is as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The PKI management entity MUST be able to validate the respect ive request and have the authorization to perform approval of the request accord ing to the PKI policies.</li> <li>The PKI management entity <bcp14>MUST</bcp14> be able to valid ate the respective request and have the authorization to perform approval of the request according to the PKI policies.</li>
</ul> </ul>
<t keepWithNext="true">Message Flow:</t> <t keepWithNext="true">Message Flow:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
Step# PKI management entity PKI management entity Step# PKI management entity PKI management entity
1 format nested 1 format nested
2 -> nested -> 2 -> nested ->
3 handle or forward nested 3 handle or forward nested
4 format or receive response 4 format or receive response
5 <- response <- 5 <- response <-
6 forward response 6 forward response
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="RA_AddBatch" numbered="true" toc="default"> <section anchor="RA_AddBatch" numbered="true" toc="default">
<name>Batching Messages</name> <name>Batching Messages</name>
<t>A PKI management entity MAY bundle any number of PKI management m <t>A PKI management entity <bcp14>MAY</bcp14> bundle any number of P
essages for batch processing or to transfer a bulk of PKI management messages us KI management messages for batch processing or to transfer a bulk of PKI managem
ing the nested message structure. In this use case, nested messages are used bo ent messages using the nested message structure. In this use case, nested messa
th on the upstream interface for transferring request messages towards the next ges are used both on the upstream interface for transferring request messages to
PKI management entity and on its downstream interface for response messages.</t> wards the next PKI management entity and on its downstream interface for respons
<t>This PKI management operation is typically used on the interface e messages.</t>
between an LRA and an RA to bundle several messages for offline or asynchronous <t>This PKI management operation is typically used on the interface
delivery. In this case the LRA needs to initiate delayed delivery as described between an LRA and an RA to bundle several messages for offline or asynchronous
in <xref target="RA_response_polling" format="default"/>. If the RA needs differ delivery. In this case, the LRA needs to initiate delayed delivery, as describe
ent routing information per nested PKI management message provided upstream, a s d in <xref target="RA_response_polling" format="default"/>. If the RA needs diff
uitable mechanism may need to be implemented to ensure that the downstream deliv erent routing information per the nested PKI management message provided upstrea
ery of the response is done to the right requester. Since this mechanism strong m, a suitable mechanism may need to be implemented to ensure that the downstream
ly depends on the requirements of the target architecture, it is out of scope of delivery of the response is done to the right requester. Since this mechanism
this document.</t> strongly depends on the requirements of the target architecture, it is out of sc
<t>A nested message containing requests is generated locally at the ope of this document.</t>
PKI management entity. For the upstream nested message, the PKI management enti <t>A nested message containing requests is generated locally at the
ty acts as a protocol end point and therefore a fresh transactionID and a fresh PKI management entity. For the upstream nested message, the PKI management enti
senderNonce MUST be used in the header of the nested message. An upstream nested ty acts as a protocol endpoint; therefore, a fresh transactionID and a fresh sen
message may contain request messages, e.g., ir, cr, p10cr, kur, pollReq, certCo derNonce <bcp14>MUST</bcp14> be used in the header of the nested message. An ups
nf, rr, or genm. While building the upstream nested message the PKI management tream nested message may contain request messages, e.g., ir, cr, p10cr, kur, pol
entity must store the sender, transactionID, and senderNonce fields of all bundl lReq, certConf, rr, or genm. While building the upstream nested message, the PK
ed messages together with the transactionID of the upstream nested message.</t> I management entity must store the sender, transactionID, and senderNonce fields
<t>Such an upstream nested message is sent to the next PKI managemen of all bundled messages together with the transactionID of the upstream nested
t entity. The upstream PKI management entity that unbundles it MUST handle each message.</t>
of the included request messages as usual. It MUST answer with a downstream nes <t>Such an upstream nested message is sent to the next PKI managemen
ted message. This downstream nested message MUST use the transactionID of the u t entity. The upstream PKI management entity that unbundles it <bcp14>MUST</bcp1
pstream nested message and return the senderNonce of the upstream nested message 4> handle each of the included request messages as usual. It <bcp14>MUST</bcp14
as the recipNonce of the downstream nested message. The downstream nested mess > answer with a downstream nested message. This downstream nested message <bcp1
age MUST bundle all available individual response messages (e.g., ip, cp, kup, p 4>MUST</bcp14> use the transactionID of the upstream nested message and return t
ollRep, pkiConf, rp, genp, error) for all original request messages of the upstr he senderNonce of the upstream nested message as the recipNonce of the downstrea
eam nested message. While unbundling the downstream nested message, the former m nested message. The downstream nested message <bcp14>MUST</bcp14> bundle all
PKI management entity must determine lost and unexpected responses based on the available individual response messages (e.g., ip, cp, kup, pollRep, pkiConf, rp,
previously stored transactionIDs. When it forwards the unbundled responses, any genp, or error) for all original request messages of the upstream nested messag
extra messages MUST be dropped, and any missing response message MUST be answer e. While unbundling the downstream nested message, the former PKI management en
ed with an error message (failInfo bit: systemUnavail) to inform the respective tity must determine lost and unexpected responses based on the previously stored
requester about the failed certificate management operation.</t> transactionIDs. When it forwards the unbundled responses, any extra messages <
bcp14>MUST</bcp14> be dropped, and any missing response message <bcp14>MUST</bcp
14> be answered with an error message (failInfo bit: systemUnavail) to inform th
e respective requester about the failed certificate management operation.</t>
<t>Note: This form of nesting messages is characterized b y the fact that the transactionID in the header of the nested message is differe nt to those used in the included messages.</t> <t>Note: This form of nesting messages is characterized b y the fact that the transactionID in the header of the nested message is differe nt to those used in the included messages.</t>
<t>The protection of the nested messages MUST NOT be regarded as an indication of verification or approval of the bundled PKI request messages.</t> <t>The protection of the nested messages <bcp14>MUST NOT</bcp14> be regarded as an indication of verification or approval of the bundled PKI request messages.</t>
<t>No specific prerequisites apply in addition to those s pecified in <xref target="Prereq" format="default"/>.</t> <t>No specific prerequisites apply in addition to those s pecified in <xref target="Prereq" format="default"/>.</t>
<t keepWithNext="true">Message Flow:</t> <t keepWithNext="true">Message Flow:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
Step# PKI management entity PKI management entity Step# PKI management entity PKI management entity
1 format nested 1 format nested
2 -> nested -> 2 -> nested ->
3 handle or forward nested 3 handle or forward nested
4 format or receive nested 4 format or receive nested
5 <- nested <- 5 <- nested <-
6 handle nested 6 handle nested
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
<section anchor="RA_Replace" numbered="true" toc="default"> <section anchor="RA_Replace" numbered="true" toc="default">
<name>Replacing Protection</name> <name>Replacing Protection</name>
<t>The following two alternatives can be used by any PKI management en <t>The following two alternatives can be used by any PKI management en
tity forwarding a CMP message with or without changes while providing its own pr tity forwarding a CMP message with or without changes while providing its own pr
otection and in this way asserting approval of the message.</t> otection and, in this way, asserting approval of the message.</t>
<t>If retaining end-to-end message authentication is required, <t>If retaining end-to-end message authentication is required,
an additional protection SHALL be added instead of replacing the original protec an additional protection <bcp14>SHALL</bcp14> be added instead of replacing the
tion.</t> original protection.</t>
<t>By replacing the existing protection using its own CMP prote <t>By replacing the existing protection using its own CMP prote
ction key the PKI management entity provides a proof of verifying and approving ction key, the PKI management entity provides a proof of verifying and approving
the message as described above. Thus, the PKI management entity acts as an actua the message as described above. Thus, the PKI management entity acts as an actu
l Registration Authority (RA), which implements important security functionality al registration authority (RA), which implements important security functionalit
of the PKI.</t> y of the PKI such as verifying the proof of requester identity and authorization
<t keepWithNext="true">Before replacing the existing protection by a n .</t>
ew protection, the PKI management entity</t> <t>Note: By replacing the message protection, the binding of a
signature-based proof-of-possession to the proof-of-identity given by the origin
al message protection gets lost. To enable the CA to verify this binding, the o
riginal message can be provided in the origPKIMessage generalInfo field.</t>
<t keepWithNext="true">Before replacing the existing protection with a
new protection, the PKI management entity:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>MUST validate the protection of the received message,</li> <li><bcp14>MUST</bcp14> validate the protection of the received mess age,</li>
<li>should check the content of the message,</li> <li>should check the content of the message,</li>
<li>may do any modifications that it wants to perform, and</li> <li>may do any modifications that it wants to perform, and</li>
<li>MUST check that the sender of the original message, as authentic <li><bcp14>MUST</bcp14> check that the sender of the original messag
ated by the message protection, is authorized for the given operation.</li> e, as authenticated by the message protection, is authorized for the given opera
tion.</li>
<li>for certificate requests, <bcp14>MUST</bcp14> verify
the binding of signature-based proof-of-possession to the proof-of-identity as d
escribed in <xref target="RA_response_enrollment" format="default"/>.</li>
</ul> </ul>
<t>These message adaptations MUST NOT be applied to kur messages descr <t>These message adaptations <bcp14>MUST NOT</bcp14> be applied to kur
ibed in <xref target="EE_Update" format="default"/> since their original protect messages described in <xref target="EE_Update" format="default"/> since their o
ion using the key and certificate to be updated needs to be preserved.</t> riginal protection using the key and certificate to be updated needs to be prese
<t>These message adaptations MUST NOT be applied to certificate reques rved.</t>
t messages described in <xref target="EE_centralKeyGeneration" format="default"/ <t>These message adaptations <bcp14>MUST NOT</bcp14> be applied to cer
> for central key generation since their original protection needs to be preserv tificate request messages described in <xref target="EE_centralKeyGeneration" fo
ed up to the Key Generation Authority, which needs to use it for encrypting the rmat="default"/> for central key generation since their original protection need
new private key for the EE.</t> s to be preserved up to the KGA, which needs to use it for encrypting the new pr
<t>In both the kur and central key generation cases, if a PKI manageme ivate key for the EE.</t>
nt entity needs to state its approval of the original request message it MUST pr <t>In both the kur and central key generation cases, if a PKI manageme
ovide this using a nested message as specified in <xref target="RA_AddSingel" fo nt entity needs to state its approval of the original request message, it <bcp14
rmat="default"/>.</t> >MUST</bcp14> provide this using a nested message as specified in <xref target="
<t>When an intermediate PKI management entity modifies a message, it M RA_AddSingel" format="default"/>.</t>
UST NOT change the transactionID, the senderNonce, or the recipNonce - apart fro <t>When an intermediate PKI management entity modifies a message, it <
m the exception for the recipNonce given in <xref target="RA_response_polling" f bcp14>MUST NOT</bcp14> change the transactionID, the senderNonce, or the recipNo
ormat="default"/>.</t> nce, apart from the exception for the recipNonce given in <xref target="RA_respo
nse_polling" format="default"/>.</t>
<section anchor="RA_keepPOPO" numbered="true" toc="default"> <section anchor="RA_keepPOPO" numbered="true" toc="default">
<name>Not Changing Proof-of-Possession</name> <name>Not Changing Proof-of-Possession</name>
<t>This variant of forwarding a message means that a PKI management entity forwards a CMP message with or without modifying the message header or bo dy while preserving any included proof-of-possession.</t> <t>This variant of forwarding a message means that a PKI management entity forwards a CMP message with or without modifying the message header or bo dy while preserving any included proof-of-possession.</t>
<t>This variant is typically used when an RA replaces an existing MAC-based protection by its own signature-based protection, because the upstream PKI management entity does not know the respective shared secret infor mation, replacing the protection is useful.</t> <t>This variant is typically used when an RA replaces an existing MAC-based protection with its own signature-based protection; because t he upstream PKI management entity does not know the respective shared secret inf ormation, replacing the protection is useful.</t>
<t>Note: A signature-based proof-of-possession of a certi ficate request will be broken if any field in the certTemplate structure is chan ged.</t> <t>Note: A signature-based proof-of-possession of a certi ficate request will be broken if any field in the certTemplate structure is chan ged.</t>
<t>In case the PKI management entity breaks an existing proof-of-pos session, the message adaptation described in <xref target="RA_breakPOPO" format= "default"/> needs to be applied instead.</t> <t>In case the PKI management entity breaks an existing proof-of-pos session, the message adaptation described in <xref target="RA_breakPOPO" format= "default"/> needs to be applied instead.</t>
<t keepWithNext="true">Specific prerequisites augmenting the prerequ isites in <xref target="Prereq" format="default"/>:</t> <t keepWithNext="true">The specific prerequisite augmenting the prer equisites in <xref target="Prereq" format="default"/> is as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The PKI management entity MUST be able to validate the respect ive request and have the authorization to perform approval of the request accord ing to the PKI policies.</li> <li>The PKI management entity <bcp14>MUST</bcp14> be able to valid ate the respective request and have the authorization to perform approval of the request according to the PKI policies.</li>
</ul> </ul>
</section> </section>
<section anchor="RA_breakPOPO" numbered="true" toc="default"> <section anchor="RA_breakPOPO" numbered="true" toc="default">
<name>Using raVerified</name> <name>Using raVerified</name>
<t>This variant of forwarding a message needs to be used if a PKI ma <t>This variant of forwarding a message needs to be used if a PKI ma
nagement entity breaks any included proof-of-possession in a certificate request nagement entity breaks any included proof-of-possession in a certificate request
message, for instance because it forwards an ir or cr message with modification message, for instance, because it forwards an ir or cr message with modificatio
s of the certTemplate, i.e., modification, addition, or removal of fields.</t> ns of the certTemplate, i.e., modification, addition, or removal of fields.</t>
<t>The PKI management entity MUST verify the proof-of-possession con <t>The PKI management entity <bcp14>MUST</bcp14> verify the proof-of
tained in the original message using the included public key. If successful, th -possession contained in the original message using the included public key. If
e PKI management entity MUST change the popo field value to raVerified.</t> successful, the PKI management entity <bcp14>MUST</bcp14> change the popo field
<t keepWithNext="true">Specific prerequisites augmenting the prerequ value to raVerified.</t>
isites in <xref target="Prereq" format="default"/>:</t> <t keepWithNext="true">Specific prerequisites augmenting the prerequ
isites in <xref target="Prereq" format="default"/> are as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The PKI management entity MUST be authorized to replace the pr <li>The PKI management entity <bcp14>MUST</bcp14> be authorized to
oof-of-possession (after verifying it) with raVerified.</li> replace the proof-of-possession (after verifying it) with raVerified.</li>
<li>The PKI management entity MUST be able to validate the respect <li>The PKI management entity <bcp14>MUST</bcp14> be able to valid
ive request and have the authorization to perform approval of the request accord ate the respective request and have the authorization to perform approval of the
ing to the PKI policies.</li> request according to the PKI policies.</li>
</ul> </ul>
<t keepWithNext="true">Detailed Description of popo Field of certReq <t keepWithNext="true">Detailed Description of the popo Field of the
Structure:</t> certReq Structure:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
popo popo
raVerified REQUIRED raVerified REQUIRED
-- MUST have the value NULL and indicates that the PKI -- MUST have the value NULL and indicates that the PKI
-- management entity verified the popo of the original message -- management entity verified the popo of the original message
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="RA_on-behalf" numbered="true" toc="default"> <section anchor="RA_on-behalf" numbered="true" toc="default">
<name>Acting on Behalf of other PKI Entities</name> <name>Acting on Behalf of Other PKI Entities</name>
<t>A PKI management entity may need to request a PKI management operatio <t>A PKI management entity may need to request a PKI management operatio
n on behalf of another PKI entity. In this case the PKI management entity initi n on behalf of another PKI entity. In this case, the PKI management entity init
ates the respective PKI management operation as described in <xref target="EE_Us iates the respective PKI management operation as described in <xref target="EE_U
eCases" format="default"/> acting in the role of the EE.</t> seCases" format="default"/>, acting in the role of the EE.</t>
<t>Note: The request message protection will not authenticate the <t>Note: The request message protection will not authenticate the
EE, but the RA acting on behalf of the EE.</t> EE, but it will authenticate the RA acting on behalf of the EE.</t>
<section anchor="RA_on-behalf_request" numbered="true" toc="defau lt"> <section anchor="RA_on-behalf_request" numbered="true" toc="defau lt">
<name>Requesting a Certificate</name> <name>Requesting a Certificate</name>
<t>A PKI management entity may use one of the PKI management operati <t>A PKI management entity may use one of the PKI managem
ons described in <xref target="EE_request" format="default"/> to request a certi ent operations described in <xref target="EE_request" format="default"/> to requ
ficate on behalf of another PKI entity. It either generates the key pair itself est a certificate on behalf of another PKI entity. It either generates the key
and inserts the new public key in the subjectPublicKey field of the request cer pair itself and inserts the new public key in the subjectPublicKey field of the
tTemplate, or it uses a certificate request received from downstream, e.g., by m request certTemplate, or it uses a certificate request received from downstream,
eans of a different protocol. In the latter case it MUST verify the received pr e.g., by means of a different protocol.
oof-of-possession if this proof breaks, e.g., due to transformation from <xref t In the latter case, it <bcp14>MUST</bcp14> verify the rec
arget="RFC2986" format="default">PKCS#10</xref> to <xref target="RFC4211" format eived proof-of-possession if this proof breaks, e.g., due to transformation from
="default">CRMF</xref> certificate request format.</t> <xref target="RFC2986" format="default">PKCS #10</xref> to <xref target="RFC421
1" format="default">CRMF</xref>.
It <bcp14>MUST</bcp14> also verify, based on local PKI po
licy, that the subject name in the certTemplate identifies the EE.</t>
<t>No specific prerequisites apply in addition to those s pecified in <xref target="EE_request" format="default"/>.</t> <t>No specific prerequisites apply in addition to those s pecified in <xref target="EE_request" format="default"/>.</t>
<t>Note: An upstream PKI management entity will not be ab le to differentiate this PKI management operation from the one described in <xre f target="RA_Replace" format="default"/> because in both cases the message is pr otected by the PKI management entity.</t> <t>Note: An upstream PKI management entity will not be ab le to differentiate this PKI management operation from the one described in <xre f target="RA_Replace" format="default"/> because, in both cases, the message is protected by the PKI management entity.</t>
<t keepWithNext="true">The message sequence for this PKI management operation is identical to the respective PKI management operation giv en in <xref target="EE_request" format="default"/>, with the following changes:< /t> <t keepWithNext="true">The message sequence for this PKI management operation is identical to the respective PKI management operation giv en in <xref target="EE_request" format="default"/>, with the following changes:< /t>
<ol spacing="normal" type="%d"> <ol spacing="normal" type="1">
<li>The request messages MUST be signed using the <li>The request messages <bcp14>MUST</bcp14> be s
CMP protection key of the PKI management entity taking the role of the EE in th igned using the CMP protection key of the PKI management entity taking the role
is operation.</li> of the EE in this operation.</li>
<li>If inclusion of a proper proof-of-possession <li>If inclusion of a proper proof-of-possession
is not possible the PKI management entity MUST verify the POP provided from down is not possible, the PKI management entity <bcp14>MUST</bcp14> verify the POP pr
stream and use "raVerified" in its upstream request.</li> ovided from downstream and use "raVerified" in its upstream request.</li>
<li>The binding of the proof-of-possession to the
proof-of-identity of the requesting EE cannot be provided when acting on behalf
of the EE.</li>
</ol> </ol>
</section> </section>
<section anchor="RA_on-behalf_revoke" numbered="true" toc="defaul t"> <section anchor="RA_on-behalf_revoke" numbered="true" toc="defaul t">
<name>Revoking a Certificate</name> <name>Revoking a Certificate</name>
<t>A PKI management entity may use the PKI management ope ration described in <xref target="EE_Revoke" format="default"/> to revoke a cert ificate of another PKI entity. This revocation request message MUST be signed b y the PKI management entity using its own CMP protection key to prove to the PKI authorization to revoke the certificate on behalf of that PKI entity.</t> <t>A PKI management entity may use the PKI management ope ration described in <xref target="EE_Revoke" format="default"/> to revoke a cert ificate of another PKI entity. This revocation request message <bcp14>MUST</bcp 14> be signed by the PKI management entity using its own CMP protection key to p rove to the PKI authorization to revoke the certificate on behalf of that PKI en tity.</t>
<t>No specific prerequisites apply in addition to those s pecified in <xref target="EE_Revoke" format="default"/>.</t> <t>No specific prerequisites apply in addition to those s pecified in <xref target="EE_Revoke" format="default"/>.</t>
<t>Note: An upstream PKI management entity will not be ab le to differentiate this PKI management operation from the ones described in <xr ef target="RA_Replace" format="default"/>.</t> <t>Note: An upstream PKI management entity will not be ab le to differentiate this PKI management operation from the ones described in <xr ef target="RA_Replace" format="default"/>.</t>
<t keepWithNext="true">The message sequence for this PKI management operation is identical to that given in <xref target="EE_Revoke" form at="default"/>, with the following changes:</t> <t keepWithNext="true">The message sequence for this PKI management operation is identical to that given in <xref target="EE_Revoke" form at="default"/>, with the following changes:</t>
<ol spacing="normal" type="%d"> <ol spacing="normal" type="1">
<li>The rr message MUST be signed using the CMP p <li>The rr message <bcp14>MUST</bcp14> be signed
rotection key of the PKI management entity acting on behalf of the EE in this op using the CMP protection key of the PKI management entity acting on behalf of th
eration.</li> e EE in this operation.</li>
</ol> </ol>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Transfer_types" numbered="true" toc="default"> <section anchor="Transfer_types" numbered="true" toc="default">
<name>CMP Message Transfer Mechanisms</name> <name>CMP Message Transfer Mechanisms</name>
<t>CMP messages are designed to be self-contained, such that in principle <t>CMP messages are designed to be self-contained, such that, in principle
any reliable transfer mechanism can be used. EEs will typically support only on , any reliable transfer mechanism can be used. EEs will typically support only
e transfer mechanism. PKI management entities SHOULD offer HTTP and MAY offer C one transfer mechanism. PKI management entities <bcp14>SHOULD</bcp14> offer HTT
oAP where required. Piggybacking of CMP messages on any other reliable transfer P and <bcp14>MAY</bcp14> offer CoAP where required. Piggybacking of CMP messages
protocol MAY be used, and file-based transfer MAY be used in case offline transf on any other reliable transfer protocol <bcp14>MAY</bcp14> be used, and file-ba
er is required.</t> sed transfer <bcp14>MAY</bcp14> be used in case offline transfer is required.</t
<t>Independently of the means of transfer, it can happen that messages are >
lost or that a communication partner does not respond. To prevent waiting inde <t>Independently of the means of transfer, it can happen that messages are
finitely, each PKI entity that sends CMP requests should use a configurable per- lost or that a communication partner does not respond. To prevent waiting inde
request timeout, and each PKI management entity that handles CMP requests should finitely, each PKI entity that sends CMP requests should use a configurable per-
use a configurable timeout in case a further request message is to be expected request timeout, and each PKI management entity that handles CMP requests should
from the client side within the same transaction. In this way a hanging transac use a configurable timeout in case a further request message is to be expected
tion can be closed cleanly with an error as described in <xref target="Error" fo from the client side within the same transaction. In this way, a hanging transa
rmat="default"/> (failInfo bit: systemUnavail) and related resources (for instan ction can be closed cleanly with an error as described in <xref target="Error" f
ce, any cached extraCerts) can be freed.</t> ormat="default"/> (failInfo bit: systemUnavail), and related resources (for inst
<t>Moreover, there are various situations where the delivery of message ance, any cached extraCerts) can be freed.</t>
s gets delayed. For instance, a serving PKI management entity might take longer <t>Moreover, there are various situations where the delivery of message
than expected to form a response due to administrative processes, resource cons s gets delayed. For instance, a serving PKI management entity might take longer
traints, or upstream message delivery delays. The transport layer itself may ca than expected to form a response due to administrative processes, resource cons
use delays, for instance due to offline transport, network segmentation, or inte traints, or upstream message delivery delays. The transport layer itself may ca
rmittent network connectivity. Part of these issues can be detected and handled use delays, for instance, due to offline transport, network segmentation, or int
at CMP level using pollReq and pollRep messages as described in <xref target="E ermittent network connectivity. Part of these issues can be detected and handle
E_Polling" format="default"/>, while others are better handled at transfer level d at CMP level using pollReq and pollRep messages as described in <xref target="
. Depending on the transfer protocol and system architecture, solutions for han EE_Polling" format="default"/>, while others are better handled at transfer leve
dling delays at transfer level may be present and can be used for CMP connection l. Depending on the transfer protocol and system architecture, solutions for ha
s, for instance connection re-establishment and message retransmission.</t> ndling delays at transfer level may be present and can be used for CMP connectio
ns, for instance, connection reestablishment and message retransmission.</t>
<t>Note: Long timeout periods are helpful to maximize chances to handle minor delays at lower layers without the need for polling.</t> <t>Note: Long timeout periods are helpful to maximize chances to handle minor delays at lower layers without the need for polling.</t>
<t>Note: When using TCP and similar reliable connection-oriented transp ort protocols, which is typical in conjunction with HTTP, there is the option to keep the connection alive over multiple request-response message pairs. This m ay improve efficiency.</t> <t>Note: When using TCP and similar reliable connection-oriented transp ort protocols, which is typical in conjunction with HTTP, there is the option to keep the connection alive over multiple request-response message pairs. This m ay improve efficiency.</t>
<t>When conveying CMP messages in HTTP, CoAP, or MIME-based transfer proto cols, the internet media type "application/pkixcmp" MUST be set for transfer enc oding as specified in <xref target="RFC6712" format="default">Section 3.4 of CMP over HTTP</xref> and <xref target="I-D.ietf-ace-cmpv2-coap-transport" format="d efault">Section 2.4 of CMP over CoAP</xref>.</t> <t>When conveying CMP messages in HTTP, CoAP, or MIME-based transfer proto cols, the Internet media type "application/pkixcmp" <bcp14>MUST</bcp14> be set f or transfer encoding as specified in <xref target="RFC6712" format="default" sec tionFormat="of" section="3.4">CMP over HTTP</xref> and <xref target="RFC9482" fo rmat="default" sectionFormat="of" section="2.3">CMP over CoAP</xref>.</t>
<section anchor="HTTP" numbered="true" toc="default"> <section anchor="HTTP" numbered="true" toc="default">
<name>HTTP Transfer</name> <name>HTTP Transfer</name>
<t>This transfer mechanism can be used by a PKI entity to transfer CMP m <t>This transfer mechanism can be used by a PKI entity to transfer CMP m
essages over HTTP. If HTTP transfer is used the specifications as described in < essages over HTTP. If HTTP transfer is used, the specifications described in <xr
xref target="RFC6712" format="default"/> and updated by <xref target="I-D.ietf-l ef target="RFC6712" format="default"/> and updated by <xref target="RFC9480" for
amps-cmp-updates" format="default">CMP Updates</xref> MUST be followed.</t> mat="default">CMP Updates</xref> <bcp14>MUST</bcp14> be followed.</t>
<t>PKI management operations MUST use an URI path consisting of '/.well- <t>PKI management operations <bcp14>MUST</bcp14> use a URI path consisti
known/cmp/' or '/.well-known/cmp/p/&lt;name&gt;/' as specified in <xref target=" ng of '/.well-known/cmp' or '/.well-known/cmp/p/&lt;name&gt;' as specified in <x
I-D.ietf-lamps-cmp-updates" format="default">CMP Updates Section 3.3</xref>. It ref target="RFC9480" format="default" sectionFormat="of" section="3.3">CMP Updat
SHOULD be followed by an operation label depending on the type of PKI management es</xref>. It <bcp14>SHOULD</bcp14> be followed by an operation label depending
operation.</t> on the type of PKI management operation.</t>
<table anchor="http_endpoints" align="left"> <table anchor="http_endpoints" align="left">
<name>HTTP URI Path Segment &lt;operation&gt;</name> <name>HTTP URI Path Segment &lt;operation&gt;</name>
<thead> <thead>
<tr> <tr>
<th align="left">PKI Management Operation</th> <th align="left">PKI Management Operation</th>
<th align="center">URI Path Segment</th> <th align="center">URI Path Segment</th>
<th align="left">Details</th> <th align="left">Details</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"><xref target="EE_newPKI" format="title"/></td> <td align="left">Enrolling an End Entity to a New PKI</td>
<td align="center">initialization</td> <td align="center">initialization</td>
<td align="left"><xref target="EE_newPKI" format="default"/></td> <td align="left"><xref target="EE_newPKI" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_trustedPKI" format="title"/></td > <td align="left">Enrolling an End Entity to a Known PKI</td>
<td align="center">certification</td> <td align="center">certification</td>
<td align="left"><xref target="EE_trustedPKI" format="default"/></ td> <td align="left"><xref target="EE_trustedPKI" format="default"/></ td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_Update" format="title"/></td> <td align="left">Updating a Valid Certificate</td>
<td align="center">keyupdate</td> <td align="center">keyupdate</td>
<td align="left"><xref target="EE_Update" format="default"/></td> <td align="left"><xref target="EE_Update" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_P10" format="title"/></td> <td align="left">Enrolling an End Entity Using a PKCS #10 Request< /td>
<td align="center">pkcs10</td> <td align="center">pkcs10</td>
<td align="left"><xref target="EE_P10" format="default"/></td> <td align="left"><xref target="EE_P10" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_Revoke" format="title"/></td> <td align="left">Revoking a Certificate</td>
<td align="center">revocation</td> <td align="center">revocation</td>
<td align="left"><xref target="EE_Revoke" format="default"/></td> <td align="left"><xref target="EE_Revoke" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_CACerts" format="title"/></td> <td align="left">Get CA Certificates</td>
<td align="center">getcacerts</td> <td align="center">getcacerts</td>
<td align="left"><xref target="EE_CACerts" format="default"/></td> <td align="left"><xref target="EE_CACerts" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_RootCAUpdate" format="title"/></ td> <td align="left">Get Root CA Certificate Update</td>
<td align="center">getrootupdate</td> <td align="center">getrootupdate</td>
<td align="left"><xref target="EE_RootCAUpdate" format="default"/> </td> <td align="left"><xref target="EE_RootCAUpdate" format="default"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_Temp" format="title"/></td> <td align="left">Get Certificate Request Template</td>
<td align="center">getcertreqtemplate</td> <td align="center">getcertreqtemplate</td>
<td align="left"><xref target="EE_Temp" format="default"/></td> <td align="left"><xref target="EE_Temp" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_CRLs" format="title"/></td> <td align="left">CRL Update Retrieval</td>
<td align="center">getcrls</td> <td align="center">getcrls</td>
<td align="left"><xref target="EE_CRLs" format="default"/></td> <td align="left"><xref target="EE_CRLs" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<t><xref target="RA_AddBatch" format="title"/></t> <t>Batching Messages</t>
<t>Note: This path element is applicable only bet ween PKI management entities.</t> <t>Note: This path element is applicable only bet ween PKI management entities.</t>
</td> </td>
<td align="center">nested</td> <td align="center">nested</td>
<td align="left"><xref target="RA_AddBatch" format="default"/></td > <td align="left"><xref target="RA_AddBatch" format="default"/></td >
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t keepWithNext="true">If operation labels are used:</t> <t keepWithNext="true">If operation labels are used:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Independently of any variants used (see Sections <xre <li>independently of any variants used (see Sections <xref target="EE_M
f target="EE_MAC" format="counter"/>, <xref target="EE_centralKeyGeneration" for AC" format="counter"/>, <xref target="EE_centralKeyGeneration" format="counter"/
mat="counter"/>, and <xref target="EE_Polling" format="counter"/>) the operation >, and <xref target="EE_Polling" format="counter"/>), the operation label corres
label corresponding to the PKI management operation SHALL be used.</li> ponding to the PKI management operation <bcp14>SHALL</bcp14> be used.</li>
<li>Any certConf or pollReq messages SHALL be sent to the <li>any certConf or pollReq messages <bcp14>SHALL</bcp14>
same endpoint as determined by the PKI management operation.</li> be sent to the same endpoint as determined by the PKI management operation.</li
<li>When a single request message is nested as described >
in <xref target="RA_AddSingel" format="default"/>, the label to use SHALL be the <li>when a single request message is nested as described
same as for the underlying PKI management operation.</li> in <xref target="RA_AddSingel" format="default"/>, the label to use <bcp14>SHALL
</bcp14> be the same as for the underlying PKI management operation.</li>
</ul> </ul>
<t>By sending a request to its preferred endpoint, the PKI entity will r <t>By sending a request to its preferred endpoint, the PKI entity will r
ecognize via the HTTP response status code whether a configured URI is supported ecognize, via the HTTP response status code, whether a configured URI is support
by the PKI management entity.</t> ed by the PKI management entity.</t>
<t>In case a PKI management entity receives an unexpected HTTP st <t>In case a PKI management entity receives an unexpected HTTP st
atus code from upstream, it MUST respond downstream with an error message as des atus code from upstream, it <bcp14>MUST</bcp14> respond downstream with an error
cribed in <xref target="Error" format="default"/> using a failInfo bit correspon message as described in <xref target="Error" format="default"/>, using a failIn
ding to the status code, e.g., systemFailure.</t> fo bit corresponding to the status code, e.g., systemFailure.</t>
<t>For certificate management the major security goal is integrit <t>For certificate management, the major security goal is integri
y and data origin authentication. For delivery of centrally generated keys, also ty and data origin authentication. For delivery of centrally generated keys, con
confidentiality is a must. These goals are sufficiently achieved by CMP itself, fidentiality is also a must. These goals are sufficiently achieved by CMP itself
also in an end-to-end fashion.</t> , also in an end-to-end fashion.</t>
<t>If a second line of defense is required or general privacy con cerns exist, TLS can be used to provide confidentiality on a hop-by-hop basis. TLS should be used with certificate-based authentication to further protect the HTTP transfer as described in <xref target="RFC9110" format="default"/>. In ad dition, the recommendations provided in <xref target="RFC9325" format="default"/ > should be followed.</t> <t>If a second line of defense is required or general privacy con cerns exist, TLS can be used to provide confidentiality on a hop-by-hop basis. TLS should be used with certificate-based authentication to further protect the HTTP transfer as described in <xref target="RFC9110" format="default"/>. In ad dition, the recommendations provided in <xref target="RFC9325" format="default"/ > should be followed.</t>
<t>Note: The requirements for checking certificates given in <xref targe t="RFC5280" format="default"/> and either <xref target="RFC5246" format="default "/> or <xref target="RFC8446" format="default"/> must be followed for the TLS la yer. Certificate status checking should be used for the TLS certificates of all communication partners.</t> <t>Note: The requirements for checking certificates given in <xref targe t="RFC5280" format="default"/> and either <xref target="RFC5246" format="default "/> or <xref target="RFC8446" format="default"/> must be followed for the TLS la yer. Certificate status checking should be used for the TLS certificates of all communication partners.</t>
<t>TLS with mutual authentication based on shared secret information may be used in case no suitable certificates for certificate-based authentication a re available, e.g., a PKI management operation with MAC-based protection is used .</t> <t>TLS with mutual authentication based on shared secret information may be used in case no suitable certificates for certificate-based authentication a re available, e.g., a PKI management operation with MAC-based protection is used .</t>
<t>Note: The entropy of the shared secret information is crucial for the level of protection available using shard secret information-based TLS authenti cation. A pre-shared key (PSK) mechanism may be used with shared secret informa tion with an entropy of at least 128 bits. Otherwise, a password-authenticated key exchange (PAKE) protocol is recommended.</t> <t>Note: The entropy of the shared secret information is crucial for the level of protection available using shard secret information-based TLS authenti cation. A pre-shared key (PSK) mechanism may be used with shared secret informa tion with an entropy of at least 128 bits. Otherwise, a password-authenticated key exchange (PAKE) protocol is recommended.</t>
<t>Note: The provisioning of client certificates and PSKs is out of scope of this document.</t> <t>Note: The provisioning of client certificates and PSKs is out of scope of this document.</t>
</section> </section>
<section anchor="CoAP" numbered="true" toc="default"> <section anchor="CoAP" numbered="true" toc="default">
<name>CoAP Transfer </name> <name>CoAP Transfer </name>
<t>This transfer mechanism can be used by a PKI entity to transf <t>This transfer mechanism can be used by a PKI entity to transf
er CMP messages over <xref target="RFC7252" format="default">CoAP</xref>, e.g., er CMP messages over <xref target="RFC7252" format="default">CoAP</xref>, e.g.,
in constrained environments. If CoAP transfer is used the specifications as de in constrained environments. If CoAP transfer is used, the specifications descr
scribed in <xref target="I-D.ietf-ace-cmpv2-coap-transport" format="default">CMP ibed in <xref target="RFC9482" format="default">CMP over CoAP</xref> <bcp14>MUST
over CoAP</xref> MUST be followed.</t> </bcp14> be followed.</t>
<t>PKI management operations MUST use an URI path consisting of ' <t>PKI management operations <bcp14>MUST</bcp14> use a URI path c
/.well-known/cmp/' or '/.well-known/cmp/p/&lt;name&gt;/' as specified in <xref t onsisting of '/.well-known/cmp' or '/.well-known/cmp/p/&lt;name&gt;' as specifie
arget="I-D.ietf-ace-cmpv2-coap-transport" format="default">CMP over CoAP Section d in <xref target="RFC9482" format="default" sectionFormat="of" section="2.1">CM
2.1</xref>. It SHOULD be followed by an operation label depending on the type P over CoAP</xref>. It <bcp14>SHOULD</bcp14> be followed by an operation label
of PKI management operation.</t> depending on the type of PKI management operation.</t>
<table anchor="coap_endpoints" align="left"> <table anchor="coap_endpoints" align="left">
<name>CoAP URI Path Segment &lt;operation&gt;</name> <name>CoAP URI Path Segment &lt;operation&gt;</name>
<thead> <thead>
<tr> <tr>
<th align="left">PKI Management Operation</th> <th align="left">PKI Management Operation</th>
<th align="center">URI Path Segment</th> <th align="center">URI Path Segment</th>
<th align="left">Details</th> <th align="left">Details</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"><xref target="EE_newPKI" format="title"/></td> <td align="left">Enrolling an End Entity to a New PKI</td>
<td align="center">ir</td> <td align="center">ir</td>
<td align="left"><xref target="EE_newPKI" format="default"/></td> <td align="left"><xref target="EE_newPKI" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_trustedPKI" format="title"/></td > <td align="left">Enrolling an End Entity to a Known PKI</td>
<td align="center">cr</td> <td align="center">cr</td>
<td align="left"><xref target="EE_trustedPKI" format="default"/></ td> <td align="left"><xref target="EE_trustedPKI" format="default"/></ td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_Update" format="title"/></td> <td align="left">Updating a Valid Certificate</td>
<td align="center">kur</td> <td align="center">kur</td>
<td align="left"><xref target="EE_Update" format="default"/></td> <td align="left"><xref target="EE_Update" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_P10" format="title"/></td> <td align="left">Enrolling an End Entity Using a PKCS #10 Request< /td>
<td align="center">p10</td> <td align="center">p10</td>
<td align="left"><xref target="EE_P10" format="default"/></td> <td align="left"><xref target="EE_P10" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_Revoke" format="title"/></td> <td align="left">Revoking a Certificate</td>
<td align="center">rr</td> <td align="center">rr</td>
<td align="left"><xref target="EE_Revoke" format="default"/></td> <td align="left"><xref target="EE_Revoke" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_CACerts" format="title"/></td> <td align="left">Get CA Certificates</td>
<td align="center">crts</td> <td align="center">crts</td>
<td align="left"><xref target="EE_CACerts" format="default"/></td> <td align="left"><xref target="EE_CACerts" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_RootCAUpdate" format="title"/></ td> <td align="left">Get Root CA Certificate Update</td>
<td align="center">rcu</td> <td align="center">rcu</td>
<td align="left"><xref target="EE_RootCAUpdate" format="default"/> </td> <td align="left"><xref target="EE_RootCAUpdate" format="default"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_Temp" format="title"/></td> <td align="left">Get Certificate Request Template</td>
<td align="center">att</td> <td align="center">att</td>
<td align="left"><xref target="EE_Temp" format="default"/></td> <td align="left"><xref target="EE_Temp" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"><xref target="EE_CRLs" format="title"/></td> <td align="left">CRL Update Retrieval</td>
<td align="center">crls</td> <td align="center">crls</td>
<td align="left"><xref target="EE_CRLs" format="default"/></td> <td align="left"><xref target="EE_CRLs" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<t><xref target="RA_AddBatch" format="title"/></t> <t>Batching Messages</t>
<t>Note: This path element is applicable only bet ween PKI management entities.</t> <t>Note: This path element is applicable only bet ween PKI management entities.</t>
</td> </td>
<td align="center">nest</td> <td align="center">nest</td>
<td align="left"><xref target="RA_AddBatch" format="default"/></td > <td align="left"><xref target="RA_AddBatch" format="default"/></td >
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t keepWithNext="true">If operation labels are used:</t> <t keepWithNext="true">If operation labels are used:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Independently of any variants used (see Sections <xre <li>independently of any variants used (see Sections <xre
f target="EE_MAC" format="counter"/>, <xref target="EE_centralKeyGeneration" for f target="EE_MAC" format="counter"/>, <xref target="EE_centralKeyGeneration" for
mat="counter"/>, and <xref target="EE_Polling" format="counter"/>) the operation mat="counter"/>, and <xref target="EE_Polling" format="counter"/>), the operatio
label corresponding to the PKI management operation SHALL be used.</li> n label corresponding to the PKI management operation <bcp14>SHALL</bcp14> be us
<li>Any certConf or pollReq messages SHALL be sent to the ed.</li>
same endpoint as determined by the PKI management operation.</li> <li>any certConf or pollReq messages <bcp14>SHALL</bcp14>
<li>When a single request message is nested as described be sent to the same endpoint, as determined by the PKI management operation.</l
in <xref target="RA_AddSingel" format="default"/>, the label to use SHALL be the i>
same as for the underlying PKI management operation.</li> <li>when a single request message is nested as described
in <xref target="RA_AddSingel" format="default"/>, the label to use <bcp14>SHALL
</bcp14> be the same as for the underlying PKI management operation.</li>
</ul> </ul>
<t>By sending a request to its preferred endpoint, the PKI entity <t>By sending a request to its preferred endpoint, the PKI entity
will recognize via the CoAP response status code whether a configured URI is su will recognize, via the CoAP response status code, whether a configured URI is
pported by the PKI management entity. The CoAP-inherent discovery mechanisms MA supported by the PKI management entity. The CoAP-inherent discovery mechanisms
Y also be used.</t> <bcp14>MAY</bcp14> also be used.</t>
<t>In case a PKI management entity receives an unexpected CoAP st <t>In case a PKI management entity receives an unexpected CoAP st
atus code from upstream, it MUST respond downstream with an error message as des atus code from upstream, it <bcp14>MUST</bcp14> respond downstream with an error
cribed in <xref target="Error" format="default"/> using a failInfo bit correspon message, as described in <xref target="Error" format="default"/>, using a failI
ding to the status code, e.g., systemFailure.</t> nfo bit corresponding to the status code, e.g., systemFailure.</t>
<t>Like for HTTP transfer, to offer a second line of defense or t <t>Like for HTTP transfer, to offer a second line of defense or t
o provide hop-by-hop privacy protection, DTLS may be utilized as described in <x o provide hop-by-hop privacy protection, DTLS may be utilized as described in <x
ref target="I-D.ietf-ace-cmpv2-coap-transport" format="default">CMP over CoAP</x ref target="RFC9482" format="default">CMP over CoAP</xref>. If DTLS is utilized
ref>. If DTLS is utilized, the same boundary conditions (peer authentication, e , the same boundary conditions (peer authentication, etc.) as those stated for T
tc.) as stated for TLS to protect HTTP transfer in <xref target="HTTP" format="d LS to protect HTTP transfer in <xref target="HTTP" format="default"/> apply to D
efault"/> apply to DTLS likewise.</t> TLS likewise.</t>
<t>Note: The provisioning of client certificates and PSKs is out of scope of this document.</t> <t>Note: The provisioning of client certificates and PSKs is out of scope of this document.</t>
</section> </section>
<section anchor="Piggybacking" numbered="true" toc="default"> <section anchor="Piggybacking" numbered="true" toc="default">
<name>Piggybacking on Other Reliable Transfer</name> <name>Piggybacking on Other Reliable Transfer</name>
<t>CMP messages MAY also be transfer on some other reliable protocol, e. <t>CMP messages <bcp14>MAY</bcp14> also be transferred on some other rel
g., EAP or MQTT. Connection, delay, and error handling mechanisms similar to tho iable protocol, e.g., Extensible Authentication Protocol (EAP) or Message Queuin
se specified for HTTP in <xref target="RFC6712" format="default">RFC&nbsp;6712</ g Telemetry Transport (MQTT). Connection, delay, and error handling mechanisms s
xref>need to be implemented.</t> imilar to those specified for HTTP in <xref target="RFC6712" format="default"/>
<t>A more detailed specification is out of scope of this document and wo need to be implemented.</t>
uld need to be given for instance in the scope of the transfer protocol used.</t <t>A more detailed specification is out of scope of this document and wo
> uld need to be given, for instance, in the scope of the transfer protocol used.<
/t>
</section> </section>
<section anchor="Offline" numbered="true" toc="default"> <section anchor="Offline" numbered="true" toc="default">
<name>Offline Transfer</name> <name>Offline Transfer</name>
<t>For transferring CMP messages between PKI entities, any mechanism can <t>For transferring CMP messages between PKI entities, any mechanism tha
be used that is able to store and forward binary objects of sufficient length a t is able to store and forward binary objects of sufficient length and with suff
nd with sufficient reliability while preserving the order of messages for each t icient reliability while preserving the order of messages for each transaction c
ransaction.</t> an be used.</t>
<t>The transfer mechanism should be able to indicate message loss, exces <t>The transfer mechanism should be able to indicate message loss, exces
sive delay, and possibly other transmission errors. In such cases the PKI entiti sive delay, and possibly other transmission errors. In such cases, the PKI entit
es MUST report an error as specified in <xref target="Error" format="default"/> ies <bcp14>MUST</bcp14> report an error as specified in <xref target="Error" for
as far as possible.</t> mat="default"/>, as far as possible.</t>
<section anchor="File-based" numbered="true" toc="default"> <section anchor="File-based" numbered="true" toc="default">
<name>File-Based Transfer</name> <name>File-Based Transfer</name>
<t>CMP messages MAY be transferred between PKI entities using file-bas ed mechanisms, for instance when an EE is offline or a PKI management entity per forms delayed delivery. Each file MUST contain the ASN.1 DER encoding of one CM P message only, where the message may be nested. There MUST be no extraneous he ader or trailer information in the file. The file name extension ".pki" MUST be used.</t> <t>CMP messages <bcp14>MAY</bcp14> be transferred between PKI entities using file-based mechanisms, for instance, when an EE is offline or a PKI manag ement entity performs delayed delivery. Each file <bcp14>MUST</bcp14> contain t he ASN.1 DER encoding of one CMP message only, where the message may be nested. There <bcp14>MUST</bcp14> be no extraneous header or trailer information in the file. The filename extension ".pki" <bcp14>MUST</bcp14> be used.</t>
</section> </section>
<section anchor="Other_trans" numbered="true" toc="default"> <section anchor="Other_trans" numbered="true" toc="default">
<name>Other Asynchronous Transfer Protocols</name> <name>Other Asynchronous Transfer Protocols</name>
<t>Other asynchronous transfer protocols, e.g., email or website up-/d <t>Other asynchronous transfer protocols, e.g., email or website uploa
ownload, MAY transfer CMP messages between PKI entities. A MIME wrapping is defi d/download, <bcp14>MAY</bcp14> transfer CMP messages between PKI entities. A MIM
ned for those environments that are MIME-native. The MIME wrapping is specified E wrapping is defined for those environments that are MIME-native. The MIME wrap
in <xref target="RFC8551" format="default">RFC&nbsp;8551 Section 3.1</xref>.</t> ping is specified in <xref target="RFC8551" format="default" sectionFormat="of"
<t>The ASN.1 DER encoding of the CMP messages MUST be transferred usin section="3.1"/>.</t>
g the "application/pkixcmp" content type and base64-encoded content transfer enc <t>The ASN.1 DER encoding of the CMP messages <bcp14>MUST</bcp14> be t
oding as specified in <xref target="RFC6712" format="default">Section 3.4 of CMP ransferred using the "application/pkixcmp" content type and base64-encoded conte
over HTTP</xref>. A filename MUST be included either in a "content-type" or a " nt transfer encoding, as specified in <xref target="RFC6712" format="default" se
content-disposition" statement. The file name extension ".pki" MUST be used.</t> ctionFormat="of" section="3.4">CMP over HTTP</xref>. A filename <bcp14>MUST</bcp
14> be included either in a "content-type" or a "content-disposition" statement.
The filename extension ".pki" <bcp14>MUST</bcp14> be used.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Conformity" numbered="true" toc="default"> <section anchor="Conformity" numbered="true" toc="default">
<name>Conformance Requirements</name> <name>Conformance Requirements</name>
<t>This section defines which level of support for the various features specified in this profile is required for each type of PKI entity.</t> <t>This section defines which level of support for the various features specified in this profile is required for each type of PKI entity.</t>
<section anchor="UseCases" numbered="true" toc="default"> <section anchor="UseCases" numbered="true" toc="default">
<name>PKI Management Operations</name> <name>PKI Management Operations</name>
<t>The following table provides an overview of the PKI management operations specified in Sections <xref target="EE_UseCases" format="counter"/> and <xref target="RA_UseCases" format="counter"/> and states whether support by conforming EE, RA, and CA implementations is mandatory, recommended, optional, o r not applicable. Variants amend or change behavior of base PKI management oper ations and are therefore also included.</t> <t>The following table provides an overview of the PKI management operations specified in Sections <xref target="EE_UseCases" format="counter"/> and <xref target="RA_UseCases" format="counter"/> and states whether support by conforming EE, RA, and CA implementations is mandatory, recommended, optional, o r not applicable. Variants amend or change behavior of base PKI management oper ations and are therefore also included.</t>
<t>The PKI management operation specifications in <xref target="EE_UseCa ses" format="default"/> assume that either the RA or CA is the PKI management en tity that terminates the CMP protocol. If the RA terminates the CMP protocol it either responds directly as described in <xref target="RA_response" format="defa ult"/> or forwards the certificate management operation towards the CA not using CMP. <xref target="RA_forwarde_messages" format="default"/> describes different options how an RA can forward a CMP message using CMP. <xref target="RA_on-beha lf" format="default"/> offers the option that an RA operates on behalf on an EE and therefore takes the role of the EE in <xref target="EE_UseCases" format="def ault"/>.</t> <t>The PKI management operation specifications in <xref target="EE_UseCa ses" format="default"/> assume that either the RA or CA is the PKI management en tity that terminates the Certificate Management Protocol. If the RA terminates C MP, it either responds directly as described in <xref target="RA_response" forma t="default"/>, or it forwards the certificate management operation towards the C A not using CMP. <xref target="RA_forwarde_messages" format="default"/> describe s different options of how an RA can forward a CMP message using CMP. <xref targ et="RA_on-behalf" format="default"/> offers the option that an RA operates on be half on an EE and therefore takes the role of the EE in <xref target="EE_UseCase s" format="default"/>.</t>
<t keepWithNext="true"/> <t keepWithNext="true"/>
<table anchor="PKIManOp_support" align="left"> <table anchor="PKIManOp_support" align="left">
<name>Level of Support for PKI Management Operations and Variants</n ame> <name>Level of Support for PKI Management Operations and Variants</n ame>
<thead> <thead>
<tr> <tr>
<th align="left">ID</th> <th align="left">ID</th>
<th align="left">PKI Management Operations and Variants</th> <th align="left">PKI Management Operations and Variants</th>
<th align="left">EE</th> <th align="left">EE</th>
<th align="left">RA</th> <th align="left">RA</th>
<th align="left">CA</th> <th align="left">CA</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Generic</td> <td align="left">Generic</td>
<td align="left"><xref target="GenericParts" format="title"/>, < <td align="left">Generic Aspects of PKI Messages and PKI Managem
xref target="GenericParts" format="default"/></td> ent Operations, <xref target="GenericParts" format="default"/></td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">IR</td> <td align="left">IR</td>
<td align="left"><xref target="EE_newPKI" format="title"/>, <xre <td align="left">Enrolling an End Entity to a New PKI, <xref tar
f target="EE_newPKI" format="default"/></td> get="EE_newPKI" format="default"/></td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">CR</td> <td align="left">CR</td>
<td align="left"><xref target="EE_trustedPKI" format="title"/>, <td align="left">Enrolling an End Entity to a Known PKI, <xref t
<xref target="EE_trustedPKI" format="default"/></td> arget="EE_trustedPKI" format="default"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">KUR</td> <td align="left">KUR</td>
<td align="left"><xref target="EE_Update" format="title"/>, <xre <td align="left">Updating a Valid Certificate, <xref target="EE_
f target="EE_Update" format="default"/></td> Update" format="default"/></td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">P10CR</td> <td align="left">P10CR</td>
<td align="left"><xref target="EE_P10" format="title"/>, <xref t <td align="left"> Enrolling an End Entity Using a PKCS #10
arget="EE_P10" format="default"/></td> Request, <xref target="EE_P10" format="default"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">MAC</td> <td align="left">MAC</td>
<td align="left"><xref target="EE_MAC" format="title"/>, with IR <td align="left">Using MAC-Based Protection for Enrollment (IR,
, CR, and P10CR if supported, <xref target="EE_MAC" format="default"/></td> CR, and P10CR if supported), <xref target="EE_MAC" format="default"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">SHOULD 1)</td> <td align="left"><bcp14>SHOULD</bcp14> 1)</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">CKeyGen</td> <td align="left">CKeyGen</td>
<td align="left"><xref target="EE_centralKeyGeneration" format=" <td align="left">Adding Central Key Pair Generation to Enrollmen
title"/>, IR, CR, KUR, and P10CR if supported, <xref target="EE_centralKeyGenera t (IR, CR, KUR, and P10CR if supported), <xref target="EE_centralKeyGeneration"
tion" format="default"/></td> format="default"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">RR</td> <td align="left">RR</td>
<td align="left"><xref target="EE_Revoke" format="title"/>, <xre <td align="left">Revoking a Certificate, <xref target="EE_Revoke
f target="EE_Revoke" format="default"/></td> " format="default"/></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
<td align="left">SHOULD 2)</td> <td align="left"><bcp14>SHOULD</bcp14> 2)</td>
<td align="left">SHOULD 3)</td> <td align="left"><bcp14>SHOULD</bcp14> 3)</td>
</tr> </tr>
<tr> <tr>
<td align="left">CACerts</td> <td align="left">CACerts</td>
<td align="left"><xref target="EE_CACerts" format="title"/>, <xr <td align="left">Get CA Certificates, <xref target="EE_CACerts"
ef target="EE_CACerts" format="default"/></td> format="default"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">RootUpd</td> <td align="left">RootUpd</td>
<td align="left"><xref target="EE_RootCAUpdate" format="title"/> <td align="left">Get Root CA Certificate Update, <xref target="E
, <xref target="EE_RootCAUpdate" format="default"/></td> E_RootCAUpdate" format="default"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">ReqTempl</td> <td align="left">ReqTempl</td>
<td align="left"><xref target="EE_Temp" format="title"/>, <xref <td align="left">Get Certificate Request Template, <xref target=
target="EE_Temp" format="default"/></td> "EE_Temp" format="default"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">CRLUpd</td> <td align="left">CRLUpd</td>
<td align="left"><xref target="EE_CRLs" format="title"/>, <xref <td align="left">CRL Update Retrieval, <xref target="EE_CRLs" fo
target="EE_CRLs" format="default"/></td> rmat="default"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">Polling</td> <td align="left">Polling</td>
<td align="left"><xref target="EE_Polling" format="title"/>, <xr <td align="left">Handling Delayed Delivery, <xref target="EE_Pol
ef target="EE_Polling" format="default"/></td> ling" format="default"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">CertResp</td> <td align="left">CertResp</td>
<td align="left"><xref target="RA_response_enrollment" format="t itle"/> (IR, CR, KUR, and P10CR if supported), <xref target="RA_response_enrollm ent" format="default"/></td> <td align="left">Responding to a Certificate Request (IR, CR, KU R, and P10CR if supported), <xref target="RA_response_enrollment" format="defaul t"/></td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">CertConf</td> <td align="left">CertConf</td>
<td align="left"><xref target="RA_response_confirmation" format= "title"/>, <xref target="RA_response_confirmation" format="default"/></td> <td align="left">Responding to a Confirmation Message, <xref tar get="RA_response_confirmation" format="default"/></td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">RevResp</td> <td align="left">RevResp</td>
<td align="left"><xref target="RA_response_revocation" format="t itle"/>, <xref target="RA_response_revocation" format="default"/></td> <td align="left">Responding to a Revocation Request, <xref targe t="RA_response_revocation" format="default"/></td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">GenResp</td> <td align="left">GenResp</td>
<td align="left"><xref target="RA_response_support" format="titl e"/> (CACerts, RootUpd, ReqTempl, CRLUpd if supported), <xref target="RA_respons e_support" format="default"/></td> <td align="left">Responding to a Support Message (CACerts, RootU pd, ReqTempl, CRLUpd if supported), <xref target="RA_response_support" format="d efault"/></td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">InitPoll</td> <td align="left">InitPoll</td>
<td align="left"><xref target="RA_response_polling" format="titl e"/>, <xref target="RA_response_polling" format="default"/></td> <td align="left">Initiating Delayed Delivery, <xref target="RA_r esponse_polling" format="default"/></td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">FwdKeep</td> <td align="left">FwdKeep</td>
<td align="left"><xref target="RA_forwarde_messages" format="tit le"/> - <xref target="RA_noChange" format="title"/>, <xref target="RA_noChange" format="default"/></td> <td align="left">Forwarding Messages - Not Changing Protection, <xref target="RA_noChange" format="default"/></td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
<td align="left">N/A</td> <td align="left">N/A</td>
</tr> </tr>
<tr> <tr>
<td align="left">FwdAddS</td> <td align="left">FwdAddS</td>
<td align="left"><xref target="RA_forwarde_messages" format="tit le"/> - <xref target="RA_AddSingel" format="title"/>, <xref target="RA_AddSingel " format="default"/></td> <td align="left">Forwarding Messages - Adding Protection to a Re quest Message, <xref target="RA_AddSingel" format="default"/></td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">FwdAddB</td> <td align="left">FwdAddB</td>
<td align="left"><xref target="RA_forwarde_messages" format="tit le"/> - <xref target="RA_AddBatch" format="title"/>, <xref target="RA_AddBatch" format="default"/></td> <td align="left">Forwarding Messages - Batching Messages, <xref target="RA_AddBatch" format="default"/></td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">FwdReqKP</td> <td align="left">FwdReqKP</td>
<td align="left"><xref target="RA_forwarde_messages" format="tit le"/> - <xref target="RA_keepPOPO" format="title"/>, <xref target="RA_keepPOPO" format="default"/></td> <td align="left">Forwarding Messages - Not Changing Proof-of-Pos session, <xref target="RA_keepPOPO" format="default"/></td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">SHOULD 1)</td> <td align="left"><bcp14>SHOULD</bcp14> 1)</td>
<td align="left">N/A</td> <td align="left">N/A</td>
</tr> </tr>
<tr> <tr>
<td align="left">FwdReqBP</td> <td align="left">FwdReqBP</td>
<td align="left"><xref target="RA_forwarde_messages" format="tit le"/> - <xref target="RA_breakPOPO" format="title"/>, <xref target="RA_breakPOPO " format="default"/></td> <td align="left">Forwarding Messages - Using raVerified, <xref t arget="RA_breakPOPO" format="default"/></td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">CertROnB</td> <td align="left">CertROnB</td>
<td align="left"><xref target="RA_on-behalf" format="title"/> - <xref target="RA_on-behalf_request" format="title"/>, <xref target="RA_on-behalf _request" format="default"/></td> <td align="left">Acting on Behalf of Other PKI Entities - Reques ting a Certificate, <xref target="RA_on-behalf_request" format="default"/></td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">N/A</td> <td align="left">N/A</td>
</tr> </tr>
<tr> <tr>
<td align="left">RevROnB</td> <td align="left">RevROnB</td>
<td align="left"><xref target="RA_on-behalf" format="title"/> - <xref target="RA_on-behalf_revoke" format="title"/>, <xref target="RA_on-behalf_ revoke" format="default"/></td> <td align="left">Acting on Behalf of Other PKI Entities - Revoki ng a Certificate, <xref target="RA_on-behalf_revoke" format="default"/></td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">SHOULD 2)</td> <td align="left"><bcp14>SHOULD</bcp14> 2)</td>
<td align="left">SHOULD 3)</td> <td align="left"><bcp14>SHOULD</bcp14> 3)</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>1) The RA should be able to change the CMP message protectio <ol type="%d)" spacing="normal">
n from MAC-based to signature-based protection, see <xref target="RA_keepPOPO" f <li>The RA should be able to change the CMP message protection
ormat="default"/>.</t> from MAC-based to signature-based protection; see <xref target="RA_keepPOPO" for
<t>2) The RA should be able to request certificate revocation o mat="default"/>.</li>
n behalf of an EE, see <xref target="RA_on-behalf_revoke" format="default"/>, e. <li>The RA should be able to request certificate revocation on
g., in order to handle incidents.</t> behalf of an EE (see <xref target="RA_on-behalf_revoke" format="default"/>), e.g
<t>3) An alternative would be to perform revocation at the CA w ., in order to handle incidents.</li>
ithout using CMP, for instance using a local administration interface.</t> <li>An alternative would be to perform revocation at the CA wit
hout using CMP, for instance, using a local administration interface.</li>
</ol>
</section> </section>
<section anchor="Transport" numbered="true" toc="default"> <section anchor="Transport" numbered="true" toc="default">
<name>Message Transfer</name> <name>Message Transfer</name>
<t>CMP does not have specific needs regarding message transfer, e <t>CMP does not have specific needs regarding message transfer, e
xcept that for each request message sent, eventually a sequence of one response xcept that, for each request message sent, eventually a sequence of one response
message should be received. Therefore, virtually any reliable transfer mechanis message should be received. Therefore, virtually any reliable transfer mechani
m can be used, such as HTTP, CoAP, and file-based offline transfer. Thus, this sm can be used, such as HTTP, CoAP, and file-based offline transfer. Thus, this
document does not require any specific transfer protocol to be supported by conf document does not require any specific transfer protocol to be supported by con
orming implementations.</t> forming implementations.</t>
<t>On different links between PKI entities, e.g., EE-RA and RA-CA <t>On different links between PKI entities (e.g., EE-RA and RA-CA
, different transfer mechanisms as specified in <xref target="Transfer_types" fo ), different transfer mechanisms, as specified in <xref target="Transfer_types"
rmat="default"/> may be used.</t> format="default"/>, may be used.</t>
<t>HTTP SHOULD be supported and CoAP MAY be supported at all PKI <t>HTTP <bcp14>SHOULD</bcp14> be supported and CoAP <bcp14>MAY</b
entities for maximizing general interoperability at transfer level. Yet full fle cp14> be supported at all PKI entities for maximizing general interoperability a
xibility is retained to choose whatever transfer mechanism is suitable, for inst t transfer level. Yet full flexibility is retained to choose whatever transfer m
ance for devices and system architectures with specific constraints.</t> echanism is suitable, for instance, for devices and system architectures with sp
ecific constraints.</t>
<t>The following table lists the name and level of support specif ied for each transfer mechanism.</t> <t>The following table lists the name and level of support specif ied for each transfer mechanism.</t>
<table anchor="Trans_Support" align="left"> <table anchor="Trans_Support" align="left">
<name>Level of Support for Message Transfer Types</name> <name>Level of Support for Message Transfer Types</name>
<thead> <thead>
<tr> <tr>
<th align="left">ID</th> <th align="left">ID</th>
<th align="left">Message Transfer Type</th> <th align="left">Message Transfer Type</th>
<th align="left">EE</th> <th align="left">EE</th>
<th align="left">RA</th> <th align="left">RA</th>
<th align="left">CA</th> <th align="left">CA</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">HTTP</td> <td align="left">HTTP</td>
<td align="left"><xref target="HTTP" format="title"/>, <xref tar <td align="left">HTTP Transfer, <xref target="HTTP" format="defa
get="HTTP" format="default"/></td> ult"/></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">CoAP</td> <td align="left">CoAP</td>
<td align="left"><xref target="CoAP" format="title"/>, <xref tar <td align="left">CoAP Transfer, <xref target="CoAP" format="defa
get="CoAP" format="default"/></td> ult"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">Piggyb</td> <td align="left">Piggyb</td>
<td align="left"><xref target="Piggybacking" format="title"/>, < <td align="left">Piggybacking on Other Reliable Transfer, <xref
xref target="Piggybacking" format="default"/></td> target="Piggybacking" format="default"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">Offline</td> <td align="left">Offline</td>
<td align="left"><xref target="Offline" format="title"/>, <xref <td align="left">Offline Transfer, <xref target="Offline" format
target="Offline" format="default"/></td> ="default"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document defines new entries with the following content in the "CMP Well-Known URI Path Segments" registry (see https://www.iana.org/assignment s/cmp/) as defined in <xref target="RFC8615" format="default">RFC&nbsp;8615</xre f>.</t> <t>IANA has registered the following content in the "CMP Well-Known URI Path Segments" registry (see <eref brackets="angle" target="https://www.iana.or g/assignments/cmp"/>), as defined in <xref target="RFC8615" format="default"/>.< /t>
<table anchor="Trans_operationLabels" align="left"> <table anchor="Trans_operationLabels" align="left">
<name>New "CMP Well-Known URI Path Segments" Registry Entries</name> <name>New "CMP Well-Known URI Path Segments" Registry Entries</name>
<thead> <thead>
<tr> <tr>
<th align="left">Path Segment</th> <th align="left">Path Segment</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">initialization</td> <td align="left">initialization</td>
<td align="left"><xref target="EE_newPKI" format="title"/> over HT <td align="left">Enrolling an End Entity to a New PKI over HTTP</t
TP</td> d>
<td align="left">[thisRFC]</td> <td align="left">RFC 9483, <xref target="EE_newPKI" format="defaul
t"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">certification</td> <td align="left">certification</td>
<td align="left"><xref target="EE_trustedPKI" format="title"/> ove <td align="left">Enrolling an End Entity to a Known PKI over HTTP<
r HTTP</td> /td>
<td align="left">[thisRFC]</td> <td align="left">RFC 9483, <xref target="EE_trustedPKI" format="de
fault"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">keyupdate</td> <td align="left">keyupdate</td>
<td align="left"><xref target="EE_Update" format="title"/> over HT <td align="left">Updating a Valid Certificate over HTTP</td>
TP</td> <td align="left">RFC 9483, <xref target="EE_Update" format="defaul
<td align="left">[thisRFC]</td> t"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">pkcs10</td> <td align="left">pkcs10</td>
<td align="left"><xref target="EE_P10" format="title"/> over HTTP< <td align="left">Enrolling an End Entity Using a PKCS #10 Request
/td> over HTTP</td>
<td align="left">[thisRFC]</td> <td align="left">RFC 9483, <xref target="EE_P10" format="default"/
></td>
</tr> </tr>
<tr> <tr>
<td align="left">revocation</td> <td align="left">revocation</td>
<td align="left"><xref target="EE_Revoke" format="title"/> over HT <td align="left">Revoking a Certificate over HTTP</td>
TP</td> <td align="left">RFC 9483, <xref target="EE_Revoke" format="defaul
<td align="left">[thisRFC]</td> t"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">getcacerts</td> <td align="left">getcacerts</td>
<td align="left"><xref target="EE_CACerts" format="title"/> over H <td align="left">Get CA Certificates over HTTP</td>
TTP</td> <td align="left">RFC 9483, <xref target="EE_CACerts" format="defau
<td align="left">[thisRFC]</td> lt"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">getrootupdate</td> <td align="left">getrootupdate</td>
<td align="left"><xref target="EE_RootCAUpdate" format="title"/> o <td align="left">Get Root CA Certificate Update over HTTP</td>
ver HTTP</td> <td align="left">RFC 9483, <xref target="EE_RootCAUpdate" format="
<td align="left">[thisRFC]</td> default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">getcertreqtemplate</td> <td align="left">getcertreqtemplate</td>
<td align="left"><xref target="EE_Temp" format="title"/> over HTTP <td align="left">Get Certificate Request Template over HTTP</td>
</td> <td align="left">RFC 9483, <xref target="EE_Temp" format="default"
<td align="left">[thisRFC]</td> /></td>
</tr> </tr>
<tr> <tr>
<td align="left">getcrls</td> <td align="left">getcrls</td>
<td align="left"><xref target="EE_CRLs" format="title"/> over HTTP <td align="left">CRL Update Retrieval over HTTP</td>
</td> <td align="left">RFC 9483, <xref target="EE_CRLs" format="default"
<td align="left">[thisRFC]</td> /></td>
</tr> </tr>
<tr> <tr>
<td align="left">nested</td> <td align="left">nested</td>
<td align="left"><xref target="RA_AddBatch" format="title"/> over <td align="left">Batching Messages over HTTP</td>
HTTP</td> <td align="left">RFC 9483, <xref target="RA_AddBatch" format="defa
<td align="left">[thisRFC]</td> ult"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">ir</td> <td align="left">ir</td>
<td align="left"><xref target="EE_newPKI" format="title"/> over Co <td align="left">Enrolling an End Entity to a New PKI over CoAP</t
AP</td> d>
<td align="left">[thisRFC]</td> <td align="left">RFC 9483, <xref target="EE_newPKI" format="defaul
t"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">cr</td> <td align="left">cr</td>
<td align="left"><xref target="EE_trustedPKI" format="title"/> ove <td align="left">Enrolling an End Entity to a Known PKI over CoAP<
r CoAP</td> /td>
<td align="left">[thisRFC]</td> <td align="left">RFC 9483, <xref target="EE_trustedPKI" format="de
fault"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">kur</td> <td align="left">kur</td>
<td align="left"><xref target="EE_Update" format="title"/> over Co <td align="left">Updating a Valid Certificate over CoAP</td>
AP</td> <td align="left">RFC 9483, <xref target="EE_Update" format="defaul
<td align="left">[thisRFC]</td> t"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">p10</td> <td align="left">p10</td>
<td align="left"><xref target="EE_P10" format="title"/> over CoAP< <td align="left">Enrolling an End Entity Using a PKCS #10 Request
/td> over CoAP</td>
<td align="left">[thisRFC]</td> <td align="left">RFC 9483, <xref target="EE_P10" format="default"/
></td>
</tr> </tr>
<tr> <tr>
<td align="left">rr</td> <td align="left">rr</td>
<td align="left"><xref target="EE_Revoke" format="title"/> over Co <td align="left">Revoking a Certificate over CoAP</td>
AP</td> <td align="left">RFC 9483, <xref target="EE_Revoke" format="defaul
<td align="left">[thisRFC]</td> t"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">crts</td> <td align="left">crts</td>
<td align="left"><xref target="EE_CACerts" format="title"/> over C <td align="left">Get CA Certificates over CoAP</td>
oAP</td> <td align="left">RFC 9483, <xref target="EE_CACerts" format="defau
<td align="left">[thisRFC]</td> lt"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">rcu</td> <td align="left">rcu</td>
<td align="left"><xref target="EE_RootCAUpdate" format="title"/> o <td align="left">Get Root CA Certificate Update over CoAP</td>
ver CoAP</td> <td align="left">RFC 9483, <xref target="EE_RootCAUpdate" format="
<td align="left">[thisRFC]</td> default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">att</td> <td align="left">att</td>
<td align="left"><xref target="EE_Temp" format="title"/> over CoAP <td align="left">Get Certificate Request Template over CoAP</td>
</td> <td align="left">RFC 9483, <xref target="EE_Temp" format="default"
<td align="left">[thisRFC]</td> /></td>
</tr> </tr>
<tr> <tr>
<td align="left">crls</td> <td align="left">crls</td>
<td align="left"><xref target="EE_CRLs" format="title"/> over CoAP <td align="left">CRL Update Retrieval over CoAP</td>
</td> <td align="left">RFC 9483, <xref target="EE_CRLs" format="default"
<td align="left">[thisRFC]</td> /></td>
</tr> </tr>
<tr> <tr>
<td align="left">nest</td> <td align="left">nest</td>
<td align="left"><xref target="RA_AddBatch" format="title"/> over <td align="left">Batching Messages over CoAP</td>
CoAP</td> <td align="left">RFC 9483, <xref target="RA_AddBatch" format="defa
<td align="left">[thisRFC]</td> ult"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>&lt; TBD: New entries must be added to the registry "CMP Wel l-Known URI Path Segments". &gt;</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The security considerations as laid out in <xref target="RFC4210" forma <t>The security considerations laid out in <xref target="RFC4210" format="
t="default">CMP</xref> updated by <xref target="I-D.ietf-lamps-cmp-updates" form default">CMP</xref> and updated by <xref target="RFC9480" format="default">CMP U
at="default">CMP Updates</xref> and <xref target="I-D.ietf-lamps-cmp-algorithms" pdates</xref>, <xref target="RFC9481" format="default">CMP Algorithms</xref>, <x
format="default">CMP Algorithms</xref>, <xref target="RFC4211" format="default" ref target="RFC4211" format="default">CRMF</xref>, <xref target="RFC9045" format
>CRMF</xref> updated by <xref target="RFC9045" format="default">Algorithm Requir ="default">Algorithm Requirements Update</xref>, <xref target="RFC6712" format="
ements Update</xref>, <xref target="RFC6712" format="default">CMP over HTTP</xre default">CMP over HTTP</xref>, and <xref target="RFC9482" format="default">CMP o
f>, and <xref target="I-D.ietf-ace-cmpv2-coap-transport" format="default">CMP ov ver CoAP</xref> apply.</t>
er CoAP</xref> apply.</t> <t>Trust anchors for chain validations are often provided in the form o
<t>Trust anchors for chain validations are often provided in the form o f self-signed certificates. All trust anchors <bcp14>MUST</bcp14> be stored on t
f self-signed certificates. All trust anchors MUST be stored on the device with he device with integrity protection. In some cases, a PKI entity may not have su
integrity protection. In some cases, a PKI entity may not have sufficient storag fficient storage for the complete certificates. In such cases, it may only store
e for the complete certificates. In such cases it may only store, e.g., a hash o , e.g., a hash of each self-signed certificate and require receiving the certifi
f each self-signed certificate and require receiving the certificate in the extr cate in the extraCerts field, as described in <xref target="extraCerts" format="
aCerts field as described in <xref target="extraCerts" format="default"/>. If su default"/>. If such self-signed certificates are provided in-band in the message
ch self-signed certificates are provided in-band in the messages, they MUST be v s, they <bcp14>MUST</bcp14> be verified using information from the trust store o
erified using information from the trust store of the PKI entity.</t> f the PKI entity.</t>
<t>For TLS using shared secret information-based authentication, both PSK <t>For TLS using shared secret information-based authentication, both PSK
and PAKE provide the same amount of protection against a real-time authenticatio and PAKE provide the same amount of protection against a real-time authenticatio
n attack which is directly the amount of entropy in the shared secret. The diffe n attack, which is directly the amount of entropy in the shared secret. The diff
rence between a pre-shared key (PSK) and a password-authenticated key exchange ( erence between a pre-shared key (PSK) and a password-authenticated key exchange
PAKE) protocol is in the level of long-term confidentiality of the TLS messages (PAKE) protocol is in the level of long-term confidentiality of the TLS messages
against brute-force decryption, where a PSK-based cipher suite only provides sec against brute-force decryption, where a PSK-based cipher suite only provides se
urity according to the entropy of the shared secret, while a PAKE-based cipher s curity according to the entropy of the shared secret, while a PAKE-based cipher
uite provides full security independent of the entropy of the shared secret.</t> suite provides full security independent of the entropy of the shared secret.</t
</section> >
<section anchor="Acknowledgements" numbered="true" toc="default">
<name>Acknowledgements</name>
<t>We thank the various reviewers of this document.</t>
</section> </section>
</middle> </middle>
<back> <back>
<!-- References split into informative and normative --> <displayreference target="I-D.ietf-anima-brski-ae" to="BRSKI-AE"/>
<displayreference target="I-D.ietf-anima-brski-prm" to="BRSKI-PRM"/>
<!-- There are 2 ways to insert reference entries from the citation libraries <displayreference target="I-D.ietf-netconf-sztp-csr" to="SZTP-CSR"/>
: <displayreference target="I-D.ietf-lamps-rfc4210bis" to="PKIX-CMP"/>
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here ( <displayreference target="I-D.ietf-lamps-rfc6712bis" to="HTTP-CMP"/>
as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml
"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x
ml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included fil
es in the same
directory as the including file. You can also define the XML_LIBRARY environ
ment variable
with a value containing a set of directories to search. These can be either
in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RF <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
C.2119.xml"?--> 19.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refe <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
rence.RFC.2119.xml"/> 986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.2986.xml"/> 210.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.4210.xml"/> 211.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
FC.4211.xml"/> 280.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
FC.5280.xml"/> 652.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
FC.5652.xml"/> 958.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
FC.5958.xml"/> 712.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.6712.xml"/> 174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RF
FC.8174.xml"/> C.8615.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refe <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
rence.RFC.8615.xml"/> 933.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
FC.8933.xml"/> 045.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
FC.9045.xml"/> 110.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
FC.9110.xml"/> 325.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9325.xml"/> <reference anchor="RFC9480" target="https://www.rfc-editor.org/info/rfc9480">
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-la <front>
mps-cmp-updates.xml"/> <title>Certificate Management Protocol (CMP) Updates</title>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-la <author fullname="Hendrik Brockhaus" initials="H." surname="Brockhaus">
mps-cmp-algorithms.xml"/> <organization>Siemens</organization>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ac </author>
e-cmpv2-coap-transport.xml"/> <author fullname="David von Oheimb" initials="D." surname="von Oheimb">
<organization>Siemens</organization>
</author>
<author fullname="John Gray" initials="J." surname="Gray">
<organization>Entrust</organization>
</author>
<date month="October" year="2023"/>
</front>
<seriesInfo name="RFC" value="9480"/>
<seriesInfo name="DOI" value="10.17487/RFC9480"/>
</reference>
<reference anchor="RFC9481" target="https://www.rfc-editor.org/info/rfc9481">
<front>
<title>Certificate Management Protocol (CMP) Algorithms</title>
<author fullname="Hendrik Brockhaus" initials="H." surname="Brockhaus">
<organization>Siemens AG</organization>
</author>
<author fullname="Hans Aschauer" initials="H." surname="Aschauer">
<organization>Siemens AG</organization>
</author>
<author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
<organization>Entrust</organization>
</author>
<author fullname="John Gray" initials="J." surname="Gray">
<organization>Entrust</organization>
</author>
<date month="October" year="2023"/>
</front>
<seriesInfo name="RFC" value="9481"/>
<seriesInfo name="DOI" value="10.17487/RFC9481"/>
</reference>
<reference anchor="RFC9482" target="https://www.rfc-editor.org/info/rfc9482">
<front>
<title>
Constrained Application Protocol (CoAP) Transfer for the Certificate Management
Protocol
</title>
<author fullname="Mohit Sahni" initials="M." surname="Sahni" role="editor">
<organization>Palo Alto Networks</organization>
</author>
<author fullname="Saurabh Tripathi" initials="S." surname="Tripathi" role="edito
r">
<organization>Palo Alto Networks</organization>
</author>
<date month="October" year="2023"/>
</front>
<seriesInfo name="RFC" value="9482"/>
<seriesInfo name="DOI" value="10.17487/RFC9482"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RF <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
C.2119.xml"?--> 647.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
FC.3647.xml"/> 246.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
FC.5246.xml"/> 753.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
FC.5753.xml"/> 030.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
FC.7030.xml"/> 252.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.7252.xml"/> 366.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8366.xml"/> 446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8446.xml"/> 551.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8551.xml"/> 572.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8572.xml"/> 649.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8649.xml"/> 995.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8995.xml"/> <reference anchor="I-D.ietf-anima-brski-ae" target="https://datatracker.ietf.org
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-an /doc/html/draft-ietf-anima-brski-ae-05">
ima-brski-ae.xml"/> <front>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-an <title>
ima-brski-prm.xml"/> BRSKI-AE: Alternative Enrollment Protocols in BRSKI
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ne </title>
tconf-sztp-csr.xml"/> <author fullname="David von Oheimb" initials="D." surname="von Oheimb">
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-la <organization>Siemens AG</organization>
mps-rfc4210bis.xml"/> </author>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-la <author fullname="Steffen Fries" initials="S." surname="Fries">
mps-rfc6712bis.xml"/> <organization>Siemens AG</organization>
<!-- A reference written by an organization not a person. --> </author>
<author fullname="Hendrik Brockhaus" initials="H." surname="Brockhaus">
<organization>Siemens AG</organization>
</author>
<date day="28" month="June" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-brski-ae-05"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ani
ma-brski-prm.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-net
conf-sztp-csr.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lam
ps-rfc4210bis.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-lamps-rfc6712bis.xml"/>
<reference anchor="NIST.CSWP.04162018" target="http://nvlpubs.nis t.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf"> <reference anchor="NIST.CSWP.04162018" target="http://nvlpubs.nis t.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf">
<front> <front>
<title>Framework for Improving Critical Infrastru <title>Framework for Improving Critical Infrastructure Cybers
cture Cybersecurity, Version 1.1</title> ecurity</title>
<author> <author>
<organization>National Institute of Stand <organization>National Institute of Standards and Technolog
ards and Technology (NIST)</organization> y (NIST)</organization>
</author> </author>
<date year="2018" month="April"/> <date year="2018" month="April"/>
</front> </front>
<seriesInfo name="NIST" value="NIST.CSWP.04162018"/> <refcontent>Version 1.1</refcontent>
<seriesInfo name="DOI" value="10.6028/NIST.CSWP.04162018" <seriesInfo name="DOI" value="10.6028/NIST.CSWP.04162018"/>
/>
</reference> </reference>
<reference anchor="NIST.SP.800-57p1r5" target="https://doi.org/10 .6028/NIST.SP.800-57pt1r5"> <reference anchor="NIST.SP.800-57p1r5" target="https://doi.org/10 .6028/NIST.SP.800-57pt1r5">
<front> <front>
<title>Recommendation for key management, part 1 <title>Recommendation for Key Management: Part 1 - General</t
:general</title> itle>
<author initials="E B" surname="Barker" fullname= <author initials="E" surname="Barker" fullname="Elaine Barker
"E B Barker"> ">
<organization/> <organization/>
</author> </author>
<date year="2020"/> <date year="2020" month="May"/>
</front> </front>
<seriesInfo name="NIST" value="NIST.SP.800-57pt1r5"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5
"/>
</reference> </reference>
<reference anchor="IEEE.802.1AR_2018" target="https://ieeexplore.ieee.o
rg/document/8423794"> <reference anchor="IEEE.802.1AR_2018" target="https://ieeexplore.
ieee.org/document/8423794">
<front> <front>
<title>IEEE Standard for Local and metropolitan area netw <title>IEEE Standard for Local and Metropolitan Area Networks -
orks - Secure Device Identity</title> Secure Device Identity</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date day="2" month="August" year="2018"/> <date month="August" year="2018"/>
</front> </front>
<seriesInfo name="IEEE" value="802.1AR-2018"/> <seriesInfo name="IEEE Std" value="802.1AR-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8423794"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8423794"/>
</reference> </reference>
<reference anchor="ETSI-3GPP.33.310" target="http://www.3gpp.org/ ftp/Specs/html-info/33310.htm"> <reference anchor="ETSI-3GPP.33.310" target="http://www.3gpp.org/ ftp/Specs/html-info/33310.htm">
<front> <front>
<title>Network Domain Security (NDS); Authenticat <title>Network Domain Security (NDS); Authentication Framewor
ion Framework (AF)</title> k (AF)</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date day="16" month="December" year="2020"/> <date month="December" year="2020"/>
</front> </front>
<seriesInfo name="3GPP TS" value="33.310 16.6.0"/> <seriesInfo name="3GPP TS" value="33.310 16.6.0"/>
</reference> </reference>
<reference anchor="ETSI-EN.319411-1" target="https://www.etsi.org /deliver/etsi_en/319400_319499/31941101/01.03.01_60/en_31941101v010301p.pdf"> <reference anchor="ETSI-EN.319411-1" target="https://www.etsi.org /deliver/etsi_en/319400_319499/31941101/01.03.01_60/en_31941101v010301p.pdf">
<front> <front>
<title>Electronic Signatures and Infrastructures <title>Electronic Signatures and Infrastructures (ESI); Polic
(ESI); Policy and security requirements for Trust Service Providers issuing cert y and security requirements for Trust Service Providers issuing certificates; Pa
ificates; Part 1: General requirements</title> rt 1: General requirements</title>
<author> <author>
<organization>ETSI</organization> <organization>ETSI</organization>
</author> </author>
<date month="May" year="2021"/> <date month="May" year="2021"/>
</front> </front>
<seriesInfo name="ETSI EN" value="319 411-1 V1.3.1"/> <seriesInfo name="ETSI EN" value="319 411-1"/>
<refcontent>V1.3.1</refcontent>
</reference> </reference>
<reference anchor="UNISIG.Subset-137" target="https://www.era.europa.eu/
sites/default/files/filesystem/ertms/ccs_tsi_annex_a_-_mandatory_specifications/ <reference anchor="UNISIG.Subset-137" target="https://www.era.eur
set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-_subset-137_v100.pdf"> opa.eu/system/files/2023-01/sos3_index083_-_subset-137_v100.pdf">
<front> <front>
<title>Subset-137; ERTMS/ETCS On-line Key Management FFFIS; V1.0.0</ <title>ERTMS/ETCS On-line Key Management FFFIS</title>
title> <author>
<author> <organization>UNISIG</organization>
<organization>UNISIG</organization> </author>
</author> <date month="December" year="2015"/>
<date month="December" year="2015"/> </front>
</front> <refcontent>Subset-137, V1.0.0</refcontent>
</reference> </reference>
<reference anchor="IEC.62443-3-3" target="https://webstore.iec.ch/public ation/7033"> <reference anchor="IEC.62443-3-3" target="https://webstore.iec.ch/public ation/7033">
<front> <front>
<title>Industrial communication networks - Network and system securi ty - Part 3-3: System security requirements and security levels</title> <title>Industrial communication networks - Network and system securi ty - Part 3-3: System security requirements and security levels</title>
<author> <author>
<organization>IEC</organization> <organization>IEC</organization>
</author> </author>
<date month="August" year="2013"/> <date month="August" year="2013"/>
</front> </front>
<seriesInfo name="IEC" value="62443-3-3"/> <seriesInfo name="IEC" value="62443-3-3:2013"/>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="Param_Example" numbered="true" toc="default"> <section anchor="Param_Example" numbered="true" toc="default">
<name>Example CertReqTemplate</name> <name>Example CertReqTemplate</name>
<t keepWithNext="true">Suppose the server requires that the certTemplate c ontains</t> <t keepWithNext="true">Suppose the server requires that the certTemplate c ontains:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the issuer field with a value to be filled in by the EE,</li> <li>the issuer field with a value to be filled in by the EE,</li>
<li>the subject field with a common name to be filled in by the EE and t wo organizational unit fields with given values "myDept" and "myGroup",</li> <li>the subject field with a common name to be filled in by the EE and t wo organizational unit fields with given values "myDept" and "myGroup",</li>
<li>the publicKey field contains an ECC key on curve secp256r1 or an RSA public key of length 2048,</li> <li>the publicKey field contains an Elliptic Curve Cryptography (ECC) ke y on curve secp256r1 or an RSA public key of length 2048,</li>
<li>the subjectAltName extension with DNS name "www.myServer.com" and an IP address to be filled in,</li> <li>the subjectAltName extension with DNS name "www.myServer.com" and an IP address to be filled in,</li>
<li>the keyUsage extension marked critical with the value digitalSignatu re and keyAgreement, and</li> <li>the keyUsage extension marked critical with the value digitalSignatu re and keyAgreement, and</li>
<li>the extKeyUsage extension with values to be filled in by the EE.</li > <li>the extKeyUsage extension with values to be filled in by the EE.</li >
</ul> </ul>
<t keepWithNext="true">Then the infoValue with certTemplate and keySpec fi elds returned to the EE will be encoded as follows:</t> <t keepWithNext="true">Then the infoValue with certTemplate and keySpec fi elds returned to the EE will be encoded as follows:</t>
<artwork align="left" name="Example_CertReqTemplate" type="" alt=""><![CDA TA[ <artwork align="left" name="" type="" alt=""><![CDATA[
SEQUENCE { SEQUENCE {
SEQUENCE { SEQUENCE {
[3] { [3] {
SEQUENCE {} SEQUENCE {}
} }
[5] { [5] {
SEQUENCE { SEQUENCE {
SET { SET {
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER commonName (2 5 4 3) OBJECT IDENTIFIER commonName (2 5 4 3)
skipping to change at line 2812 skipping to change at line 2864
} }
} }
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12) OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12)
INTEGER 2048 INTEGER 2048
} }
} }
} }
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="History" numbered="true" toc="default"> <section anchor="Acknowledgements" numbered="false" toc="default">
<name>History of Changes</name> <name>Acknowledgements</name>
<t>Note: This appendix will be deleted in the final version of the documen <t>We thank the various reviewers of this document.</t>
t.</t>
<t keepWithNext="true">From version 20 -&gt; 21:</t>
<ul spacing="compact">
<li>Addressed comment from Murray checking each usage of key word "SH
OULD" and changing it to "MUST", "MAY", or "should" where needed or adding an ex
planation how interoperability may be affected (see thread "Murray Kucherawy's N
o Objection on draft-ietf-lamps-lightweight-cmp-profile-18: (with COMMENT)")</li
>
<li>Some minor editorial changes</li>
</ul>
<t keepWithNext="true">From version 19 -&gt; 20:</t>
<ul spacing="compact">
<li>Addressed comment from John (see thread "[IANA #1261900] expert r
eview for draft-ietf-lamps-lightweight-cmp-profile (cmp)")</li>
</ul>
<t keepWithNext="true">From version 18 -&gt; 19:</t>
<ul spacing="compact">
<li>Addressed comment from Murray, moving section 'Convention and Ter
minology' after Section 1.1 and adding a paragraph on the use of key word "SHOUL
D", moving section 'Compatibility with Existing CMP Profiles' right before secti
on 'Use of CMP in SZTP and BRSKI Environments', and adding a paragraph to sectio
n 'Scope of this Document' also clarifying the use of key word "SHOULD" (see thr
ead "Murray Kucherawy's No Objection on draft-ietf-lamps-lightweight-cmp-profile
-18: (with COMMENT)")</li>
<li>Updated Section 4.1.6 to reflect the changes to CMP Updates on gu
idance which CMS key management technique to use with central key management (se
e thread "CMS: selection of key management technique to use for EnvelopedData")
and removed normative language regarding which key management technique to suppo
rt</li>
</ul>
<t keepWithNext="true">From version 17 -&gt; 18:</t>
<ul spacing="compact">
<li>Addressed comment from Paul (see thread "Paul Wouters' Yes on dra
ft-ietf-lamps-lightweight-cmp-profile-16: (with COMMENT)")</li>
<li>Updated Section 4.3.4 with one minor correction and one clarifica
tion (see thread "Minor change to draft-ietf-lamps-lightweight-cmp-profile-17 on
Section 4.3.4 CRL Update Retrieval")</li>
</ul>
<t keepWithNext="true">From version 16 -&gt; 17:</t>
<ul spacing="compact">
<li>Addressed comment from Paul (see thread "Paul Wouters' Yes on dra
ft-ietf-lamps-lightweight-cmp-profile-16: (with COMMENT)")</li>
<li>Addressed comment from Robert (see thread “Robert Wilton’s No Obj
ection on draft-ietf-lamps-lightweight-cmp-profile-16: (with COMMENT)")</li>
</ul>
<t keepWithNext="true">From version 15 -&gt; 16:</t>
<ul spacing="compact">
<li>Addressed comment from Warren (see thread "Warren Kumari's No Rec
ord on draft-ietf-lamps-lightweight-cmp-profile-15: (with COMMENT)")</li>
<li>Addressed comment from Sheng (see thread "Intdir telechat review
of draft-ietf-lamps-lightweight-cmp-profile-15")</li>
<li>Addressed comment from Niklas (see thread "Iotdir telechat review
of draft-ietf-lamps-lightweight-cmp-profile-15")</li>
<li>Addressed comment from Erik (see thread "Erik Kline's No Objectio
n on draft-ietf-lamps-lightweight-cmp-profile-15: (with COMMENT)")</li>
<li>Streamlined wording in two ASN.1 comments</li>
</ul>
<t keepWithNext="true">From version 14 -&gt; 15:</t>
<ul spacing="compact">
<li>Added a reference to HashOfRootKey extension to note in Section 3
.3</li>
<li>Addressed comment from Joel (see thread "Genart last call review
of draft-ietf-lamps-lightweight-cmp-profile-14")</li>
<li>Addressed comment from Robert (see thread "Artart last call revie
w of draft-ietf-lamps-lightweight-cmp-profile-14")</li>
</ul>
<t keepWithNext="true">From version 13 -&gt; 14:</t>
<ul spacing="compact">
<li>Addressed comments from AD Evaluation (see thread "AD Review of d
raft-ietf-lamps-lightweight-cmp-profile-13")</li>
<li>Added a note to Section 1 informing about rfc4210bis and rfc6712b
is activity</li>
<li>Added support for constrained PKI entities that can, e.g., only s
tore a hash of a self-signed certificate as trust anchor and require the self-si
gned certificate to be provided in-line in extraCerts, see Section 3.3 and Secti
on 9</li>
<li>Addressed idnits feedback, specifically changing the followin
g RFC reference: RFC3278 -> RFC5753</li>
</ul>
<t keepWithNext="true">From version 12 -&gt; 13:</t>
<ul spacing="compact">
<li>Some minor clarifications regarding 'exactly one element' -> 'seq
uence of one element'</li>
<li>Adding authors contact details</li>
</ul>
<t keepWithNext="true">From version 11 -&gt; 12:</t>
<ul spacing="compact">
<li>Added a note to Section 4.1.6 to clarify the combination of centr
al key generation with certificate update</li>
<li>Updated Section 4.3.4 for clarification that only one CRL per rou
nd-trip is requested</li>
<li>Updated Section 7.1 to fix a wrong change from the last update in
the first two rows of Table 3</li>
</ul>
<t keepWithNext="true">From version 10 -&gt; 11:</t>
<ul spacing="compact">
<li>Updated Section 3.2, 3.5, and 3.6.4 to define more clearly signat
ure-based protection as the default and the exception for not protecting error m
essages as mentioned at IETF 113</li>
<li>Streamlined headlines in Section 4.1</li>
<li>Updates Section 6.1 and Section 6.2 regarding new well-known path
segment for profile labels as discussed during IETF 113</li>
<li>Updated Section 7.1. on the support of PKI management operations
required for EEs, RAs, and CAs as mentioned at IETF 113</li>
<li>Updates Section 8 adding well-known path segments on PKI manageme
nt operations to be used with HTTP and CoAP</li>
<li>Capitalized all headlines</li>
</ul>
<t keepWithNext="true">From version 09 -&gt; 10:</t>
<ul spacing="compact">
<li>Resolved some nits reported by I-D nit checker tool</li>
<li>Resolve some wording issues</li>
</ul>
<t keepWithNext="true">From version 08 -&gt; 09:</t>
<ul spacing="compact">
<li>Updated Section 1.1 and 1.2 and converted Section 2.2 and 2.3 int
o more detailed tables in Section 7 (see thread "WG Last Call for draft-ietf-lam
ps-cmp-updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08")</li>
<li>Updated Section 3.1 and 4.1.1 making implicitConfirm recommended for
ir/cr/p10cr/kur and providing further recommendations on its use (see thread "c
ertConf - WG Last Call for draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-
lightweight-cmp-profile-08")</li>
<li>Updated Section 4.1.6 adding some clarifications regarding valida
ting the authorization of centrally generated keys</li>
<li>Updated Section 4.3.4 adding some clarifications on CRL update retri
eval (see thread "CRL update retrieval - WG Last Call for draft-ietf-lamps-cmp-u
pdates-14 and draft-ietf-lamps-lightweight-cmp-profile-08")</li>
<li>Updated references to CMP Updates pointing to concrete sections (
see thread "CRL update retrieval - WG Last Call for draft-ietf-lamps-cmp-updates
-14 and draft-ietf-lamps-lightweight-cmp-profile-08"))</li>
<li>Corrected a couple of nits elsewhere</li>
</ul>
<t keepWithNext="true">From version 07 -&gt; 08:</t>
<ul spacing="compact">
<li>Updates Section 4.1.6.1. regarding content of the originator and
keyEncryptionAlgorithm fields (see thread "AD review of draft-ietf-lamps-cmp-alg
orithms-07")</li>
<li>Rolled back part of the changes on root CA certificate updates in Se
ction 4.3.2 (see thread "Allocation of OIDs for CRL update retrieval (draft-ietf
-lamps-cmp-updates-13)")</li>
</ul>
<t keepWithNext="true">From version 06 -&gt; 07:</t>
<ul spacing="compact">
<li>Added references to [draft-ietf-netconf-sztp-csr] in new Section
1.5 and Section 4.1.4</li>
<li>Added reference to [I-D.ietf-anima-brski-ae] in new Section 1.5 and
Section 4.1.1</li>
<li>Changed reference in Section 2 to [I-D.ietf-anima-brski-prm] as the
PUSH use case is continued to be discussed in this draft after the split of BRSK
I-AE</li>
<li>Improved note regarding UNISIG Subset-137 in Section 1.6</li>
<li>Removed "rootCaCert" in Section 3.1 and updated the structure of the
genm request for root CA certificate updates in Section 4.3.2.</li>
<li>Simplified handling of sender and recipient nonces in case of delaye
d delivery in Sections 3.1, 3.5, 4.4, and 5.1.2</li>
<li>Changed the order of Sections 4.1.4 and 4.1.5</li>
<li>Added reference on RFC 8933 regarding CMS signedAttrs to Section 4.1
.6</li>
<li>Added Section 4.3.4 on CRL update retrieval</li>
<li>Generalized delayed enrollment to delayed delivery in Section 4.4 an
d 5.1.2, updated the state machine in the introduction of Section 4</li>
<li>Updated Section 6 regarding delayed message transfer</li>
<li>Changed file name extension from ".PKI" to ".pki", deleted operation
al path for central key generation, and added an operational path for CRL update
retrieval in Sections 6.1 and 6.2</li>
<li>Shifted many security considerations to CMP Updates</li>
<li>Replaced the term "transport" by "transfer" where appropriate to pre
vent confusion regarding TCP vs. HTTP and CoAP</li>
<li>Various editorial changes and language corrections</li>
</ul>
<t keepWithNext="true">From version 05 -&gt; 06:</t>
<ul spacing="compact">
<li>Changed in Section 2.3 the normative requirement in of adding pro
tection to a single message to mandatory and replacing protection to optional</l
i>
<li>Added Section 3.4 specifying generic prerequisites to PKI management
operations</li>
<li>Added Section 3.5 specifying generic message validation</li>
<li>Added Section 3.6 on generic error reporting. This section replaces
the former error handling section from Section 4 and 5.</li>
<li>Added reference to using hashAlg</li>
<li>Updates Section 4.3.2 and Section 4.3.3 to align with CMP Updates</l
i>
<li>Added Section 5.1 specifying the behavior of PKI management entities
when responding to requests</li>
<li>Reworked Section 5.2.3. on usage of nested messages</li>
<li>Updates Section 5.3 on performing PKI management operation on behalf
of another entity</li>
<li>Updates Section 6.2 on HTTPS transport of CMP messages as discusses
at IETF 110 and email thread "I-D Action: draft-ietf-lamps-lightweight-cmp-profi
le-05.txt"</li>
<li>Added CoAP endpoints to Section 6.4</li>
<li>Added security considerations on usage of shared secret information<
/li>
<li>Updated the example in Appendix A</li>
<li>Added newly registered OIDs to the example in Appendix A</li>
<li>Updated new RFC numbers for I-D.ietf-lamps-crmf-update-algs</li>
<li>Multiple language corrections, clarifications, and changes in wordin
g</li>
</ul>
<t keepWithNext="true">From version 04 -&gt; 05:</t>
<ul spacing="compact">
<li>Changed to XML V3</li>
<li>Added algorithm names introduced in CMP Algorithms Section 7.3 to Se
ction 4 of this document</li>
<li>Updates Syntax in Section 4.4.3 due to changes made in CMP Updates</
li>
<li>Deleted the text on HTTP-based discovery as discussed in Section 6.1
</li>
<li>Updates Appendix A due to change syntax in Section 4.4.3</li>
<li>Many clarifications and changes in wording thanks to David's extensi
ve review</li>
</ul>
<t keepWithNext="true">From version 03 -&gt; 04:</t>
<ul spacing="compact">
<li>Deleted normative text sections on algorithms and refer to CMP Algor
ithms and CRMF Algorithm Requirements Update instead</li>
<li>Some clarifications and changes in wording</li>
</ul>
<t keepWithNext="true">From version 02 -&gt; 03:</t>
<ul spacing="compact">
<li>Updated the interoperability with [UNISIG.Subset-137] in Section 1.4
.</li>
<li>Changed Section 2.3 to a tabular layout to enhanced readability</li>
<li>Added a ToDo to section 3.1 on aligning with the CMP Algorithms draf
t that will be set up as decided in IETF 108</li>
<li>Updated section 4.1.6 to add the AsymmetricKey Package structure to
transport a newly generated private key as decided in IETF 108</li>
<li>Added a ToDo to section 4.1.7 on required review of the nonce handli
ng in case an offline LRA responds and not forwards the pollReq messages</li>
<li>Updated Section 4 due to the definition of the new ITAV OIDs in CMP
Updates</li>
<li>Updated Section 4.4.4 to utilize controls instead of rsaKeyLen (see
thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen")</li>
<li>Deleted the section on definition and discovery of HTTP URIs and cop
ied the text to the HTTP transport section and to CMP Updates section 3.2</li>
<li>Added some explanation to Section 5.1.2 and Section 5.1.3 on using n
ested messages when a protection by the RA is required.</li>
<li>Deleted the section on HTTP URI definition and discovery as some con
tent was moved to CMP Updates. The rest of the content was moved back to the HTT
P transport section</li>
<li>Deleted the ASN.1 module after moving the new OIDs id-it-caCerts, id
-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates</li>
<li>Minor changes in wording and addition of some open ToDos</li>
</ul>
<t keepWithNext="true">From version 01 -&gt; 02:</t>
<ul spacing="compact">
<li>Extend <xref target="Compatibility" format="default"/> with regard t
o conflicts with UNISIG Subset-137.</li>
<li>Minor clarifications on extraCerts in <xref target="extraCerts" form
at="default"/> and <xref target="EE_newPKI" format="default"/>.</li>
<li>Complete specification of requesting a certificate from a trusted PK
I with signature protection in <xref target="EE_trustedPKI" format="default"/>.<
/li>
<li>Changed from symmetric key-encryption to password-based key manageme
nt technique in <xref target="EE_KGPB" format="default"/> as discussed on the m
ailing list (see thread "draft-ietf-lamps-lightweight-cmp-profile-01, section 5.
1.6.1")</li>
<li>Changed delayed enrollment described in <xref target="EE_Polling" fo
rmat="default"/> from recommended to optional as decided at IETF 107</li>
<li>Introduced the new RootCAKeyUpdate structure for root CA certificate
update in <xref target="EE_RootCAUpdate" format="default"/> as decided at IETF
107 (also see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, section
5.4.3")</li>
<li>Extend the description of the CertReqTemplate PKI management operati
on, including an example added in the Appendix. Keep rsaKeyLen as a single inte
ger value in <xref target="EE_Temp" format="default"/> as discussed on the maili
ng list (see thread "draft-ietf-lamps-lightweight-cmp-profile-01, section 5.4.4"
)</li>
<li>Deleted Sections "Get certificate management configuration" and "Get
enrollment voucher" as decided at IETF 107</li>
<li>Complete specification of adding an additional protection by an PKI
management entity in <xref target="RA_Add" format="default"/>.</li>
<li>Added a section on HTTP URI definition and discovery and extended <x
ref target="HTTP" format="default"/> on definition and discovery of supported HT
TP URIs and content types, add a path for nested messages as specified in <xref
target="RA_Add" format="default"/> and delete the paths for /getCertMgtConfig an
d /getVoucher</li>
<li>Changed <xref target="Offline" format="default"/> to address offline
transport and added more detailed specification file-based transport of CMP</li
>
<li>Added a reference to the new I-D of Mohit Sahni on "CoAP Transport f
or CMPV2" in <xref target="CoAP" format="default"/>; thanks to Mohit supporting
the effort to ease utilization of CMP</li>
<li>Moved the change history to the Appendix</li>
<li>Minor changes in wording</li>
</ul>
<t keepWithNext="true">From version 00 -&gt; 01:</t>
<ul spacing="compact">
<li>
<t>Harmonize terminology with <xref target="RFC4210" format="default">
CMP</xref>, e.g.,</t>
<ul spacing="compact">
<li>transaction, message sequence, exchange, use case -&gt; PKI mana
gement operation</li>
<li>PKI component, (L)RA/CA -&gt; PKI management entity</li>
</ul>
</li>
<li>Minor changes in wording</li>
</ul>
<t keepWithNext="true">From draft-brockhaus-lamps-lightweight-cmp-profile-
03 -&gt; draft-ietf-lamps-lightweight-cmp-profile-00:</t>
<ul spacing="compact">
<li>Changes required to reflect WG adoption</li>
<li>Minor changes in wording</li>
</ul>
<t keepWithNext="true">From version 02 -&gt; 03:</t>
<ul spacing="compact">
<li>Added a short summary of <xref target="RFC4210" format="default"/> A
ppendix D and E in <xref target="Existing_profiles" format="default"/>.</li>
<li>Clarified some references to different sections and added some clari
fication in response to feedback from Michael Richardson and Tomas Gustavsson.</
li>
<li>Added an additional label to the operational path to address multipl
e CAs or certificate profiles in <xref target="HTTP" format="default"/>.</li>
</ul>
<t keepWithNext="true">From version 01 -&gt; 02:</t>
<ul spacing="compact">
<li>Added some clarification on the key management techniques for protec
tion of centrally generated keys in <xref target="EE_centralKeyGeneration" forma
t="default"/>.</li>
<li>Added some clarifications on the certificates for root CA certificat
e update in <xref target="EE_RootCAUpdate" format="default"/>.</li>
<li>Added a section to specify the usage of nested messages for RAs to a
dd an additional protection for further discussion, see <xref target="RA_Add" fo
rmat="default"/>.</li>
<li>Added a table containing endpoints for HTTP transport in <xref targe
t="HTTP" format="default"/> to simplify addressing PKI management entities.</li>
<li>Added some ToDos resulting from discussion with Tomas Gustavsson.</l
i>
<li>Minor clarifications and changes in wording.</li>
</ul>
<t keepWithNext="true">From version 00 -&gt; 01:</t>
<ul spacing="compact">
<li>Added a section to specify the enrollment with an already trusted PK
I for further discussion, see <xref target="EE_trustedPKI" format="default"/>.</
li>
<li>Complete specification of requesting a certificate from a legacy PKI
using a <xref target="RFC2986" format="default">PKCS#10</xref> request in <xref
target="EE_P10" format="default"/>.</li>
<li>Complete specification of adding central generation of a key pair on
behalf of an end entity in <xref target="EE_centralKeyGeneration" format="defau
lt"/>.</li>
<li>Complete specification of handling delayed enrollment due to asynchr
onous message delivery in <xref target="EE_Polling" format="default"/>.</li>
<li>Complete specification of additional support messages, e.g., to upda
te a Root CA certificate or to request an <xref target="RFC8366" format="default
">RFC&nbsp;8366</xref> voucher, in <xref target="EE_GeneralMessage" format="defa
ult"/>.</li>
<li>Minor changes in wording.</li>
</ul>
<t keepWithNext="true">From draft-brockhaus-lamps-industrial-cmp-profile-0
0 -&gt; draft-brockhaus-lamps-lightweight-cmp-profile-00:</t>
<ul spacing="compact">
<li>Change focus from industrial to more multi-purpose use cases and lig
htweight CMP profile.</li>
<li>Incorporate the omitted confirmation into the header specified in <x
ref target="Header" format="default"/> and described in the standard enrollment
use case in <xref target="EE_newPKI" format="default"/> due to discussion with T
omas Gustavsson.</li>
<li>Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's e
ntities certificate' in <xref target="RA_on-behalf_revoke" format="default"/>, b
ecause it is regarded as important functionality in many environments to enable
the management station to revoke EE certificates.</li>
<li>Complete the specification of the revocation message flow in <xref t
arget="EE_Revoke" format="default"/> and <xref target="RA_on-behalf_revoke" form
at="default"/>.</li>
<li>The CoAP based transport mechanism and piggybacking of CMP messages
on top of other reliable transport protocols is out of scope of this document an
d would need to be specified in another document.</li>
<li>Further minor changes in wording.</li>
</ul>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 398 change blocks. 
2433 lines changed or deleted 2176 lines changed or added

This html diff was produced by rfcdiff 1.48.