rfc9481.original.xml   rfc9481.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), <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
please see http://xml.resource.org/authoring/README.html. --> submissionType="IETF"
<?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"
category="std" category="std"
docName="draft-ietf-lamps-cmp-algorithms-15" consensus="true"
docName="draft-ietf-lamps-cmp-algorithms-16"
number="9481"
ipr="trust200902" ipr="trust200902"
obsoletes="" obsoletes=""
updates="4210" updates="4210"
submissionType="IETF"
xml:lang="en" xml:lang="en"
tocInclude="true" tocInclude="true"
tocDepth="3" tocDepth="3"
symRefs="true" symRefs="true"
sortRefs="true" sortRefs="true"
consensus="true"
version="3"> version="3">
<front> <front>
<title abbrev="CMP Algorithms">Certificate Management Protocol (C <title abbrev="CMP Algorithms">Certificate Management Protocol (CMP) Algo
MP) Algorithms</title> rithms</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cmp-alg <seriesInfo name="RFC" value="9481"/>
orithms-15"/> <author fullname="Hendrik Brockhaus" initials="H." surname="Brockhaus">
<!-- add 'role="editor"' below for the editors if appropriate --> <organization abbrev="Siemens">Siemens AG</organization>
<!-- Another author who claims to be an editor --> <address>
<author fullname="Hendrik Brockhaus" initials="H." surname="Brock <postal>
haus" role="editor"> <street>Werner-von-Siemens-Strasse 1</street>
<organization abbrev="Siemens">Siemens AG</organization> <code>80333</code>
<address> <city>Munich</city>
<postal> <country>Germany</country>
<street/> </postal>
<code/> <email>hendrik.brockhaus@siemens.com</email>
<city/> <uri>https://www.siemens.com</uri>
<country/> </address>
</postal> </author>
<phone/>
<email>hendrik.brockhaus@siemens.com</email> <author fullname="Hans Aschauer" initials="H." surname="Aschauer">
<uri/> <organization abbrev="Siemens">Siemens AG</organization>
</address> <address>
</author> <postal>
<author fullname="Hans Aschauer" initials="H." surname="Aschauer" <street>Werner-von-Siemens-Strasse 1</street>
> <code>80333</code>
<organization abbrev="Siemens">Siemens AG</organization> <city>Munich</city>
<address> <country>Germany</country>
<postal> </postal>
<street/> <email>hans.aschauer@siemens.com</email>
<code/> <uri>https://www.siemens.com</uri>
<city/> </address>
<country/> </author>
</postal>
<phone/> <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
<email>hans.aschauer@siemens.com</email> <organization abbrev="Entrust">Entrust</organization>
<uri/> <address>
</address> <postal>
</author> <street>1187 Park Place</street>
<author fullname="Mike Ounsworth" initials="M." surname="Ounswort <region>MN</region>
h"> <code>55379</code>
<organization abbrev="Entrust">Entrust</organization> <city>Minneapolis</city>
<address> <country>United States of America</country>
<postal> </postal>
<street/> <email>mike.ounsworth@entrust.com</email>
<code/> <uri>https://www.entrust.com</uri>
<city/> </address>
<country/> </author>
</postal>
<phone/> <author fullname="John Gray" initials="J." surname="Gray">
<email>mike.ounsworth@entrust.com</email> <organization abbrev="Entrust">Entrust</organization>
<uri/> <address>
</address> <postal>
</author> <street>1187 Park Place</street>
<author fullname="John Gray" initials="J." surname="Gray"> <region>MN</region>
<organization abbrev="Entrust">Entrust</organization> <code>55379</code>
<address> <city>Minneapolis</city>
<postal> <country>United States of America</country>
<street/> </postal>
<code/> <email>john.gray@entrust.com</email>
<city/> <uri>https://www.entrust.com</uri>
<country/> </address>
</postal> </author>
<phone/> <date year="2023" month="October"/>
<email>john.gray@entrust.com</email> <area>sec</area>
<uri/> <workgroup>lamps</workgroup>
</address> <keyword>CMP</keyword>
</author>
<date year="2022"/>
<!-- If the month and year are both specified and are the current
ones, xml2rfc will fill
in the current day for you. If only the current year is specified, 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>
<workgroup>LAMPS Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>CMP</keyword>
<abstract> <abstract>
<t>This document describes the conventions for using seve ral cryptographic algorithms with the Certificate Management Protocol (CMP). CM P is used to enroll and further manage the lifecycle of X.509 certificates. Thi s document also updates the algorithm use profile from RFC 4210 Appendix D.2.</t > <t>This document describes the conventions for using seve ral cryptographic algorithms with the Certificate Management Protocol (CMP). CM P is used to enroll and further manage the lifecycle of X.509 certificates. Thi s document also updates the algorithm use profile from Appendix D.2 of RFC 4210. </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" title="Introduction"> <section anchor="Introduction">
<t><xref target="RFC4210">RFC&nbsp;4210 Appendix D.2</xre <name>Introduction</name>
f> contains a set of algorithms, mandatory to be supported by conforming impleme <t><xref target="RFC4210" sectionFormat="of" section="D.2"/> co
ntations. These algorithms were appropriate at the time CMP was released, but as ntains a set of algorithms that is mandatory to be supported by implementations
cryptographic algorithms weaken over time, some of them should not be used anym conforming to <xref target="RFC4210"/>. These algorithms were appropriate at the
ore. In general, new attacks are emerging due to research cryptoanalysis or incr time CMP was released, but as cryptographic algorithms weaken over time, some o
ease in computing power. New algorithms were introduced that are more resistant f them should no longer be used.
to today's attacks.</t> In general, new attacks are emerging due to research in cryptan
<t>This document lists current cryptographic algorithms u alysis or an increase in computing power. New algorithms were introduced that ar
sable with CMP to offer an easier way maintaining the list of suitable algorithm e more resistant to today's attacks.</t>
s over time.</t> <t>This document lists current cryptographic algorithms t
<section anchor="Terminology" title="Terminology"> hat can be used with CMP to offer an easier way to maintain the list of suitable
<t>The key words "MUST", "MUST NOT", "REQUIRED", algorithms over time.</t>
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", <section anchor="Terminology">
"MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP <name>Terminology</name>
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they <t>
appear in all capitals, as shown here.</t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<t>In the following sections ASN.1 values and typ IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
es are used to indicate where algorithm identifier and output values are provide NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
d. These ASN.1 values and types are defined in <xref target="RFC4210">CMP</xref> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
, <xref target="RFC4211">CRMF</xref>, <xref target="I-D.ietf-lamps-cmp-updates"> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
CMP Updates</xref>, or <xref target="RFC5652">CMS</xref>.</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>In the following sections, ASN.1 values and ty
pes are used to indicate where algorithm identifier and output values are provid
ed. These ASN.1 values and types are defined in <xref target="RFC4210">CMP</xref
>, <xref target="RFC4211">Certificate Request Message Format (CRMF)</xref>, <xre
f target="RFC9480">CMP Updates</xref>, and <xref target="RFC5652">Cryptographic
Message Syntax (CMS)</xref>.</t>
</section> </section>
</section> </section>
<section anchor="Hash" title="Message Digest Algorithms"> <section anchor="Hash">
<name>Message Digest Algorithms</name>
<t>This section provides references to object identifiers and conventions to be employed by CMP implementations that support SHA2 or SHAK E message digest algorithms.</t> <t>This section provides references to object identifiers and conventions to be employed by CMP implementations that support SHA2 or SHAK E message digest algorithms.</t>
<t keepWithNext="true">Digest algorithm identifiers are l ocated in:</t> <t keepWithNext="true">Digest algorithm identifiers are l ocated in the:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>hashAlg field of OOBCertHash and CertStatus</ <li>hashAlg field of OOBCertHash and CertStatus,<
li> /li>
<li>owf field of Challenge, PBMParameter, and DHB <li>owf field of Challenge, PBMParameter, and DHB
MParameter</li> MParameter,</li>
<li>digestAlgorithms field of SignedData</li> <li>digestAlgorithms field of SignedData, and</li
<li>digestAlgorithm field of SignerInfo</li> >
<li>digestAlgorithm field of SignerInfo.</li>
</ul> </ul>
<t keepWithNext="true">Digest values are located in:</t> <t keepWithNext="true">Digest values are located in the:< /t>
<ul spacing="compact"> <ul spacing="compact">
<li>hashVal field of OOBCertHash</li> <li>hashVal field of OOBCertHash,</li>
<li>certHash field of CertStatus</li> <li>certHash field of CertStatus, and</li>
<li>witness field of Challenge</li> <li>witness field of Challenge.</li>
</ul> </ul>
<t>In addition, digest values are input to signature algo rithms.</t> <t>In addition, digest values are input to signature algo rithms.</t>
<section anchor="SHA2" title="SHA2"> <section anchor="SHA2">
<t>The SHA2 algorithm family is defined in <xref <name>SHA2</name>
target="NIST.FIPS.180-4">FIPS&nbsp;Pub&nbsp;180-4</xref>.</t> <t>The SHA2 algorithm family is defined in <xref target
="NIST_FIPS_180_4">FIPS&nbsp;Pub&nbsp;180-4</xref>.</t>
<t keepWithNext="true">The message digest algorit hms SHA-224, SHA-256, SHA-384, and SHA-512 are identified by the following OIDs: </t> <t keepWithNext="true">The message digest algorit hms SHA-224, SHA-256, SHA-384, and SHA-512 are identified by the following OIDs: </t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) us(840) organization(1) gov(101) csor(3) nistalgorithm(4)
hashalgs(2) 4 } hashalgs(2) 4 }
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) us(840) organization(1) gov(101) csor(3) nistalgorithm(4)
hashalgs(2) 1 } hashalgs(2) 1 }
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) us(840) organization(1) gov(101) csor(3) nistalgorithm(4)
hashalgs(2) 2 } hashalgs(2) 2 }
id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) us(840) organization(1) gov(101) csor(3) nistalgorithm(4)
hashalgs(2) 3 } hashalgs(2) 3 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered are spec ified in <xref target="RFC5754">RFC&nbsp;5754 Section 2</xref>.</t> <t>Specific conventions to be considered are spec ified in <xref target="RFC5754" section="2" sectionFormat="of"/>.</t>
</section> </section>
<section anchor="SHAKE" title="SHAKE"> <section anchor="SHAKE">
<t>The SHA-3 family of hash functions is defined <name>SHAKE</name>
in <xref target="NIST.FIPS.202" format="default">FIPS&nbsp;Pub&nbsp;202</xref> a <t>The SHA-3 family of hash functions is defined
nd includes fixed output length variants SHA3-224, SHA3-256, SHA3-384, and SHA3- in <xref target="NIST_FIPS_202" format="default">FIPS&nbsp;Pub&nbsp;202</xref> a
512, as well as extendable-output functions (SHAKEs) SHAKE128 and SHAKE256. Curr nd consists of the fixed output length variants SHA3-224, SHA3-256, SHA3-384, an
ently, SHAKE128 and SHAKE256 are the only members of the SHA3-family which are s d SHA3-512, as well as the extendable-output functions (XOFs) SHAKE128 and SHAKE
pecified for use in X.509 certificates <xref target="RFC8692" format="default"/> 256. Currently, SHAKE128 and SHAKE256 are the only members of the SHA3-family th
and CMS <xref target="RFC8702" format="default"/> as one-way hash function for at are specified for use in X.509 certificates <xref target="RFC8692" format="de
use with RSASSA-PSS and ECDSA.</t> fault"/> and CMS <xref target="RFC8702" format="default"/> as one-way hash funct
<t>SHAKE is an extendable-output function and <xr ions for use with RSASSA-PSS and ECDSA.</t>
ef target="NIST.FIPS.202" format="default">FIPS&nbsp;Pub&nbsp;202</xref> prohibi <t>SHAKE is an extendable-output function, and <x
ts using SHAKE as general-purpose hash function. When SHAKE is used in CMP as a ref target="NIST_FIPS_202" format="default">FIPS&nbsp;Pub&nbsp;202</xref> prohib
message digest algorithm, the output length MUST be 256 bits for SHAKE128 and 5 its using SHAKE as a general-purpose hash function. When SHAKE is used in CMP a
12 bits for SHAKE256.</t> s a message digest algorithm, the output length <bcp14>MUST</bcp14> be 256 bits
for SHAKE128 and 512 bits for SHAKE256.</t>
<t keepWithNext="true">The message digest algorit hms SHAKE128 and SHAKE256 are identified by the following OIDs:</t> <t keepWithNext="true">The message digest algorit hms SHAKE128 and SHAKE256 are identified by the following OIDs:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4)
hashalgs(2) 11 } hashalgs(2) 11 }
id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4)
hashalgs(2) 12 } hashalgs(2) 12 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered are spec ified in <xref target="RFC8702">RFC&nbsp;8702 Section 3.1</xref>.</t> <t>Specific conventions to be considered are spec ified in <xref target="RFC8702" section="3.1" sectionFormat="of"/>.</t>
</section> </section>
</section> </section>
<section anchor="Sig" title="Signature Algorithms"> <section anchor="Sig">
<t>This section provides references to object identifiers <name>Signature Algorithms</name>
and conventions to be employed by CMP implementations that support RSA, ECDSA, <t>This section provides references to object identifiers
or EdDSA signature algorithms.</t> and conventions to be employed by CMP implementations that support signature al
<t>The signature algorithm is referred to as MSG_SIG_ALG gorithms like RSA, ECDSA, or EdDSA.</t>
in <xref target="AlgProfLWP"/>, <xref target="RFC4210">RFC&nbsp;4210 Appendix D <t>The signature algorithm is referred to as MSG_SIG_ALG
and E</xref>, and in the <xref target="I-D.ietf-lamps-lightweight-cmp-profile">L in Appendices <xref target="RFC4210" sectionFormat="bare" section="D"/> and <xre
ightweight CMP Profile</xref>.</t> f target="RFC4210" sectionFormat="bare" section="E"/> of <xref target="RFC4210"/
<t keepWithNext="true">Signature algorithm identifiers ar >, in the <xref target="RFC9483">Lightweight CMP Profile</xref>, and in <xref ta
e located in:</t> rget="AlgProfLWP"/>.</t>
<t keepWithNext="true">Signature algorithm identifiers ar
e located in the:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>protectionAlg field of PKIHeader</li> <li>protectionAlg field of PKIHeader,</li>
<li>algorithmIdentifier field of POPOSigningKey</ <li>algorithmIdentifier field of POPOSigningKey,
li> and</li>
<li>signatureAlgorithm field of CertificationRequ est, SignKeyPairTypes, and SignerInfo</li> <li>signatureAlgorithm field of CertificationRequ est, SignKeyPairTypes, and SignerInfo</li>
</ul> </ul>
<t keepWithNext="true">Signature values are located in:</ t> <t keepWithNext="true">Signature values are located in th e:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>protection field of PKIMessage</li> <li>protection field of PKIMessage,</li>
<li>signature field of POPOSigningKey</li> <li>signature field of POPOSigningKey, and</li>
<li>signature field of CertificationRequest and S <li>signature field of CertificationRequest and S
ignerInfo</li> ignerInfo.</li>
</ul> </ul>
<section anchor="RSASig" title="RSA"> <section anchor="RSASig">
<t>The RSA (RSASSA-PSS and PKCS#1 version 1.5) si <name>RSA</name>
gnature algorithm is defined in <xref target="RFC8017">RFC&nbsp;8017</xref>.</t> <t>The RSA (RSASSA-PSS and PKCS #1 version 1.5) s
ignature algorithm is defined in <xref target="RFC8017"/>.</t>
<t keepWithNext="true">The algorithm identifier f or RSASAA-PSS signatures used with SHA2 message digest algorithms is identified by the following OID:</t> <t keepWithNext="true">The algorithm identifier f or RSASAA-PSS signatures used with SHA2 message digest algorithms is identified by the following OID:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered are spec <t>Specific conventions to be considered are spec
ified in <xref target="RFC4056">RFC&nbsp;4056</xref>.</t> ified in <xref target="RFC4056"/>.</t>
<t keepWithNext="true">The signature algorithm RS <t keepWithNext="true">The signature algorithm RS
ASSA-PSS used with SHAKE message digest algorithms are identified by the followi ASSA-PSS used with SHAKE message digest algorithms is identified by the followin
ng OIDs:</t> g OIDs:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) 30 } mechanisms(5) pkix(7) algorithms(6) 30 }
id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) 31 } mechanisms(5) pkix(7) algorithms(6) 31 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered are spec <t>Specific conventions to be considered are spec
ified in <xref target="RFC8702">RFC&nbsp;8702 Section 3.2.1</xref>.</t> ified in <xref target="RFC8702" section="3.2.1" sectionFormat="of"/>.</t>
<t keepWithNext="true">The signature algorithm PK <t keepWithNext="true">The signature algorithm PK
CS#1 version 1.5 used with SHA2 message digest algorithms is identified by the f CS #1 version 1.5 used with SHA2 message digest algorithms is identified by the
ollowing OIDs:</t> following OIDs:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 }
sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 }
sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 }
sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered are spec ified in <xref target="RFC5754">RFC&nbsp;5754 Section 3.2</xref>.</t> <t>Specific conventions to be considered are spec ified in <xref target="RFC5754" section="3.2" sectionFormat="of"/>.</t>
</section> </section>
<section anchor="ECDSA" title="ECDSA"> <section anchor="ECDSA">
<t>The ECDSA signature algorithm is defined in <x <name>ECDSA</name>
ref target="NIST.FIPS.186-4">FIPS&nbsp;Pub&nbsp;186-4</xref>.</t> <t>The ECDSA signature algorithm is defined in <x
ref target="NIST.FIPS.186-5">FIPS&nbsp;Pub&nbsp;186-5</xref>.</t>
<t keepWithNext="true">The signature algorithm EC DSA used with SHA2 message digest algorithms is identified by the following OIDs :</t> <t keepWithNext="true">The signature algorithm EC DSA used with SHA2 message digest algorithms is identified by the following OIDs :</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 }
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 }
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 }
ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
]]></sourcecode> ]]></sourcecode>
<t keepWithNext="true">As specified in RFC 5480 [ <t keepWithNext="true">As specified in <xref targ
RFC5480] the NIST-recommended SECP curves are identified by the following OIDs:< et="RFC5480"/>, the NIST-recommended curves are identified by the following OIDs
/t> :</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } us(840) ansi-X9-62(10045) curves(3) prime(1) 1 }
secp224r1 OBJECT IDENTIFIER ::= { iso(1) secp224r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 33 } identified-organization(3) certicom(132) curve(0) 33 }
secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } us(840) ansi-X9-62(10045) curves(3) prime(1) 7 }
secp384r1 OBJECT IDENTIFIER ::= { iso(1) secp384r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 34 } identified-organization(3) certicom(132) curve(0) 34 }
secp521r1 OBJECT IDENTIFIER ::= { iso(1) secp521r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 35 } identified-organization(3) certicom(132) curve(0) 35 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered are spec <t>Specific conventions to be considered are spec
ified in <xref target="RFC5754">RFC&nbsp;5754 Section 3.3</xref>.</t> ified in <xref target="RFC5754" section="3.3" sectionFormat="of" />.</t>
<t keepWithNext="true">The signature algorithm EC <t keepWithNext="true">The signature algorithm EC
DSA used with SHAKE message digest algorithms are identified by the following OI DSA used with SHAKE message digest algorithms is identified by the following OID
Ds:</t> s:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) 32 } mechanisms(5) pkix(7) algorithms(6) 32 }
id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) 33 } mechanisms(5) pkix(7) algorithms(6) 33 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered are spec ified in <xref target="RFC8702">RFC&nbsp;8702 Section 3.2.2</xref>.</t> <t>Specific conventions to be considered are spec ified in <xref target="RFC8702" section="3.2.2" sectionFormat="of"/>.</t>
</section> </section>
<section anchor="EdDSA" title="EdDSA"> <section anchor="EdDSA">
<t>The EdDSA signature algorithm is defined in <x <name>EdDSA</name>
ref target="RFC8032">RFC&nbsp;8032 Section 3.3</xref> and <xref target="NIST.FIP <t>The EdDSA signature algorithm is defined in <x
S.186-5">FIPS&nbsp;Pub&nbsp;186-5 (Draft)</xref>.</t> ref target="RFC8032" section="3.3" sectionFormat="of"/> and <xref target="NIST.F
<t keepWithNext="true">The signature algorithm Ed IPS.186-5">FIPS&nbsp;Pub&nbsp;186-5</xref>.</t>
25519 that MUST be used with SHA-512 message digest algorithms is identified by <t keepWithNext="true">The signature algorithm Ed
the following OIDs:</t> 25519 that <bcp14>MUST</bcp14> be used with SHA-512 message digest algorithms is
identified by the following OIDs:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-Ed25519 OBJECT IDENTIFIER ::= { iso(1) id-Ed25519 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) thawte(101) 112 } identified-organization(3) thawte(101) 112 }
]]></sourcecode> ]]></sourcecode>
<t keepWithNext="true">The signature algorithm Ed 448 that MUST be used with SHAKE256 message digest algorithms is identified by t he following OIDs:</t> <t keepWithNext="true">The signature algorithm Ed 448 that <bcp14>MUST</bcp14> be used with SHAKE256 message digest algorithms is identified by the following OIDs:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-Ed448 OBJECT IDENTIFIER ::= { iso(1) id-Ed448 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) thawte(101) 113 } identified-organization(3) thawte(101) 113 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered are spec <t>Specific conventions to be considered are spec
ified in <xref target="RFC8419">RFC&nbsp;8419</xref>.</t> ified in <xref target="RFC8419"/>.</t>
<t>Note: The hash algorithm used to calculate the <t>Note: The hash algorithm used to calculate the
certHash in certConf messages MUST be SHA512 if the certificate to be confirmed certHash in certConf messages <bcp14>MUST</bcp14> be SHA512 if the certificate
has been signed using Ed25519 and SHAKE256 with d=512 if signed using Ed448.</t to be confirmed has been signed using Ed25519 or SHAKE256 with d=512 if the cert
> ificate to be confirmed has been signed using Ed448.</t>
</section> </section>
</section> </section>
<section anchor="KeyMan" title="Key Management Algorithms"> <section anchor="KeyMan">
<name>Key Management Algorithms</name>
<t>CMP utilizes the following general key management tech niques: key agreement, key transport, and passwords.</t> <t>CMP utilizes the following general key management tech niques: key agreement, key transport, and passwords.</t>
<t><xref target="RFC4211">CRMF</xref> and <xref target="I <t><xref target="RFC4211">CRMF</xref> and <xref target="R
-D.ietf-lamps-cmp-updates">CMP Updates</xref> promotes the use of <xref target=" FC9480">CMP Updates</xref> promote the use of <xref target="RFC5652">CMS Envelop
RFC5652">CMS</xref> EnvelopedData by deprecating the use of EncryptedValue.</t> edData</xref> by deprecating the use of EncryptedValue.</t>
<section anchor="KeyAgree" title="Key Agreement Algorithm <section anchor="KeyAgree">
s"> <name>Key Agreement Algorithms</name>
<t>The key agreement algorithm is referred to as <t>The key agreement algorithm is referred to as
PROT_ENC_ALG in <xref target="RFC4210">RFC&nbsp;4210 Appendix D and E</xref> and PROT_ENC_ALG in Appendices <xref target="RFC4210" sectionFormat="bare" section="
as KM_KA_ALG in the <xref target="I-D.ietf-lamps-lightweight-cmp-profile">Light D"/> and <xref target="RFC4210" sectionFormat="bare" section="E"/> of <xref targ
weight CMP Profile</xref>, as well as in <xref target="AlgProf"/>.</t> et="RFC4210"/> and as KM_KA_ALG in the <xref target="RFC9483">Lightweight CMP Pr
<t>Key agreement algorithms are only used in CMP ofile</xref> and <xref target="AlgProf"/>.</t>
when using <xref target="RFC5652">CMS</xref> EnvelopedData together with the key <t>Key agreement algorithms are only used in CMP
agreement key management technique. When a key agreement algorithm is used, a k when using <xref target="RFC5652">CMS EnvelopedData</xref> together with the key
ey-encryption algorithm (<xref target="SymKeyEnc"/>) is needed next to the conte agreement key management technique. When a key agreement algorithm is used, a k
nt-encryption algorithm (<xref target="Enc"/>).</t> ey-encryption algorithm (<xref target="SymKeyEnc"/>) is needed next to the conte
<t keepWithNext="true">Key agreement algorithm id nt-encryption algorithm (<xref target="Enc"/>).</t>
entifiers are located in:</t> <t keepWithNext="true">Key agreement algorithm id
entifiers are located in the:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>keyEncryptionAlgorithm field of KeyAg reeRecipientInfo</li> <li>keyEncryptionAlgorithm field of KeyAg reeRecipientInfo.</li>
</ul> </ul>
<t keepWithNext="true">Key wrap algorithm identif iers are located in:</t> <t keepWithNext="true">Key wrap algorithm identif iers are located in the:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>KeyWrapAlgorithm parameters within ke yEncryptionAlgorithm field of KeyAgreeRecipientInfo</li> <li>KeyWrapAlgorithm parameters within ke yEncryptionAlgorithm field of KeyAgreeRecipientInfo.</li>
</ul> </ul>
<t keepWithNext="true">Wrapped content-encryption keys are located in:</t> <t keepWithNext="true">Wrapped content-encryption keys are located in the:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>encryptedKey field of RecipientEncryp tedKeys</li> <li>encryptedKey field of RecipientEncryp tedKeys.</li>
</ul> </ul>
<section anchor="DH" title="Diffie-Hellman"> <section anchor="DH">
<t>Diffie-Hellman key agreement is define <name>Diffie-Hellman</name>
d in <xref target="RFC2631">RFC&nbsp;2631</xref> and SHALL be used in the epheme <t>The Diffie-Hellman (DH) key agreement
ral-static as specified in <xref target="RFC3370">RFC&nbsp;3370</xref>. Static-s is defined in <xref target="RFC2631"/> and <bcp14>SHALL</bcp14> be used in the e
tatic variants SHALL NOT be used.</t> phemeral-static variants, as specified in <xref target="RFC3370"/>. Static-stati
<t keepWithNext="true">The Diffie-Hellman c variants <bcp14>SHALL NOT</bcp14> be used.</t>
key agreement algorithm is identified by the following OID:</t> <t keepWithNext="true">The DH key agreeme
nt algorithm is identified by the following OID:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered are specified in <xref target="RFC3370">RFC&nbsp;3370 Section 4.1</xref>.</t> <t>Specific conventions to be considered are specified in <xref target="RFC3370" section="4.1" sectionFormat="of" />.</t>
</section> </section>
<section anchor="ECDH" title="ECDH"> <section anchor="ECDH">
<t>Elliptic Curve Diffie-Hellman (ECDH) k <name>ECDH</name>
ey agreement is defined in <xref target="RFC5753">RFC&nbsp;5753</xref> and SHALL <t>The Elliptic Curve Diffie-Hellman (ECD
be used in the ephemeral-static variant as specified in <xref target="RFC5753"> H) key agreement is defined in <xref target="RFC5753"/> and <bcp14>SHALL</bcp14>
RFC&nbsp;5753</xref> or the 1-Pass ECMQV variant as specified in <xref target="R be used in the ephemeral-static variant, as specified in <xref target="RFC5753"
FC5753">RFC&nbsp;5753</xref>. Static-static variants SHALL NOT be used.</t> />, or the 1-Pass Elliptic Curve Menezes-Qu-Vanstone (ECMQV) variant, as specifi
ed in <xref target="RFC5753"/>. Static-static variants <bcp14>SHALL NOT</bcp14>
be used.</t>
<t keepWithNext="true">The ECDH key agree ment algorithm used together with NIST-recommended SECP curves are identified by the following OIDs:</t> <t keepWithNext="true">The ECDH key agree ment algorithm used together with NIST-recommended SECP curves are identified by the following OIDs:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 11(11) 0 } identified-organization(3) certicom(132) schemes(1) 11(11) 0 }
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 11(11) 1 } identified-organization(3) certicom(132) schemes(1) 11(11) 1 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 11(11) 2 } identified-organization(3) certicom(132) schemes(1) 11(11) 2 }
dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 11(11) 3 } identified-organization(3) certicom(132) schemes(1) 11(11) 3 }
dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) iso(1) identified-organization(3) certicom(132) schemes(1)
14(14) 0 } 14(14) 0 }
dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) iso(1) identified-organization(3) certicom(132) schemes(1)
14(14) 1 } 14(14) 1 }
dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) iso(1) identified-organization(3) certicom(132) schemes(1)
14(14) 2 } 14(14) 2 }
dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) iso(1) identified-organization(3) certicom(132) schemes(1)
14(14) 3 } 14(14) 3 }
mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 15(15) 0 } identified-organization(3) certicom(132) schemes(1) 15(15) 0 }
mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 15(15) 1 } identified-organization(3) certicom(132) schemes(1) 15(15) 1 }
mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 15(15) 2 } identified-organization(3) certicom(132) schemes(1) 15(15) 2 }
mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 15(15) 3 } identified-organization(3) certicom(132) schemes(1) 15(15) 3 }
]]></sourcecode> ]]></sourcecode>
<t keepWithNext="true">As specified in <x ref target="RFC5480">RFC&nbsp;5480</xref> the NIST-recommended SECP curves are i dentified by the following OIDs:</t> <t keepWithNext="true">As specified in <x ref target="RFC5480"/>, the NIST-recommended SECP curves are identified by the f ollowing OIDs:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } us(840) ansi-X9-62(10045) curves(3) prime(1) 1 }
secp224r1 OBJECT IDENTIFIER ::= { iso(1) secp224r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 33 } identified-organization(3) certicom(132) curve(0) 33 }
secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } us(840) ansi-X9-62(10045) curves(3) prime(1) 7 }
secp384r1 OBJECT IDENTIFIER ::= { iso(1) secp384r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 34 } identified-organization(3) certicom(132) curve(0) 34 }
secp521r1 OBJECT IDENTIFIER ::= { iso(1) secp521r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 35 } identified-organization(3) certicom(132) curve(0) 35 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered <t>Specific conventions to be considered
are specified in <xref target="RFC5753">RFC&nbsp;5753</xref>.</t> are specified in <xref target="RFC5753"/>.</t>
<t keepWithNext="true">The ECDH key agree <t keepWithNext="true">The ECDH key agree
ment algorithm used together with curve25519 or curve448 are identified by the f ment algorithm used together with curve25519 or curve448 is identified by the fo
ollowing OIDs:</t> llowing OIDs:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-X25519 OBJECT IDENTIFIER ::= { iso(1) id-X25519 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) thawte(101) 110 } identified-organization(3) thawte(101) 110 }
id-X448 OBJECT IDENTIFIER ::= { iso(1) id-X448 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) thawte(101) 111 } identified-organization(3) thawte(101) 111 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered are specified in <xref target="RFC8418">RFC&nbsp;8418</xref>.</t> <t>Specific conventions to be considered are specified in <xref target="RFC8418"/>.</t>
</section> </section>
</section> </section>
<section anchor="KeyTrans" title="Key Transport Algorithm <section anchor="KeyTrans">
s"> <name>Key Transport Algorithms</name>
<t>The key transport algorithm is also referred t <t>The key transport algorithm is also referred t
o as PROT_ENC_ALG in <xref target="RFC4210">RFC&nbsp;4210 Appendix D and E</xref o as PROT_ENC_ALG in Appendices <xref target="RFC4210" sectionFormat="bare" sect
> and as KM_KL_ALG in the <xref target="I-D.ietf-lamps-lightweight-cmp-profile"> ion="D"/> and <xref target="RFC4210" sectionFormat="bare" section="E"/> of <xref
Lightweight CMP Profile</xref>, as well as in <xref target="AlgProf"/>.</t> target="RFC4210"/> and as KM_KT_ALG in the <xref target="RFC9483">Lightweight C
MP Profile</xref> and <xref target="AlgProf"/>.</t>
<t>Key transport algorithms are only used in CMP when using <xref target="RFC5652">CMS</xref> EnvelopedData together with the key transport key management technique.</t> <t>Key transport algorithms are only used in CMP when using <xref target="RFC5652">CMS</xref> EnvelopedData together with the key transport key management technique.</t>
<t keepWithNext="true">Key transport algorithm id entifiers are located in:</t> <t keepWithNext="true">Key transport algorithm id entifiers are located in the:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>keyEncryptionAlgorithm field of KeyTr ansRecipientInfo</li> <li>keyEncryptionAlgorithm field of KeyTr ansRecipientInfo.</li>
</ul> </ul>
<t keepWithNext="true">Key transport encrypted co ntent-encryption keys are located in:</t> <t keepWithNext="true">Key transport encrypted co ntent-encryption keys are located in the:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>encryptedKey field of KeyTransRecipie ntInfo</li> <li>encryptedKey field of KeyTransRecipie ntInfo.</li>
</ul> </ul>
<section anchor="RSAEnc" title="RSA"> <section anchor="RSAEnc">
<t>The RSA key transport algorithm is the <name>RSA</name>
RSA encryption scheme defined in <xref target="RFC8017">RFC&nbsp;8017</xref>.</ <t>The RSA key transport algorithm is the
t> RSA encryption scheme defined in <xref target="RFC8017"/>.</t>
<t keepWithNext="true">The algorithm iden tifier for RSA (PKCS #1 v1.5) is:</t> <t keepWithNext="true">The algorithm iden tifier for RSA (PKCS #1 v1.5) is:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
]]></sourcecode> ]]></sourcecode>
<t keepWithNext="true">The algorithm iden tifier for RSAES-OAEP is:</t> <t keepWithNext="true">The algorithm iden tifier for RSAES-OAEP is:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }
]]></sourcecode> ]]></sourcecode>
<t>Further conventions to be considered f or PKCS #1 v1.5 are specified in <xref target="RFC3370">RFC&nbsp;3370 Section 4. 2.1</xref> and for RSAES-OAEP in <xref target="RFC3560">RFC&nbsp;3560</xref>.</t > <t>Further conventions to be considered f or PKCS #1 v1.5 are specified in <xref target="RFC3370" section="4.2.1" sectionF ormat="of" /> and for RSAES-OAEP in <xref target="RFC3560"/>.</t>
</section> </section>
</section> </section>
<section anchor="SymKeyEnc" title="Symmetric Key-Encrypti <section anchor="SymKeyEnc">
on Algorithms"> <name>Symmetric Key-Encryption Algorithms</name>
<t>The symmetric key-encryption algorithm is also <t>The symmetric key-encryption algorithm is also
referred to as KM_KW_ALG in <xref target="AlgProfLWP"/> and in the <xref target referred to as KM_KW_ALG in <xref target="AlgProfLWP"/> and the <xref target="R
="I-D.ietf-lamps-lightweight-cmp-profile">Lightweight CMP Profile</xref>.</t> FC9483">Lightweight CMP Profile</xref>.</t>
<t>As symmetric key-encryption key management tec <t>As the symmetric key-encryption key management
hnique is not used by CMP, the symmetric key-encryption algorithm is only needed technique is not used by CMP, the symmetric key-encryption algorithm is only ne
when using the key agreement or password-based key management technique with <x eded when using the key agreement or password-based key management technique wit
ref target="RFC5652">CMS</xref> EnvelopedData.</t> h <xref target="RFC5652">CMS</xref> EnvelopedData.</t>
<t keepWithNext="true">Key wrap algorithm identif <t keepWithNext="true">Key wrap algorithm identif
iers are located in:</t> iers are located in the:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>parameters field of the KeyEncryption AlgorithmIdentifier of KeyAgreeRecipientInfo and PasswordRecipientInfo</li> <li>parameters field of the KeyEncryption AlgorithmIdentifier of KeyAgreeRecipientInfo and PasswordRecipientInfo.</li>
</ul> </ul>
<t keepWithNext="true">Wrapped content-encryption keys are located in:</t> <t keepWithNext="true">Wrapped content-encryption keys are located in the:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>encryptedKey field of RecipientEncryp tedKeys (for key agreement) and PasswordRecipientInfo (for password-based key ma nagement)</li> <li>encryptedKey field of RecipientEncryp tedKeys (for key agreement) and PasswordRecipientInfo (for password-based key ma nagement).</li>
</ul> </ul>
<section anchor="AESWrap" title="AES Key Wrap"> <section anchor="AESWrap">
<t>The AES encryption algorithm is define <name>AES Key Wrap</name>
d in <xref target="NIST.FIPS.197">FIPS&nbsp;Pub&nbsp;197</xref> and the key wrap <t>The AES encryption algorithm is define
ping is defined in <xref target="RFC3394">RFC&nbsp;3394</xref>.</t> d in <xref target="NIST.FIPS.197">FIPS&nbsp;Pub&nbsp;197</xref>, and the key wra
pping is defined in <xref target="RFC3394"/>.</t>
<t keepWithNext="true">AES key encryption has the algorithm identifier:</t> <t keepWithNext="true">AES key encryption has the algorithm identifier:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 5 } nistAlgorithm(4) aes(1) 5 }
id-aes192-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes192-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 25 } nistAlgorithm(4) aes(1) 25 }
id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 45 } nistAlgorithm(4) aes(1) 45 }
]]></sourcecode> ]]></sourcecode>
<t>The underlying encryption functions fo <t>The underlying encryption functions fo
r the key wrap and content-encryption algorithms (as specified in Section 5) and r the key wrap and content-encryption algorithms (as specified in <xref target="
the key sizes for the two algorithms MUST be the same (e.g., AES-128 key wrap a Enc"/>) and the key sizes for the two algorithms <bcp14>MUST</bcp14> be the same
lgorithm with AES-128 content-encryption algorithm), see also <xref target="RFC8 (e.g., AES-128 key wrap algorithm with AES-128 content-encryption algorithm); s
551">RFC&nbsp;8551</xref>.</t> ee <xref target="RFC8551"/>.</t>
<t>Further conventions to be considered f <t>Further conventions to be considered f
or AES key wrap are specified in <xref target="RFC3394">RFC&nbsp;3394 Section 2. or AES key wrap are specified in <xref target="RFC3394" section="2.2" sectionFor
2</xref> and <xref target="RFC3565">RFC&nbsp;3565 Section 2.3.2</xref>.</t> mat="of" /> and <xref target="RFC3565" section="2.3.2" sectionFormat="of" />.</t
>
</section> </section>
</section> </section>
<section anchor="KeyDeriv" title="Key Derivation Algorith <section anchor="KeyDeriv">
ms"> <name>Key Derivation Algorithms</name>
<t>The key derivation algorithm is also referred <t>The key derivation algorithm is also referred
to as KM_KD_ALG in <xref target="AlgProfLWP"/> and in the <xref target="I-D.ietf to as KM_KD_ALG in <xref target="AlgProfLWP"/> and the <xref target="RFC9483">Li
-lamps-lightweight-cmp-profile">Lightweight CMP Profile</xref>.</t> ghtweight CMP Profile</xref>.</t>
<t>Key derivation algorithms are only used in CMP <t>Key derivation algorithms are only used in CMP
when using <xref target="RFC5652">CMS</xref> EnvelopedData together with passwo when using <xref target="RFC5652">CMS EnvelopedData</xref> together with the pa
rd-based key management technique.</t> ssword-based key management technique.</t>
<t keepWithNext="true">Key derivation algorithm i <t keepWithNext="true">Key derivation algorithm i
dentifiers are located in:</t> dentifiers are located in the:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>keyDerivationAlgorithm field of Passw ordRecipientInfo</li> <li>keyDerivationAlgorithm field of Passw ordRecipientInfo.</li>
</ul> </ul>
<t>When using the password-based key management t <t>When using the password-based key management t
echnique with EnvelopedData as specified in CMP Updates together with message au echnique with EnvelopedData as specified in <xref target="RFC9480">CMP Updates</
thentication code (MAC)-based PKIProtection, the salt for the password-based MAC xref> together with PKIProtection based on the message authentication code (MAC)
and KDF must be chosen independently to ensure usage of independent symmetric k , the salt for the password-based MAC and key derivation function (KDF) must be
eys.</t> chosen independently to ensure usage of independent symmetric keys.</t>
<section anchor="PBKDF2" title="PBKDF2"> <section anchor="PBKDF2">
<t>The password-based key derivation func <name>PBKDF2</name>
tion 2 (PBKDF2) is defined in <xref target="RFC8018">RFC&nbsp;8018</xref>.</t> <t>Password-based key derivation function
<t keepWithNext="true">Password-based key 2 (PBKDF2) is defined in <xref target="RFC8018"/>.</t>
derivation function 2 has the algorithm identifier:</t> <t keepWithNext="true">PBKDF2 has the alg
orithm identifier:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-5(5) 12 } rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
]]></sourcecode> ]]></sourcecode>
<t>Further conventions to be considered f or PBKDF2 are specified in <xref target="RFC3370">RFC&nbsp;3370 Section 4.4.1</x ref> and <xref target="RFC8018">RFC&nbsp;8018 Section 5.2</xref>.</t> <t>Further conventions to be considered f or PBKDF2 are specified in <xref target="RFC3370" section="4.4.1" sectionFormat= "of" /> and <xref target="RFC8018" section="5.2" sectionFormat="of" />.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Enc" title="Content Encryption Algorithms "> <section anchor="Enc">
<t>The content encryption algorithm is also referred to a <name>Content-Encryption Algorithms</name>
s PROT_SYM_ALG in <xref target="AlgProf"/>, <xref target="RFC4210">RFC&nbsp;4210 <t>The content-encryption algorithm is also referred to as PROT
Appendix D and E</xref>, and the <xref target="I-D.ietf-lamps-lightweight-cmp-p _SYM_ALG in Appendices <xref target="RFC4210" sectionFormat="bare" section="D"/>
rofile">Lightweight CMP Profile</xref>.</t> and <xref target="RFC4210" sectionFormat="bare" section="E"/> of <xref target="
<t>Content encryption algorithms are only used in CMP whe RFC4210"/>, in the <xref target="RFC9483">Lightweight CMP Profile</xref>, and in
n using CMS [RFC5652] EnvelopedData to transport a signed private key package in <xref target="AlgProf"/>.</t>
case of central key generation or key archiving, a certificate to facilitate im <t>Content-encryption algorithms are used in CMP when usi
plicit proof-of-possession, or a revocation passphrase in encrypted form.</t> ng <xref target="RFC5652">CMS EnvelopedData</xref> to transport a signed private
<t keepWithNext="true">Content encryption algorithm ident key package in case of central key generation or key archiving, a certificate t
ifiers are located in:</t> o facilitate implicit proof-of-possession, or a revocation passphrase in encrypt
ed form.</t>
<t keepWithNext="true">Content-encryption algorithm ident
ifiers are located in the:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>contentEncryptionAlgorithm field of Encrypted ContentInfo</li> <li>contentEncryptionAlgorithm field of Encrypted ContentInfo.</li>
</ul> </ul>
<t keepWithNext="true">Encrypted content is located in:</ t> <t keepWithNext="true">Encrypted content is located in th e:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>encryptedContent field of EncryptedContentInf o</li> <li>encryptedContent field of EncryptedContentInf o.</li>
</ul> </ul>
<section anchor="AESEnc" title="AES-CBC"> <section anchor="AESEnc">
<name>AES-CBC</name>
<t>The AES encryption algorithm is defined in <xr ef target="NIST.FIPS.197">FIPS&nbsp;Pub&nbsp;197</xref>.</t> <t>The AES encryption algorithm is defined in <xr ef target="NIST.FIPS.197">FIPS&nbsp;Pub&nbsp;197</xref>.</t>
<t keepWithNext="true">AES-CBC content encryption has the algorithm identifier:</t> <t keepWithNext="true">AES Cipher Block Chaining (AES-CBC) content encryption has the algorithm identifier:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 2 } nistAlgorithm(4) aes(1) 2 }
id-aes192-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes192-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1)22 } nistAlgorithm(4) aes(1)22 }
id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1)42 } nistAlgorithm(4) aes(1)42 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered for AES- CBC content encryption are specified in <xref target="RFC3565">RFC&nbsp;3565</xr ef>.</t> <t>Specific conventions to be considered for AES- CBC content encryption are specified in <xref target="RFC3565"/>.</t>
</section> </section>
</section> </section>
<section anchor="MAC" title="Message Authentication Code Algorith <section anchor="MAC">
ms"> <name>Message Authentication Code Algorithms</name>
<t>The message authentication code (MAC) is either used f or shared secret-based CMP message protection or together with the password-base d key derivation function (PBKDF2).</t> <t>The message authentication code (MAC) is either used f or shared secret-based CMP message protection or together with the password-base d key derivation function (PBKDF2).</t>
<t>The message authentication code algorithm is also refe <t>The MAC algorithm is also referred to as MSG_MAC_ALG i
rred to as MSG_MAC_ALG in <xref target="AlgProf"/>, <xref target="RFC4210">RFC&n n <xref target="AlgProf"/>, Appendices <xref target="RFC4210" sectionFormat="bar
bsp;4210 Appendix D and E</xref>, and the <xref target="I-D.ietf-lamps-lightweig e" section="D"/> and <xref target="RFC4210" sectionFormat="bare" section="E"/> o
ht-cmp-profile">Lightweight CMP Profile</xref>.</t> f <xref target="RFC4210"/>, and the <xref target="RFC9483">Lightweight CMP Profi
<section anchor="PBMac" title="Password-Based MAC"> le</xref>.</t>
<t>Password-based message authentication code (MA <section anchor="PBMac">
C) algorithms combine the derivation of a symmetric key from a password or other <name>Password-Based MAC</name>
shared secret information and a symmetric key-based MAC function as specified i <t>Password-based message authentication code (MA
n Section 6.2 using this derived key.</t> C) algorithms combine the derivation of a symmetric key from a password or other
<t keepWithNext="true">Message authentication cod shared secret information and a symmetric key-based MAC function, as specified
e algorithm identifiers are located in:</t> in <xref target="SKMac"/>, using this derived key.</t>
<t keepWithNext="true">MAC algorithm identifiers
are located in the:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>protectionAlg field of PKIHeader</li> <li>protectionAlg field of PKIHeader.</li >
</ul> </ul>
<t keepWithNext="true">Message authentication cod e values are located in:</t> <t keepWithNext="true">Message authentication cod e values are located in the:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>PKIProtection field of PKIMessage</li > <li>PKIProtection field of PKIMessage.</l i>
</ul> </ul>
<section anchor="P-BMac" title="PasswordBasedMac" <section anchor="P-BMac">
> <name>PasswordBasedMac</name>
<t>The PasswordBasedMac algorithm is defi <t>The PasswordBasedMac algorithm is defi
ned in <xref target="RFC4210">RFC&nbsp;4210 Section 5.1.3.1</xref>, <xref target ned in <xref target="RFC4210" section="5.1.3.1" sectionFormat="of" />, <xref tar
="RFC4211">RFC&nbsp;4211 Section 4.4</xref>, and <xref target="RFC9045">Algorith get="RFC4211" section="4.4" sectionFormat="of" />, and <xref target="RFC9045">"A
m Requirements Update to the Internet X.509 Public Key Infrastructure Certificat lgorithm Requirements Update to the Internet X.509 Public Key Infrastructure Cer
e Request Message Format (CRMF)</xref>.</t> tificate Request Message Format (CRMF)"</xref>.</t>
<t keepWithNext="true">The PasswordBasedM ac algorithm is identified by the following OID:</t> <t keepWithNext="true">The PasswordBasedM ac algorithm is identified by the following OID:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) nt(113533) nsn(7) algorithms(66) 13 } us(840) nt(113533) nsn(7) algorithms(66) 13 }
]]></sourcecode> ]]></sourcecode>
<t>Further conventions to be considered f or password-based MAC are specified in <xref target="RFC4210">RFC&nbsp;4210 Sect ion 5.1.3.1</xref>, <xref target="RFC4211">RFC&nbsp;4211 Section 4.4</xref>, and <xref target="RFC9045">Algorithm Requirements Update to the Internet X.509 Publ ic Key Infrastructure Certificate Request Message Format (CRMF)</xref>.</t> <t>Further conventions to be considered f or PasswordBasedMac are specified in <xref target="RFC4210" section="5.1.3.1" s ectionFormat="of" />, <xref target="RFC4211" section="4.4" sectionFormat="of" /> , and <xref target="RFC9045">"Algorithm Requirements Update to the Internet X.50 9 Public Key Infrastructure Certificate Request Message Format (CRMF)"</xref>.</ t>
</section> </section>
<section anchor="PBMAC1" title="PBMAC1"> <section anchor="PBMAC1">
<t>The Password-Based Message Authenticat <name>PBMAC1</name>
ion Code 1 (PBMAC1) is defined in <xref target="RFC8018">RFC&nbsp;8018</xref>. P <t>Password-Based Message Authentication
BMAC1 combines a password-based key derivation function like PBKDF2 (<xref targe Code 1 (PBMAC1) is defined in <xref target="RFC8018"/>. PBMAC1 combines a passwo
t="PBKDF2"/>) with an underlying symmetric key-based message authentication sche rd-based key derivation function, like PBKDF2 (<xref target="PBKDF2"/>), with an
me.</t> underlying symmetric key-based message authentication scheme.</t>
<t keepWithNext="true">PBMAC1 has the fol lowing OID:</t> <t keepWithNext="true">PBMAC1 has the fol lowing OID:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-5(5) 14 } rsadsi(113549) pkcs(1) pkcs-5(5) 14 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered for PBMAC1 are specified in <xref target="RFC8018">RFC&nbsp;8018 Section 7.1 and A.5</xref>.</t> <t>Specific conventions to be considered for PBMAC1 are specified in Section <xref target="RFC8018" section="7.1" section Format="bare"/> and Appendix <xref target="RFC8018" section="A.5" sectionFormat= "bare"/> of <xref target="RFC8018"/>.</t>
</section> </section>
</section> </section>
<section anchor="SKMac" title="Symmetric Key-Based MAC"> <section anchor="SKMac">
<t>Symmetric key-based message authentication cod <name>Symmetric Key-Based MAC</name>
e (MAC) algorithms are used for deriving the symmetric encryption key when using <t>Symmetric key-based message authentication cod
PBKDF2 as described in <xref target="PBKDF2"/> as well as with Password-based M e (MAC) algorithms are used for deriving the symmetric encryption key when using
AC as described in <xref target="PBMac"/>.</t> PBKDF2, as described in <xref target="PBKDF2"/>, as well as with password-based
<t keepWithNext="true">Message authentication cod MAC, as described in <xref target="PBMac"/>.</t>
e algorithm identifiers are located in:</t> <t keepWithNext="true">MAC algorithm identifiers
are located in the:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>protectionAlg field of PKIHeader</li> <li>protectionAlg field of PKIHeader,</li
<li>messageAuthScheme field of PBMAC1</li >
> <li>messageAuthScheme field of PBMAC1,</l
<li>mac field of PBMParameter</li> i>
<li>prf field of PBKDF2-params</li> <li>mac field of PBMParameter, and</li>
<li>prf field of PBKDF2-params.</li>
</ul> </ul>
<t keepWithNext="true">Message authentication cod e values are located in:</t> <t keepWithNext="true">MAC values are located in the:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>PKIProtection field of PKIMessage</li > <li>PKIProtection field of PKIMessage.</l i>
</ul> </ul>
<section anchor="HMAC-SHA2" title="SHA2-Based HMA <section anchor="HMAC-SHA2">
C"> <name>SHA2-Based HMAC</name>
<t>The HMAC algorithm is defined in <xref <t>The HMAC algorithm is defined in <xref
target="RFC2104">RFC&nbsp;2104</xref> and <xref target="NIST.FIPS.198-1">FIPS&n target="RFC2104"/> and <xref target="NIST.FIPS.198-1">FIPS&nbsp;Pub&nbsp;198-1<
bsp;Pub&nbsp;198-1</xref>.</t> /xref>.</t>
<t keepWithNext="true">The HMAC algorithm used with SHA2 message digest algorithms is identified by the following OIDs:</ t> <t keepWithNext="true">The HMAC algorithm used with SHA2 message digest algorithms is identified by the following OIDs:</ t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) digestAlgorithm(2) 8 } us(840) rsadsi(113549) digestAlgorithm(2) 8 }
id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) digestAlgorithm(2) 9 } us(840) rsadsi(113549) digestAlgorithm(2) 9 }
id-hmacWithSHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-hmacWithSHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) digestAlgorithm(2) 10 } us(840) rsadsi(113549) digestAlgorithm(2) 10 }
id-hmacWithSHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-hmacWithSHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) digestAlgorithm(2) 11 } us(840) rsadsi(113549) digestAlgorithm(2) 11 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered for SHA2-based HMAC are specified in <xref target="RFC4231">RFC&nbsp;4231 Sectio n 3.1</xref>.</t> <t>Specific conventions to be considered for SHA2-based HMAC are specified in <xref target="RFC4231" section="3.1" sectio nFormat="of"/>.</t>
</section> </section>
<section anchor="AES-GMAC" title="AES-GMAC"> <section anchor="AES-GMAC">
<t>The AES-GMAC algorithm is defined in < <name>AES-GMAC</name>
xref target="NIST.FIPS.197">FIPS&nbsp;Pub&nbsp;197</xref> and <xref target="NIST <t>The AES-GMAC algorithm is defined in <
.SP.800-38d">NIST&nbsp;SP&nbsp;800-38d</xref>.</t> xref target="NIST.FIPS.197">FIPS&nbsp;Pub&nbsp;197</xref> and <xref target="NIST
<t>Note: AES-GMAC MUST NOT be used twice _SP_800_38d">NIST&nbsp;SP&nbsp;800-38d</xref>.</t>
with the same parameter set, especially the same nonce. Therefore, it MUST NOT b <t>Note: The AES-GMAC <bcp14>MUST NOT</bc
e used together with PBKDF2. When using it with PBMAC1 it MUST be ensured that A p14> be used twice with the same parameter set, especially the same nonce. There
ES-GMAC is only used as message authentication scheme and not for the key deriva fore, it <bcp14>MUST NOT</bcp14> be used together with PBKDF2. When using it wit
tion function PBKDF2.</t> h PBMAC1, it <bcp14>MUST</bcp14> be ensured that the AES-GMAC is only used as a
message authentication scheme and not for the key derivation function PBKDF2.</t
>
<t keepWithNext="true">The AES-GMAC algor ithm is identified by the following OIDs:</t> <t keepWithNext="true">The AES-GMAC algor ithm is identified by the following OIDs:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 9 } nistAlgorithm(4) aes(1) 9 }
id-aes192-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes192-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 29 } nistAlgorithm(4) aes(1) 29 }
id-aes256-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes256-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 49 } nistAlgorithm(4) aes(1) 49 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered for AES-GMAC are specified in <xref target="RFC9044">RFC&nbsp;9044</xref>.</t> <t>Specific conventions to be considered for the AES-GMAC are specified in <xref target="RFC9044"/>.</t>
</section> </section>
<section anchor="SHAKE-KMAC" title="SHAKE-Based K <section anchor="SHAKE-KMAC">
MAC"> <name>SHAKE-Based KMAC</name>
<t>The KMAC algorithm is defined in <xref <t>The KMAC algorithm is defined in <xref
target="RFC8702">RFC&nbsp;8702</xref> and <xref target="NIST.SP.800-185">FIPS&n target="RFC8702"/> and <xref target="NIST_SP_800_185">FIPS&nbsp;SP&nbsp;800-185
bsp;SP&nbsp;800-185</xref>.</t> </xref>.</t>
<t keepWithNext="true">The SHAKE-based KM AC algorithm is identified by the following OIDs:</t> <t keepWithNext="true">The SHAKE-based KM AC algorithm is identified by the following OIDs:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-KMACWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) 2 19 } nistAlgorithm(4) hashAlgs(2) 19 }
id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-KMACWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) 2 20 } nistAlgorithm(4) hashAlgs(2) 20 }
]]></sourcecode> ]]></sourcecode>
<t>Specific conventions to be considered for KMAC with SHAKE are specified in <xref target="RFC8702">RFC&nbsp;8702 Sectio n 3.4</xref>.</t> <t>Specific conventions to be considered for KMAC with SHAKE are specified in <xref target="RFC8702" section="3.4" sectio nFormat="of" />.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="AlgProf" title="Algorithm Use Profiles"> <section anchor="AlgProf">
<name>Algorithm Use Profiles</name>
<t>This section provides profiles of algorithms and respe ctive conventions for different application use cases.</t> <t>This section provides profiles of algorithms and respe ctive conventions for different application use cases.</t>
<t>Recommendations like <xref target="NIST.SP.800-57pt1r5 <t>Recommendations like those described in Table 2 of <xr
">NIST SP&nbsp;800-57 Recommendation for Key Management Table 2</xref> and <xref ef target="NIST_SP_800_57pt1r5">NIST SP&nbsp;800-57 "Recommendation for Key Mana
target="ECRYPT.CSA.D5.4">ECRYPT Algorithms, Key Size and Protocols Report (2018 gement"</xref> and Section 4.6 of <xref target="ECRYPT.CSA.D5.4">ECRYPT "Algorit
) Section 4.6</xref> provide general information on current cryptographic algori hms, Key Size and Protocols Report (2018)"</xref> provide general information on
thms.</t> current cryptographic algorithms.</t>
<t keepWithNext="true">The overall cryptographic strength <t keepWithNext="true">The overall cryptographic strength
of a CMP deployment will depend on several factors, including:</t> of CMP implementations will depend on several factors, including:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Capabilities of the end entity: What kind of <li>capabilities of the end entity: What kind of
algorithms does the end entity support. The cryptographic strength of the system algorithms does the end entity support? The cryptographic strength of the system
SHOULD be at least as strong as the algorithms and keys used for the certificat <bcp14>SHOULD</bcp14> be at least as strong as the algorithms and keys used for
e being managed.</li> the certificate being managed.</li>
<li>Algorithm profile: The overall strength of th <li>algorithm profile: The overall strength of th
e profile will be the strength of the weakest algorithm it contains.</li> e profile will be the strength of the weakest algorithm it contains.</li>
<li> <li>
<t keepWithNext="true">Message protection : The overall strength of the CMC message protection</t> <t keepWithNext="true">message protection : The overall strength of the CMP message protection.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>MAC-based protection: The ent ropy of the shared secret information or password when MAC-based message protect ion is used (MSG_MAC_ALG).</li> <li>MAC-based protection: The ent ropy of the shared secret information or password when MAC-based message protect ion is used (MSG_MAC_ALG).</li>
<li>Signature-based protection: T <li>signature-based protection: T
he strength of the key pair and signature algorithm when signature-based protect he strength of the key pair and signature algorithm when signature-based protect
ion is used (MSG_SIG_ALG).</li> ion is used (MSG_SIG_ALG).</li>
<li>Protection of centrally gener <li>protection of centrally gener
ated keys: The strength of the algorithms used for the key management technique ated keys: The strength of the algorithms used for the key management technique
(<xref target="AlgProfLWP"/>: PROT_ENC_ALG or <xref target="AlgProf4210"/>: KM_K (<xref target="AlgProf4210"/>: PROT_ENC_ALG or <xref target="AlgProfLWP"/>: KM_K
A_ALG, KM_KT_ALG, KM_KD_ALG) and the encryption of the content-encryption key an A_ALG, KM_KT_ALG, KM_KD_ALG) and the encryption of the content-encryption key an
d private key (<xref target="AlgProfLWP"/>: SYM_PENC_ALG, PROT_SYM_ALG or <xref d private key (<xref target="AlgProf4210"/>: SYM_PENC_ALG, PROT_SYM_ALG or <xref
target="AlgProf4210"/>: KM_KW_ALG, PROT_SYM_ALG).</li> target="AlgProfLWP"/>: KM_KW_ALG, PROT_SYM_ALG).</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t keepWithNext="true">The following table shows the algo rithms listed in this document sorted by their bits of security. If an implement ation intends to enroll and manage certificate for keys of a specific security, it SHALL implement and use algorithms of at least that strength for the respecti ve PKI management operation. If one row does not provide a suitable algorithm, the implementer MUST choose one offering more bits of security.</t> <t keepWithNext="true">The following table shows the algo rithms listed in this document sorted by their bits of security. If an implement ation intends to enroll and manage certificates for keys of a specific security, it <bcp14>SHALL</bcp14> implement and use algorithms of at least that strength for the respective PKI management operation. If one row does not provide a suit able algorithm, the implementer <bcp14>MUST</bcp14> choose one offering more bit s of security.</t>
<table anchor="BalacedAlgSets" align="left"> <table anchor="BalacedAlgSets" align="left">
<name>Cryptographic Algorithms Sorted by their Bi ts of Security</name> <name>Cryptographic Algorithms Sorted by Their Bi ts of Security</name>
<thead> <thead>
<tr> <tr>
<th align='left'>Bits of Secu-<br />rity</th> <th align='left'>Bits of Security </th>
<th align='left'>RSA or DH</th> <th align='left'>RSA or DH</th>
<th align='left'>Elliptic Curve</ th> <th align='left'>Elliptic Curve C ryptography</th>
<th align='left'>Hash Function or XOF with Specified Output Length (d)</th> <th align='left'>Hash Function or XOF with Specified Output Length (d)</th>
<th align='left'>Symmetric Encryp tion</th> <th align='left'>Symmetric Encryp tion</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">112</td> <td align="left">112</td>
<td align="left">RSA2048,<br/>DH( 2048)</td> <td align="left">RSA2048,<br/>DH( 2048)</td>
<td align="left">ECDSA/ECDH (secp 224r1)</td> <td align="left">ECDSA/ECDH (secp 224r1)</td>
<td align="left">SHA224</td> <td align="left">SHA-224</td>
<td align="left"></td> <td align="left"></td>
</tr> </tr>
<tr> <tr>
<td align="left">128</td> <td align="left">128</td>
<td align="left">RSA3072,<br/>DH( 3072)</td> <td align="left">RSA3072,<br/>DH( 3072)</td>
<td align="left">ECDSA/ECDH (secp <td align="left">ECDSA/ECDH (secp
256r1),<br/>Ed25519/X25519 (Curve25519)</td> 256r1),<br/>Ed25519/X25519 (curve25519)</td>
<td align="left">SHA256,<br/>SHAK <td align="left">SHA-256,<br/>SHA
E128(d=256)</td> KE128(d=256)</td>
<td align="left">AES-128</td> <td align="left">AES-128</td>
</tr> </tr>
<tr> <tr>
<td align="left">192</td> <td align="left">192</td>
<td align="left"></td> <td align="left"></td>
<td align="left">ECDSA/ECDH (secp 384r1)</td> <td align="left">ECDSA/ECDH (secp 384r1)</td>
<td align="left">SHA384</td> <td align="left">SHA-384</td>
<td align="left">AES-192</td> <td align="left">AES-192</td>
</tr> </tr>
<tr> <tr>
<td align="left">224</td> <td align="left">224</td>
<td align="left"></td> <td align="left"></td>
<td align="left">Ed448/X448 (Curv e448)</td> <td align="left">Ed448/X448 (curv e448)</td>
<td align="left"></td> <td align="left"></td>
<td align="left"></td> <td align="left"></td>
</tr> </tr>
<tr> <tr>
<td align="left">256</td> <td align="left">256</td>
<td align="left"></td> <td align="left"></td>
<td align="left">ECDSA/ECDH (secp 521r1)</td> <td align="left">ECDSA/ECDH (secp 521r1)</td>
<td align="left">SHA512,<br/>SHAK E256(d=512)</td> <td align="left">SHA-512,<br/>SHA KE256(d=512)</td>
<td align="left">AES-256</td> <td align="left">AES-256</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The following table shows the cryptographic algorithms sorted by their usage in CMP and with more details.</t> <t>The following table shows the cryptographic algorithms sorted by their usage in CMP and with more details.</t>
<table anchor="BalacedAlgSetsCMP" align="left"> <table anchor="BalacedAlgSetsCMP" align="left">
<name>Cryptographic Algorithms Sorted by their Bi ts of Security and Usage by CMP</name> <name>Cryptographic Algorithms Sorted by Their Bi ts of Security and Usage by CMP</name>
<thead> <thead>
<tr> <tr>
<th align='left'>Bits of<br/>Secu rity</th> <th align='left'>Bits of Security </th>
<th align='left'>Key Types to Be Certified</th> <th align='left'>Key Types to Be Certified</th>
<th align='left'>CMP Protection</ <th align='left'>CMP Protection<b
th> r/>MSG_SIG_ALG, MSG_MAC_ALG</th>
<th align='left'>Key Management T <th align='left'>Key Management T
echnique</th> echnique<br/>PROT_ENC_ALG or KM_KA_ALG, KM_KT_ALG, KM_KD_ALG</th>
<th align='left'>Key-Wrap and Sym <th align='left'>Key-Wrap and Sym
metric Encryption</th> metric Encryption<br/>PROT_SYM_ALG,<br/>SYM_PENC_ALG<br/>or<br/>KM_KW_ALG</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"></td>
<td align="left"></td>
<td align="left">MSG_SIG_ALG, MSG
_MAC_ALG</td>
<td align="left">PROT_ENC_ALG or
KM_KA_ALG, KM_KT_ALG, KM_KD_ALG</td>
<td align="left">PROT_SYM_ALG,<br
/>SYM_PENC_ALG<br/>or<br/>KM_KW_ALG</td>
</tr>
<tr>
<td align="left">112</td> <td align="left">112</td>
<td align="left">RSA2048,<br/>sec p224r1</td> <td align="left">RSA2048,<br/>sec p224r1</td>
<td align="left">RSASSA-PSS (2048 <td align="left">RSASSA-PSS (2048
, SHA224 or SHAKE128 (d=256)),<br/>RSAEncryption (2048, SHA224),<br/>ECDSA (secp , SHA-224 or SHAKE128 (d=256)),<br/>RSAEncryption (2048, SHA-224),<br/>ECDSA (se
224r1, SHA224 or SHAKE128 (d=256)),<br/>PBMAC1 (HMAC-SHA224)</td> cp224r1, SHA-224 or SHAKE128 (d=256)),<br/>PBMAC1 (HMAC-SHA-224)</td>
<td align="left">DH(2048),<br/>RS <td align="left">DH(2048),<br/>RS
AES-OAEP (2048, SHA224),<br/>RSAEncryption (2048, SHA224),<br/>ECDH (secp224r1, AES-OAEP (2048, SHA-224),<br/>RSAEncryption (2048, SHA-224),<br/>ECDH (secp224r1
SHA224),<br/>PBKDF2 (HMAC-SHA224)</td> , SHA-224),<br/>PBKDF2 (HMAC-SHA-224)</td>
<td align="left"></td> <td align="left"></td>
</tr> </tr>
<tr> <tr>
<td align="left">128</td> <td align="left">128</td>
<td align="left">RSA3072,<br/>sec <td align="left">RSA3072,<br/>sec
p256r1,<br/>Curve25519</td> p256r1,<br/>curve25519</td>
<td align="left">RSASSA-PSS (3072 <td align="left">RSASSA-PSS (3072
, SHA256 or SHAKE128 (d=256)),<br/>RSAEncryption (3072, SHA256),<br/>ECDSA (secp , SHA-256 or SHAKE128 (d=256)),<br/>RSAEncryption (3072, SHA-256),<br/>ECDSA (se
256r1, SHA256 or SHAKE128 (d=256)),<br/>Ed25519 (SHA512),<br/>PBMAC1 (HMAC-SHA25 cp256r1, SHA-256 or SHAKE128 (d=256)),<br/>Ed25519 (SHA-512),<br/>PBMAC1 (HMAC-S
6)</td> HA-256)</td>
<td align="left">DH(3072),<br/>RS <td align="left">DH(3072),<br/>RS
AES-OAEP (3072, SHA256),<br/> RSAEncryption (3072, SHA256),<br/>ECDH (secp256r1, AES-OAEP (3072, SHA-256),<br/> RSAEncryption (3072, SHA-256),<br/>ECDH (secp256r
SHA256),<br/>X25519,<br/>PBKDF2 (HMAC-SHA256)</td> 1, SHA-256),<br/>X25519,<br/>PBKDF2 (HMAC-SHA-256)</td>
<td align="left">AES-128</td> <td align="left">AES-128</td>
</tr> </tr>
<tr> <tr>
<td align="left">192</td> <td align="left">192</td>
<td align="left">secp384r1</td> <td align="left">secp384r1</td>
<td align="left">ECDSA (secp384r1 <td align="left">ECDSA (secp384r1
, SHA384),<br/>PBMAC1 (HMAC-SHA384)</td> , SHA-384),<br/>PBMAC1 (HMAC-SHA-384)</td>
<td align="left">ECDH (secp384r1, <td align="left">ECDH (secp384r1,
SHA384),<br/>PBKDF2 (HMAC-SHA384)</td> SHA-384),<br/>PBKDF2 (HMAC-SHA-384)</td>
<td align="left">AES-192</td> <td align="left">AES-192</td>
</tr> </tr>
<tr> <tr>
<td align="left">224</td> <td align="left">224</td>
<td align="left">Curve448</td> <td align="left">curve448</td>
<td align="left">Ed448 (SHAKE256) </td> <td align="left">Ed448 (SHAKE256) </td>
<td align="left">X448</td> <td align="left">X448</td>
<td align="left"></td> <td align="left"></td>
</tr> </tr>
<tr> <tr>
<td align="left">256</td> <td align="left">256</td>
<td align="left">secp521r1</td> <td align="left">secp521r1</td>
<td align="left">ECDSA (secp521r1 <td align="left">ECDSA (secp521r1
, SHA512 or SHAKE256 (d=512)),<br/>PBMAC1 (HMAC-SHA512)</td> , SHA-512 or SHAKE256 (d=512)),<br/>PBMAC1 (HMAC-SHA-512)</td>
<td align="left">ECDH (secp521r1, <td align="left">ECDH (secp521r1,
SHA512),<br/>PBKDF2 (HMAC-SHA512)</td> SHA-512),<br/>PBKDF2 (HMAC-SHA-512)</td>
<td align="left">AES-256</td> <td align="left">AES-256</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>To avoid consuming too many computational resources it <t>To avoid consuming too many computational resources, c
is recommended to choose a set of algorithms offering roughly the same level of hoosing a set of algorithms offering roughly the same level of security is recom
security. Below are provided several algorithm profiles which are balanced, ass mended. Below are several algorithm profiles that are balanced, assuming the imp
uming the implementer chooses MAC secrets and/or certificate profiles of at leas lementer chooses MAC secrets and/or certificate profiles of at least equivalent
t equivalent strength.</t> strength.</t>
<section anchor="AlgProf4210" title="Algorithm Profile fo <section anchor="AlgProf4210">
r RFC 4210 PKI Management Message Profiles"> <name>Algorithm Profile for PKI Management Message Profiles in RFC 4210</name>
<t>The following table updates the definitions of
algorithms used within PKI Management Message Profiles as defined in <xref targ <t>The following table updates the definitions of
et="RFC4210">CMP Appendix D.2</xref>.</t> algorithms used within PKI Management Message Profiles, as defined in <xref tar
get="RFC4210" sectionFormat="of" section="D.2"/>.</t>
<t>The columns in the table are:</t> <t>The columns in the table are:</t>
<t>Name: An identifier used for message profiles< <dl newline="false" spacing="normal">
/t> <dt>Name:</dt> <dd>An identifier used for message
<t>Use: Description of where and for what the alg profiles</dd>
orithm is used</t> <dt>Use:</dt> <dd>Description of where and for wh
<t>Mandatory: Algorithms which MUST be supported at the algorithm is used</dd>
by conforming implementations</t> <dt>Mandatory:</dt> <dd>Algorithms that <bcp14>MU
<t>Optional: Algorithms which are OPTIONAL to sup ST</bcp14> be supported by conforming implementations</dd>
port</t> <dt>Optional:</dt> <dd>Algorithms that are <bcp14
<t>Deprecated: Algorithms from <xref target="RFC4 >OPTIONAL</bcp14> to support</dd>
210">RFC&nbsp;4210</xref> which SHOULD NOT be used any more</t> <dt>Deprecated:</dt> <dd>Algorithms from <xref ta
rget="RFC4210"/> that <bcp14>SHOULD NOT</bcp14> be used any more</dd>
</dl>
<table anchor="AlgProd4210T"> <table anchor="AlgProd4210T">
<name>Algorithms Used Within RFC 4210 App endix D.2</name> <name>Algorithms Used within Appendix D.2 of RFC 4210</name>
<thead> <thead>
<tr> <tr>
<th align='left'>Name</th > <th align='left'>Name</th >
<th align='left'>Use</th> <th align='left'>Use</th>
<th align='left'>Manda-<b r/>tory</th> <th align='left'>Mandator y</th>
<th align='left'>Optional </th> <th align='left'>Optional </th>
<th align='left'>Deprecat ed</th> <th align='left'>Deprecat ed</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">MSG_SIG_ ALG</td> <td align="left">MSG_SIG_ ALG</td>
<td align="left">protecti on of PKI messages using signature</td> <td align="left">protecti on of PKI messages using signatures</td>
<td align="left">RSA</td> <td align="left">RSA</td>
<td align="left">ECDSA, E dDSA</td> <td align="left">ECDSA, E dDSA</td>
<td align="left">DSA, com binations with MD5 and SHA-1</td> <td align="left">DSA, com binations with MD5 and SHA-1</td>
</tr> </tr>
<tr> <tr>
<td align="left">MSG_MAC_ ALG</td> <td align="left">MSG_MAC_ ALG</td>
<td align="left">protecti on of PKI messages using MACing</td> <td align="left">protecti on of PKI messages using MACs</td>
<td align="left">PBMAC1</ td> <td align="left">PBMAC1</ td>
<td align="left">Password BasedMac, HMAC, KMAC</td> <td align="left">Password BasedMac, HMAC, KMAC</td>
<td align="left">X9.9</td > <td align="left">X9.9</td >
</tr> </tr>
<tr> <tr>
<td align="left">SYM_PENC _ALG</td> <td align="left">SYM_PENC _ALG</td>
<td align="left">symmetri c encryption of an end entity's private key where symmetric key is distributed o ut-of-band</td> <td align="left">symmetri c encryption of an end entity's private key where the symmetric key is distribut ed out of band</td>
<td align="left">AES-wrap </td> <td align="left">AES-wrap </td>
<td align="left"></td> <td align="left"></td>
<td align="left">3-DES(3- key-EDE, CBC Mode), RC5, CAST-128</td> <td align="left">3-DES(3- key-EDE, CBC Mode), RC5, CAST-128</td>
</tr> </tr>
<tr> <tr>
<td align="left">PROT_ENC _ALG</td> <td align="left">PROT_ENC _ALG</td>
<td align="left">asymmetr ic algorithm used for encryption of (symmetric keys for encryption of) private k eys transported in PKIMessages</td> <td align="left">asymmetr ic algorithm used for encryption of (symmetric keys for encryption of) private k eys transported in PKIMessages</td>
<td align="left">DH</td> <td align="left">DH</td>
<td align="left">ECDH, RS A</td> <td align="left">ECDH, RS A</td>
<td align="left"></td> <td align="left"></td>
</tr> </tr>
<tr> <tr>
<td align="left">PROT_SYM _ALG</td> <td align="left">PROT_SYM _ALG</td>
<td align="left">symmetri c encryption algorithm used for encryption of private key bits (a key of this ty pe is encrypted using PROT_ENC_ALG)</td> <td align="left">symmetri c encryption algorithm used for encryption of private key bits (a key of this ty pe is encrypted using PROT_ENC_ALG)</td>
<td align="left">AES-CBC< /td> <td align="left">AES-CBC< /td>
<td align="left"></td> <td align="left"></td>
<td align="left">3-DES(3- key-EDE, CBC Mode), RC5, CAST-128</td> <td align="left">3-DES(3- key-EDE, CBC Mode), RC5, CAST-128</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t keepWithNext="true">Mandatory Algorithm Identi <t keepWithNext="true">The following are the mand
fiers and Specifications:</t> atory algorithm identifiers and specifications:</t>
<t>RSA: sha256WithRSAEncryption with 2048 bit, se <dl newline="false" spacing="normal">
e <xref target="RSASig"/></t> <dt>RSA:</dt> <dd>sha256WithRSAEncryption with 20
<t>PasswordBasedMac: id-PasswordBasedMac, see <xr 48 bit, see <xref target="RSASig"/></dd>
ef target="PBMac"/> (with id-sha256 as the owf parameter, see <xref target="SHA2 <dt>PasswordBasedMac:</dt> <dd>id-PasswordBasedMa
"/> and id-hmacWithSHA256 as the mac parameter, see <xref target="HMAC-SHA2"/>)< c, see <xref target="PBMac"/> (with id-sha256 as the owf parameter, see <xref ta
/t> rget="SHA2"/> and id-hmacWithSHA256 as the mac parameter, see <xref target="HMAC
<t>PBMAC1: id-PBMAC1, see <xref target="PBMAC1"/> -SHA2"/>)</dd>
(with id-PBKDF2 as the key derivation function, see <xref target="PBKDF2"/> and <dt>PBMAC1:</dt> <dd>id-PBMAC1, see <xref target=
id-hmacWithSHA256 as message authentication scheme, see <xref target="HMAC-SHA2 "PBMAC1"/> (with id-PBKDF2 as the key derivation function, see <xref target="PBK
"/>). It is RECOMMENDED to prefer the usage of PBMAC1 instead of PasswordBasedMa DF2"/> and id-hmacWithSHA256 as the message authentication scheme, see <xref tar
c.</t> get="HMAC-SHA2"/>). It is <bcp14>RECOMMENDED</bcp14> to prefer the usage of PBMA
<t>DH: id-alg-ESDH, see <xref target="DH"/></t> C1 instead of PasswordBasedMac.</dd>
<t>AES-wrap: id-aes128-wrap, see <xref target="AE <dt>DH:</dt> <dd>id-alg-ESDH, see <xref target="D
SWrap"/></t> H"/></dd>
<t>AES-CBC: id-aes128-CBC, see <xref target="AESE <dt>AES-wrap:</dt> <dd>id-aes128-wrap, see <xref
nc"/></t> target="AESWrap"/></dd>
<dt>AES-CBC:</dt> <dd>id-aes128-CBC, see <xref ta
rget="AESEnc"/></dd>
</dl>
</section> </section>
<section anchor="AlgProfLWP" title="Algorithm Profile for <section anchor="AlgProfLWP">
Lightweight CMP Profile"> <name>Algorithm Profile for Lightweight CMP Profile</name>
<t>The following table contains definitions of al <t>The following table contains definitions of al
gorithms which MAY be supported by implementations of the <xref target="I-D.ietf gorithms that <bcp14>MAY</bcp14> be supported by implementations of the <xref ta
-lamps-lightweight-cmp-profile">Lightweight CMP Profile</xref>.</t> rget="RFC9483">Lightweight CMP Profile</xref>.</t>
<t>As the set of algorithms to be used for implem <t>As the set of algorithms to be used for implem
entations of the Lightweight CMP Profile heavily depends on the PKI management o entations of the Lightweight CMP Profile heavily depends on the PKI management o
perations implemented, the certificates used for messages protection, and the ce perations implemented, the certificates used for message protection, and the cer
rtificates to be managed, this document will not specify a specific set that is tificates to be managed, this document will not specify a specific set that is m
mandatory to support for conforming implementations.</t> andatory to support for conforming implementations.</t>
<t>The columns in the table are:</t> <t>The columns in the table are:</t>
<t>Name: An identifier used for message profiles< <dl newline="false" spacing="normal">
/t> <dt>Name:</dt> <dd>An identifier used for message
<t>Use: Description of where and for what the alg profiles</dd>
orithm is used</t> <dt>Use:</dt> <dd>Description of where and for wh
<t>Examples: Lists the algorithms as described in at the algorithm is used</dd>
this document. The list of algorithms depends on the set of PKI management oper <dt>Examples:</dt> <dd>Lists the algorithms, as d
ations to be implemented.</t> escribed in this document. The list of algorithms depends on the set of PKI mana
<t>Note: It is RECOMMENDED to prefer the usage of gement operations to be implemented.</dd>
PBMAC1 instead of PasswordBasedMac.</t> </dl>
<t>Note: It is <bcp14>RECOMMENDED</bcp14> to pref
er the usage of PBMAC1 instead of PasswordBasedMac.</t>
<table anchor="AlgProfLWPT"> <table anchor="AlgProfLWPT">
<name>Algorithms Used Within Lightweight CMP Profile</name> <name>Algorithms Used within the Lightwei ght CMP Profile</name>
<thead> <thead>
<tr> <tr>
<th align='left'>Name</th > <th align='left'>Name</th >
<th align='left'>Use</th> <th align='left'>Use</th>
<th align='left'>Examples </th> <th align='left'>Examples </th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">MSG_SIG_ ALG</td> <td align="left">MSG_SIG_ ALG</td>
<td align="left">protecti on of PKI messages using signature and for SignedData, e.g., a private key trans ported in PKIMessages</td> <td align="left">protecti on of PKI messages using signatures and for SignedData, e.g., a private key tran sported in PKIMessages</td>
<td align="left">RSA, ECD SA, EdDSA</td> <td align="left">RSA, ECD SA, EdDSA</td>
</tr> </tr>
<tr> <tr>
<td align="left">MSG_MAC_ ALG</td> <td align="left">MSG_MAC_ ALG</td>
<td align="left">protecti on of PKI messages using MACing</td> <td align="left">protecti on of PKI messages using MACing</td>
<td align="left">Password BasedMac (see <xref target="Security"/>), PBMAC1, HMAC, KMAC</td> <td align="left">Password BasedMac (see <xref target="Security"/>), PBMAC1, HMAC, KMAC</td>
</tr> </tr>
<tr> <tr>
<td align="left">KM_KA_AL G</td> <td align="left">KM_KA_AL G</td>
<td align="left">asymmetr ic key agreement algorithm used for agreement of a symmetric key for use with KM _KW_ALG</td> <td align="left">asymmetr ic key agreement algorithm used for agreement of a symmetric key for use with KM _KW_ALG</td>
<td align="left">DH, ECDH </td> <td align="left">DH, ECDH </td>
</tr> </tr>
<tr> <tr>
<td align="left">KM_KT_AL G</td> <td align="left">KM_KT_AL G</td>
<td align="left">asymmetr ic key encryption algorithm used for transport of a symmetric key for PROT_SYM_A LG</td> <td align="left">asymmetr ic key-encryption algorithm used for transport of a symmetric key for PROT_SYM_A LG</td>
<td align="left">RSA</td> <td align="left">RSA</td>
</tr> </tr>
<tr> <tr>
<td align="left">KM_KD_AL G</td> <td align="left">KM_KD_AL G</td>
<td align="left">symmetri c key derivation algorithm used for derivation of a symmetric key for use with K M_KW_ALG</td> <td align="left">symmetri c key derivation algorithm used for derivation of a symmetric key for use with K M_KW_ALG</td>
<td align="left">PBKDF2</ td> <td align="left">PBKDF2</ td>
</tr> </tr>
<tr> <tr>
<td align="left">KM_KW_AL G</td> <td align="left">KM_KW_AL G</td>
<td align="left">algorith m to wrap a symmetric key for PROT_SYM_ALG</td> <td align="left">algorith m to wrap a symmetric key for PROT_SYM_ALG</td>
<td align="left">AES-wrap </td> <td align="left">AES-wrap </td>
</tr> </tr>
<tr> <tr>
<td align="left">PROT_SYM _ALG</td> <td align="left">PROT_SYM _ALG</td>
<td align="left">symmetri c content encryption algorithm used for encryption of EnvelopedData, e.g., a pri vate key transported in PKIMessages</td> <td align="left">symmetri c content-encryption algorithm used for encryption of EnvelopedData, e.g., a pri vate key transported in PKIMessages</td>
<td align="left">AES-CBC< /td> <td align="left">AES-CBC< /td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANA">
<t>This document does not request changes to the IANA reg <name>IANA Considerations</name>
istry.</t> <t>This document has no IANA actions.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document lists many cryptographic algorithms usab
le with CMP to offer implementer a more up-to-date choice. Finally, the algorit
hms to be supported also heavily depend on the certificates and PKI management o
perations utilized in the target environment. The algorithm with the lowest secu
rity strength and the entropy of shared secret information define the security o
f the overall solution, see <xref target="AlgProf"/>.</t>
<t>When using MAC-based message protection the use of PBM
AC1 is preferable to that of PasswordBasedMac. First, PBMAC1 is a well-known scr
utinized algorithm, which is not true for PasswordBasedMac. Second, the Password
BasedMac algorithm as specified in <xref target="RFC4211">RFC&nbsp;4211 Section
4.4</xref> is essentially PBKDF1 (as defined in <xref target="RFC8018">RFC&nbsp;
8018 Section 5.1</xref>) with an HMAC step at the end. Here we update to use the
PBKDF2-HMAC construct defined as PBMAC1 in <xref target="RFC8018"/>. PBKDF2 is
superior to PBKDF1 in an improved internal construct for iterated hashing, and i
n removing PBKDF1’s limitation of only being able to derive keys up to the size
of the underlying hash function. Additionally, PBKDF1 is not recommended for new
applications as stated in <xref target="RFC8018">Section 5.1 of RFC&nbsp;8018</
xref> and no longer an approved algorithm by most standards bodies, and therefor
e presents difficulties to implementer who are submitting their CMP implementati
ons for certification, hence moving to a PBKDF2-based mechanism. This change is
in alignment with <xref target="RFC9045"/> which updates <xref target="RFC4211"/
> to allow the use of PBMAC1 in CRMF.</t>
<t>AES-GMAC MUST NOT be used as the pseudo random functio
n in PBKDF2; the use of AES-GMAC more than once with the same key and the same n
once will break the security.</t>
<t>In <xref target="AlgProf"/> of this document there is
also an update to the <xref target="RFC4210">Appendix D.2 of RFC&nbsp;4210</xref
> and a set of algorithms that MAY be supported when implementing the <xref targ
et="I-D.ietf-lamps-lightweight-cmp-profile">Lightweight CMP Profile</xref>.</t>
<t>It is recognized that there may be older CMP implement
ations in use that conform to the algorithm use profile from <xref target="RFC42
10">Appendix D.2 of RFC&nbsp;4210</xref>. For example, the use of AES is now man
datory for PROT_SYM_ALG but in <xref target="RFC4210">RFC&nbsp;4210</xref> 3-DES
was mandatory. Therefore, it is expected that many CMP systems may already supp
ort the recommended algorithms in this specification. In such systems the weaken
ed algorithms should be disabled from further use. If critical systems cannot be
immediately updated to conform to the recommended algorithm use profile, it is
recommended a plan to migrate the infrastructure to conforming profiles be adopt
ed as soon as possible.</t>
<t>Symmetric key-based MAC algorithms as described in <xr
ef target="SKMac"/> MAY be used as MSG_MAC_ALG. The implementer MUST choose a su
itable PRF and ensure that the key has sufficient entropy to match the overall s
ecurity level of the algorithm profile. These considerations are outside the sco
pe of the profile.</t>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements"> <section anchor="Security">
<t>Thanks to Russ Housley for supporting this draft with <name>Security Considerations</name>
submitting <xref target="RFC9044"/> and <xref target="RFC9045"/>.</t> <t>This document lists many cryptographic algorithms usab
<t>May thanks also to all reviewers like Serge Mister, Ma le with CMP to offer implementers a more up-to-date choice. Finally, the algori
rk Ferreira, Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steff thms to be supported also heavily depend on the certificates and PKI management
en Fries for their input and feedback to this document. Apologies to all not men operations utilized in the target environment. The algorithm with the lowest sec
tioned reviewers and supporters.</t> urity strength and the entropy of shared secret information defines the security
of the overall solution; see <xref target="AlgProf"/>.</t>
<t>When using MAC-based message protection, the use of PB
MAC1 is preferable to that of PasswordBasedMac. First, PBMAC1 is a well-known sc
rutinized algorithm, which is not true for PasswordBasedMac. Second, the Passwor
dBasedMac algorithm as specified in <xref target="RFC4211" section="4.4" section
Format="of"/> is essentially PBKDF1 (as defined in <xref target="RFC8018" sectio
n="5.1" sectionFormat="of"/>) with an HMAC step at the end. Here, we update to u
se the PBKDF2-HMAC construct defined as PBMAC1 in <xref target="RFC8018"/>. PBKD
F2 is superior to PBKDF1 in an improved internal construct for iterated hashing
and in removing PBKDF1's limitation of only being able to derive keys up to the
size of the underlying hash function. Additionally, PBKDF1 is not recommended fo
r new applications as stated in <xref target="RFC8018" section="5.1" sectionForm
at="of"/> and is no longer an approved algorithm by most standards bodies. There
fore, it presents difficulties to implementers who are submitting their CMP impl
ementations for certification, hence moving to a PBKDF2-based mechanism. This ch
ange is in alignment with <xref target="RFC9045"/>, which updates <xref target="
RFC4211"/> to allow the use of PBMAC1 in CRMF.</t>
<t>The AES-GMAC <bcp14>MUST NOT</bcp14> be used as the ps
eudorandom function (PRF) in PBKDF2; the use of the AES-GMAC more than once with
the same key and the same nonce will break the security.</t>
<t>In <xref target="AlgProf"/> of this document, there is
also an update to <xref target="RFC4210" sectionFormat="of" section="D.2"/> and
a set of algorithms that <bcp14>MAY</bcp14> be supported when implementing the
<xref target="RFC9483">Lightweight CMP Profile</xref>. It is recognized that th
ere may be older CMP implementations in use that conform to the algorithm use pr
ofile from <xref target="RFC4210" sectionFormat="of" section="D.2"/>. For exampl
e, the use of AES is now mandatory for PROT_SYM_ALG, while 3-DES was mandatory i
n <xref target="RFC4210"/>. Therefore, it is expected that many CMP systems may
already support the recommended algorithms in this specification. In such system
s, the weakened algorithms should be disabled from further use. If critical syst
ems cannot be immediately updated to conform to the recommended algorithm use pr
ofile, it is recommended that a plan to migrate the infrastructure to conforming
profiles be adopted as soon as possible.</t>
<t>Symmetric key-based MAC algorithms as described in <xr
ef target="SKMac"/> <bcp14>MAY</bcp14> be used as MSG_MAC_ALG. The implementer <
bcp14>MUST</bcp14> choose a suitable PRF and ensure that the key has sufficient
entropy to match the overall security level of the algorithm profile. These cons
iderations are outside the scope of the profile.</t>
</section> </section>
</middle> </middle>
<back> <back>
<!-- References split into informative and normative --> <displayreference target="NIST_FIPS_180_4" to="NIST.FIPS.180-4"/>
<!-- There are 2 ways to insert reference entries from the citati <displayreference target="NIST_FIPS_202" to="NIST.FIPS.202"/>
on libraries: <displayreference target="NIST_SP_800_38d" to="NIST.SP.800-38d"/>
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here ( <displayreference target="NIST_SP_800_57pt1r5" to="NIST.SP.800-57pt1r5"/>
as shown) <displayreference target="NIST_SP_800_185" to="NIST.SP.800-185]"/>
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. <references>
If you use the PI option, xml2rfc will, by default, try to find included fil <name>References</name>
es in the same <references>
directory as the including file. You can also define the XML_LIBRARY environ <name>Normative References</name>
ment variable <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
with a value containing a set of directories to search. These can be either />
in the local <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"
filing system or remote ones accessed by http (http://domain/dir/... ).--> />
<!-- <references title="Normative References"> --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2631.xml"
<references> />
<name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3370.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3394.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.2104.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3560.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.2631.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3565.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.3370.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4056.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.3394.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4210.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.3560.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4211.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.3565.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4231.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.4056.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.4210.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.4211.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5753.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.4231.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5754.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.5480.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.5652.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8018.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.5753.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.5754.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.8017.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8418.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.8018.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8419.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.8032.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8692.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.8418.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8702.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.8419.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9044.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.8702.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9045.xml"
<xi:include href="https://xml2rfc.tools.ietf.org/public/r />
fc/bibxml/reference.RFC.9044.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/r <reference anchor='RFC9480' target='https://www.rfc-editor.org/info/rfc9480'>
fc/bibxml/reference.RFC.9045.xml"/> <front>
<xi:include href="https://datatracker.ietf.org/doc/bibxml <title>Certificate Management Protocol (CMP) Updates</title>
3/draft-ietf-lamps-cmp-updates.xml"/> <author initials='H' surname='Brockhaus' fullname='Hendrik Brockhaus'>
<xi:include href="https://datatracker.ietf.org/doc/bibxml <organization />
3/reference.I-D.ietf-lamps-lightweight-cmp-profile.xml"/> </author>
<!-- A reference written by an organization not a person. <author initials='D' surname='von Oheimb' fullname='David von Oheimb'>
--> <organization />
<xi:include href="https://xml2rfc.tools.ietf.org/public/r </author>
fc/bibxml-nist/reference.NIST.FIPS.180-4.xml"/> <author initials='J' surname='Gray' fullname='John Gray'>
<xi:include href="https://xml2rfc.tools.ietf.org/public/r <organization />
fc/bibxml-nist/reference.NIST.FIPS.202.xml"/> </author>
<xi:include href="https://xml2rfc.tools.ietf.org/public/r <date year='2023' month='October'/>
fc/bibxml-nist/reference.NIST.SP.800-38d.xml"/> </front>
<xi:include href="https://xml2rfc.tools.ietf.org/public/r <seriesInfo name="RFC" value="9480"/>
fc/bibxml-nist/reference.NIST.SP.800-185.xml"/> <seriesInfo name="DOI" value="10.17487/RFC9480"/>
<!-- <xi:include href="http://xml2rfc.tools.ietf.org/pub </reference>
lic/rfc/bibxml-nist/reference.NIST.FIPS.186-4.xml"/>
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml-nist/ <reference anchor='RFC9483' target='https://www.rfc-editor.org/info/rfc9483'>
reference.NIST.FIPS.197.xml"/> <front>
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml-nist/ <title>Lightweight Certificate Management Protocol (CMP) Profile</title>
reference.NIST.FIPS.198-1.xml"/> --> <author initials='H' surname='Brockhaus' fullname='Hendrik Brockhaus'>
<reference anchor="NIST.FIPS.186-4" target="https://nvlpu <organization />
bs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf"> </author>
<front> <author initials='S' surname='Fries' fullname='Steffen Fries'>
<title>Digital Signature Standard (DSS)</ <organization />
title> </author>
<author> <author initials='D' surname='von Oheimb' fullname='David von Oheimb'>
<organization showOnFrontPage="tr <organization />
ue">National Institute of Standards and Technology (NIST)</organization> </author>
</author> <date year='2023' month='October'/>
<date year="2013" month="July"/> </front>
</front> <seriesInfo name="RFC" value="9483"/>
<seriesInfo name="NIST" value="NIST FIPS 186-4"/> <seriesInfo name="DOI" value="10.17487/RFC9483"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.1 </reference>
86-4"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml-nist/reference.NIST.FIP
<reference anchor="NIST.FIPS.197" target="https://nvlpubs S.180-4.xml"/>
.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml-nist/reference.NIST.FIP
<title>Advanced encryption standard (AES) S.202.xml"/>
</title>
<author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml-nist/reference.NIST.SP.
<organization showOnFrontPage="tr 800-38d.xml"/>
ue">National Institute of Standards and Technology (NIST)</organization>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml-nist/reference.NIST.SP.
<date year="2001" month="November"/> 800-185.xml"/>
</front>
<seriesInfo name="NIST" value="NIST FIPS 197"/> <reference anchor="NIST.FIPS.197" target="https://nvlpubs.nist.gov/nistpubs/FIPS
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.1 /NIST.FIPS.197.pdf">
97"/> <front>
</reference> <title>Advanced Encryption Standard (AES)</title>
<reference anchor="NIST.FIPS.198-1" target="https://nvlpu <author>
bs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf"> <organization showOnFrontPage="true">National Institute of Standards and T
<front> echnology (NIST)</organization>
<title>The Keyed-Hash Message Authenticat </author>
ion Code (HMAC)</title> <date year="2001" month="November"/>
<author> </front>
<organization showOnFrontPage="tr <seriesInfo name="NIST FIPS" value="197"/>
ue">National Institute of Standards and Technology (NIST)</organization> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.197"/>
</author> </reference>
<date year="2008" month="July"/>
</front> <reference anchor="NIST.FIPS.198-1" target="https://nvlpubs.nist.gov/nistpubs/FI
<seriesInfo name="NIST" value="NIST FIPS 198-1"/> PS/NIST.FIPS.198-1.pdf">
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.1 <front>
98-1"/> <title>The Keyed-Hash Message Authentication Code (HMAC)</title>
</reference> <author>
<reference anchor="NIST.FIPS.186-5" target="https://nvlpu <organization showOnFrontPage="true">National Institute of Standards and T
bs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5-draft.pdf"> echnology (NIST)</organization>
<front> </author>
<title>FIPS Pub 186-5 (Draft): Digital Si <date year="2008" month="July"/>
gnature Standard (DSS)</title> </front>
<author> <seriesInfo name="FIPS PUB" value="198-1"/>
<organization showOnFrontPage="tr <seriesInfo name="DOI" value="10.6028/NIST.FIPS.198-1"/>
ue">National Institute of Standards and Technology (NIST)</organization> </reference>
</author>
<date month="October" year="2019"/> <reference anchor="NIST.FIPS.186-5" target="https://nvlpubs.nist.gov/nistpubs/FI
</front> PS/NIST.FIPS.186-5.pdf">
</reference> <front>
</references> <title>Digital Signature Standard (DSS)</title>
<references title="Informative References"> <author>
<xi:include href="https://xml2rfc.tools.ietf.org/public/r <organization showOnFrontPage="true">National Institute of Standards and T
fc/bibxml/reference.RFC.8692.xml"/> echnology (NIST)</organization>
<xi:include href="https://xml2rfc.tools.ietf.org/public/r </author>
fc/bibxml/reference.RFC.8551.xml"/> <date month="February" year="2023"/>
<!-- A reference written by an organization not a person. </front>
--> <seriesInfo name="FIPS PUB" value="186-5"/>
<reference anchor="ECRYPT.CSA.D5.4" target="https://www.e <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/>
crypt.eu.org/csa/documents/D5.4-FinalAlgKeySizeProt.pdf"> </reference>
<front> </references>
<title>Algorithms, Key Size and Protocols
Report (2018)</title> <references>
<author initials="" surname="" fullname=" <name>Informative References</name>
"> <reference anchor="ECRYPT.CSA.D5.4" target="https://www.ecrypt.eu.org/csa/docume
<organization showOnFrontPage="tr nts/D5.4-FinalAlgKeySizeProt.pdf">
ue">University of Bristol</organization> <front>
</author> <title>Algorithms, Key Size and Protocols Report (2018)</title>
<date month="March" year="2015"/> <author>
</front> <organization showOnFrontPage="true">University of Bristol</organization>
</reference> </author>
<xi:include href="https://xml2rfc.tools.ietf.org/public/r <date month="March" year="2015"/>
fc/bibxml-nist/reference.NIST.SP.800-57pt1r5.xml"/> </front>
</references> </reference>
<section anchor="History" title="History of Changes">
<t>Note: This appendix will be deleted in the final versi <xi:include href="https://bib.ietf.org/public/rfc/bibxml-nist/reference.NIST.SP.
on of the document.</t> 800-57pt1r5.xml"/>
<t keepWithNext="true">From version 14 -> 15:</t> </references>
<ul spacing="compact"> </references>
<li>Providing changes addressing comment from Mar <section anchor="Acknowledgements" numbered="false">
tin Duke and Zaheduzzaman Sarker regarding the introduction</li> <name>Acknowledgements</name>
</ul> <t>Thanks to <contact fullname="Russ Housley"/> for his w
<t keepWithNext="true">From version 13 -> 14:</t> ork on <xref target="RFC9044"/> and <xref target="RFC9045"/> upon which this RFC
<ul spacing="compact"> relies heavily.</t>
<li>Providing changes addressing comments from GE <t>May thanks also to all reviewers like <contact fullnam
N AD review</li> e="Serge Mister"/>, <contact fullname="Mark Ferreira"/>, <contact fullname="Yuef
</ul> ei Lu"/>, <contact fullname="Tomas Gustavsson"/>, <contact fullname="Lijun Liao"
<t keepWithNext="true">From version 12 -> 13:</t> />, <contact fullname="David von Oheimb"/>, and <contact fullname="Steffen Fries
<ul spacing="compact"> "/> for their input and feedback to this document. Apologies to all not mentione
<li>Providing changes addressing comments from OP d reviewers and supporters.</t>
SDIR and GENART last call reviews</li>
</ul>
<t keepWithNext="true">From version 11 -> 12:</t>
<ul spacing="compact">
<li>Capitalized all headlines</li>
</ul>
<t keepWithNext="true">From version 10 -> 11:</t>
<ul spacing="compact">
<li>Changes on the tables in Section 7 after dire
ct exchange with Quynh</li>
</ul>
<t keepWithNext="true">From version 09 -> 10:</t>
<ul spacing="compact">
<li>Removed the pre-RFC5378 work disclaimer after
the RFC 4210 authors granted BCP78 rights to the IETF Trust</li>
<li>Implemented the changes proposed by Quynh, (s
ee thread "Quynh Action: draft-ietf-lamps-cmp-algorithms-08.txt") and removed ma
rkers for ToDos regarding this review of SHAKE and KMAC usage as well as on the
tables in Section 7</li>
</ul>
<t keepWithNext="true">From version 08 -> 09:</t>
<ul spacing="compact">
<li>Updated IPR disclaimer</li>
</ul>
<t keepWithNext="true">From version 07 -> 08:</t>
<ul spacing="compact">
<li>Fixing issues from WG and AD review</li>
<li>Adding Note to Section 2.2, 3.3, and 6.2.3 re
garding usage of SHAKE and KMAC and added ToDo regarding checking respective not
es</li>
<li>Added two tables showing algorithms sorted by
their strength to Section 7 and added ToDo regarding checking these tables</li>
<li>Updates the algorithm use profile in Section
7.1</li>
<li>Updated and added security consideration on S
HAKE, PasswordBasedMac, KMAC, and symmetric key-based MAC functions and added To
Do regarding checking the security consideration on SHAKE</li>
</ul>
<t keepWithNext="true">From version 06 -> 07:</t>
<ul spacing="compact">
<li>Fixing minor formatting nits</li>
</ul>
<t keepWithNext="true">From version 05 -> 06:</t>
<ul spacing="compact">
<li>Added text to Section 2 and Section 3.3 to cl
early specify the hash algorithm to use for certConf messages for certificates s
igned with EdDSA (see thread "[CMP Updates] Hash algorithm to us for calculating
certHash")</li>
<li>Updated new RFC numbers for I-D.ietf-lamps-cm
s-aes-gmac-alg and I-D.ietf-lamps-crmf-update-algs</li>
</ul>
<t keepWithNext="true">From version 04 -> 05:</t>
<ul spacing="compact">
<li>Minor changes and corrections in wording</li>
</ul>
<t keepWithNext="true">From version 03 -> 04:</t>
<ul spacing="compact">
<li>Added John Gray to the list of authors due to
his extensive support and valuable feedback</li>
<li>Added some clarification of the use AES-GMAC
to Section 6.2.1</li>
<li>Extended the guidance on how to select a set
of algorithms in Section 7 and deleted former Section 7.1</li>
<li>Deleted the algorithms mandatory to support i
n Section 7.2 as discussed at IETF 110</li>
<li>Extended the Security considerations in Secti
on 9</li>
<li>Minor changes in wording</li>
</ul>
<t keepWithNext="true">From version 02 -> 03:</t>
<ul spacing="compact">
<li>Moved former Appendix A to new Section 7 as s
uggested by Rich and Russ (see thread "I-D Action: draft-ietf-lamps-cmp-algorith
ms-02.txt")</li>
<li>Added a column to Table 1 in Section 7.2 to r
eflect the changes to RFC 4210</li>
<li>Updated Table 2 in Section 7.3</li>
<li>Added a paragraph to Section 9 to discuss bac
kward compatibility with RFC 4210</li>
<li>Minor changes in wording</li>
</ul>
<t keepWithNext="true">From version 01 -> 02:</t>
<ul spacing="compact">
<li>Added Hans Aschauer, Mike Ounsworth, and Serg
e Mister as co-author</li>
<li>Changed to XML V3</li>
<li>Added SHAKE digest algorithm to Section 2 as
discussed at IETF 109</li>
<li>Deleted DSA from Section 3 as discussed at IE
TF 109</li>
<li>Added RSASSA-PSS with SHAKE to Section 3</li>
<li>Added SECP curves the section on ECDSA with S
HA2, ECDSA with SHAKE, and EdDSA to Section 3 as discussed at IETF 109</li>
<li>Deleted static-static D-H and ECDH from Secti
on 4.1 based on the discussion on the mailing list (see thread "[CMP Algorithms]
Section 4.1.1 and 4.1.2 drop static-static (EC)DH key agreement algorithms for
use in CMP")</li>
<li>Added ECDH OIDs and SECP curves, as well as E
CDH with curve25519 and curve448 to Section 4.1 as discussed at IETF 109</li>
<li>Deleted RSA-OAEP from Section 4.2 first as di
scussed at IETF 109, but re-added it after discussion on the mailing list (see t
hread "Mail regarding draft-ietf-lamps-cmp-algorithms")</li>
<li>Added a paragraph to Section 4.3.1 to explain
that the algorithms and key length for content encryption and key wrapping must
be aligned as discussed on the mailing list (see thread "[CMP Algorithms] Use K
ey-Wrap with or without padding in Section 4.3 and Section 5")</li>
<li>Deleted AES-CCM and AES-GMC from and added AE
S-CBC to Section 5 as discussed at IETF 109</li>
<li>Added Section 6.1.2 to offer PBMAC1 as discus
ses on the mailing list (see thread "Mail regarding draft-ietf-lamps-crmf-update
-algs-02") and restructured text in Section 6 to be easier to differentiate betw
een password- and shared-key-based MAC</li>
<li>Deleted Diffie-Hellmann based MAC from Sectio
n 6 as is only relevant when using enrolling Diffie-Hellmann certificates</li>
<li>Added AES-GMAC and SHAKE-based KMAC to Sectio
n 6 as discussed at IETF 109</li>
<li>Extended Section 9 to mention Russ supporting
with two additional I-Ds and name further supporters of the draft</li>
<li>Added a first draft of a generic algorithm se
lection guideline to Appendix A</li>
<li>Added a first proposal for mandatory algorith
ms for the Lightweight CMP Profile to Appendix A</li>
<li>Minor changes in wording</li>
</ul>
<t keepWithNext="true">From version 00 -> 01:</t>
<ul spacing="compact">
<li>Changed sections Symmetric Key-Encryption Alg
orithms and Content Encryption Algorithms based on the discussion on the mailing
list (see thread "[CMP Algorithms] Use Key-Wrap with or without padding in Sect
ion 4.3 and Section 5")</li>
<li>Added Appendix A with updated algorithms prof
ile for RDC4210 Appendix D.2 and first proposal for the Lightweight CMP Profile<
/li>
<li>Minor changes in wording</li>
</ul>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 156 change blocks. 
965 lines changed or deleted 818 lines changed or added

This html diff was produced by rfcdiff 1.48.