<?xmlversion='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"> -->version="1.0" encoding="UTF-8"?> <!DOCTYPE rfc [<!-- declare nbsp and friends --><!ENTITY nbsp" ">" "> <!ENTITY zwsp "​"> <!ENTITY nbhy"‑">"‑"> <!ENTITY wj"⁠">"⁠"> ]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. --> <?rfc strict="yes" ?> <?rfc toc="yes"?> <?rfc tocdepth="4"?> <!-- the number of levels of subsections in ToC. default: 3 --> <?rfc symrefs="yes"?> <?rfc sortrefs="yes" ?> <?rfc compact="yes" ?> <?rfc subcompact="no" ?> <?rfc iprnotified="no" ?> <!-- end of list of popular I-D processing instructions --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std"docName="draft-ietf-lamps-cmp-algorithms-15"consensus="true" docName="draft-ietf-lamps-cmp-algorithms-16" number="9481" ipr="trust200902" obsoletes="" updates="4210"submissionType="IETF"xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true"consensus="true"version="3"> <front> <title abbrev="CMP Algorithms">Certificate Management Protocol (CMP) Algorithms</title> <seriesInfoname="Internet-Draft" value="draft-ietf-lamps-cmp-algorithms-15"/> <!-- add 'role="editor"' below for the editors if appropriate --> <!-- Another author who claims to be an editor -->name="RFC" value="9481"/> <author fullname="Hendrik Brockhaus" initials="H."surname="Brockhaus" role="editor">surname="Brockhaus"> <organization abbrev="Siemens">Siemens AG</organization> <address> <postal><street/> <code/> <city/> <country/><street>Werner-von-Siemens-Strasse 1</street> <code>80333</code> <city>Munich</city> <country>Germany</country> </postal><phone/><email>hendrik.brockhaus@siemens.com</email><uri/><uri>https://www.siemens.com</uri> </address> </author> <author fullname="Hans Aschauer" initials="H." surname="Aschauer"> <organization abbrev="Siemens">Siemens AG</organization> <address> <postal><street/> <code/> <city/> <country/><street>Werner-von-Siemens-Strasse 1</street> <code>80333</code> <city>Munich</city> <country>Germany</country> </postal><phone/><email>hans.aschauer@siemens.com</email><uri/><uri>https://www.siemens.com</uri> </address> </author> <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth"> <organization abbrev="Entrust">Entrust</organization> <address> <postal><street/> <code/> <city/> <country/><street>1187 Park Place</street> <region>MN</region> <code>55379</code> <city>Minneapolis</city> <country>United States of America</country> </postal><phone/><email>mike.ounsworth@entrust.com</email><uri/><uri>https://www.entrust.com</uri> </address> </author> <author fullname="John Gray" initials="J." surname="Gray"> <organization abbrev="Entrust">Entrust</organization> <address> <postal><street/> <code/> <city/> <country/><street>1187 Park Place</street> <region>MN</region> <code>55379</code> <city>Minneapolis</city> <country>United States of America</country> </postal><phone/><email>john.gray@entrust.com</email><uri/><uri>https://www.entrust.com</uri> </address> </author> <dateyear="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, xml2rfc will fill in the current day and month for you. If the year is not the current one, it is necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the purpose of calculating the expiry date). With drafts it is normally sufficient to specify just the year. --> <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. -->year="2023" month="October"/> <area>sec</area> <workgroup>lamps</workgroup> <keyword>CMP</keyword> <abstract> <t>This document describes the conventions for using several cryptographic algorithms with the Certificate Management Protocol (CMP). CMP is used to enroll and further manage the lifecycle of X.509 certificates. This document also updates the algorithm use profile fromRFC 4210AppendixD.2.</t>D.2 of RFC 4210.</t> </abstract> </front> <middle> <sectionanchor="Introduction" title="Introduction">anchor="Introduction"> <name>Introduction</name> <t><xreftarget="RFC4210">RFC 4210 Appendix D.2</xref>target="RFC4210" sectionFormat="of" section="D.2"/> contains a set ofalgorithms,algorithms that is mandatory to be supported by implementations conformingimplementations.to <xref target="RFC4210"/>. These algorithms were appropriate at the time CMP was released, but as cryptographic algorithms weaken over time, some of them shouldnotno longer beused anymore.used. In general, new attacks are emerging due to researchcryptoanalysisin cryptanalysis or an increase in computing power. New algorithms were introduced that are more resistant to today's attacks.</t> <t>This document lists current cryptographic algorithmsusablethat can be used with CMP to offer an easier waymaintainingto maintain the list of suitable algorithms over time.</t> <sectionanchor="Terminology" title="Terminology"> <t>Theanchor="Terminology"> <name>Terminology</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>In the followingsectionssections, ASN.1 values and types are used to indicate where algorithm identifier and output values are provided. These ASN.1 values and types are defined in <xref target="RFC4210">CMP</xref>, <xreftarget="RFC4211">CRMF</xref>,target="RFC4211">Certificate Request Message Format (CRMF)</xref>, <xreftarget="I-D.ietf-lamps-cmp-updates">CMPtarget="RFC9480">CMP Updates</xref>,orand <xreftarget="RFC5652">CMS</xref>.</t>target="RFC5652">Cryptographic Message Syntax (CMS)</xref>.</t> </section> </section> <sectionanchor="Hash" title="Messageanchor="Hash"> <name>Message DigestAlgorithms">Algorithms</name> <t>This section provides references to object identifiers and conventions to be employed by CMP implementations that support SHA2 or SHAKE message digest algorithms.</t> <t keepWithNext="true">Digest algorithm identifiers are locatedin:</t>in the:</t> <ul spacing="compact"> <li>hashAlg field of OOBCertHash andCertStatus</li>CertStatus,</li> <li>owf field of Challenge, PBMParameter, andDHBMParameter</li>DHBMParameter,</li> <li>digestAlgorithms field ofSignedData</li>SignedData, and</li> <li>digestAlgorithm field ofSignerInfo</li>SignerInfo.</li> </ul> <t keepWithNext="true">Digest values are locatedin:</t>in the:</t> <ul spacing="compact"> <li>hashVal field ofOOBCertHash</li>OOBCertHash,</li> <li>certHash field ofCertStatus</li>CertStatus, and</li> <li>witness field ofChallenge</li>Challenge.</li> </ul> <t>In addition, digest values are input to signature algorithms.</t> <sectionanchor="SHA2" title="SHA2">anchor="SHA2"> <name>SHA2</name> <t>The SHA2 algorithm family is defined in <xreftarget="NIST.FIPS.180-4">FIPS Pub 180-4</xref>.</t>target="NIST_FIPS_180_4">FIPS Pub 180-4</xref>.</t> <t keepWithNext="true">The message digest algorithms SHA-224, SHA-256, SHA-384, and SHA-512 are identified by the following OIDs:</t> <sourcecode type="asn.1"><![CDATA[ id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 } id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 } id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 } id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3 } ]]></sourcecode> <t>Specific conventions to be considered are specified in <xreftarget="RFC5754">RFC 5754 Section 2</xref>.</t>target="RFC5754" section="2" sectionFormat="of"/>.</t> </section> <sectionanchor="SHAKE" title="SHAKE">anchor="SHAKE"> <name>SHAKE</name> <t>The SHA-3 family of hash functions is defined in <xreftarget="NIST.FIPS.202"target="NIST_FIPS_202" format="default">FIPS Pub 202</xref> andincludesconsists of the fixed output length variants SHA3-224, SHA3-256, SHA3-384, and SHA3-512, as well as the extendable-output functions(SHAKEs)(XOFs) SHAKE128 and SHAKE256. Currently, SHAKE128 and SHAKE256 are the only members of the SHA3-familywhichthat are specified for use in X.509 certificates <xref target="RFC8692" format="default"/> and CMS <xref target="RFC8702" format="default"/> as one-way hashfunctionfunctions for use with RSASSA-PSS and ECDSA.</t> <t>SHAKE is an extendable-outputfunctionfunction, and <xreftarget="NIST.FIPS.202"target="NIST_FIPS_202" format="default">FIPS Pub 202</xref> prohibits using SHAKE as a general-purpose hash function. When SHAKE is used in CMP as a message digest algorithm, the output lengthMUST<bcp14>MUST</bcp14> be 256 bits for SHAKE128 and 512 bits for SHAKE256.</t> <t keepWithNext="true">The message digest algorithms SHAKE128 and SHAKE256 are identified by the following OIDs:</t> <sourcecode type="asn.1"><![CDATA[ id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashalgs(2) 11 } id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashalgs(2) 12 } ]]></sourcecode> <t>Specific conventions to be considered are specified in <xreftarget="RFC8702">RFC 8702 Section 3.1</xref>.</t>target="RFC8702" section="3.1" sectionFormat="of"/>.</t> </section> </section> <sectionanchor="Sig" title="Signature Algorithms">anchor="Sig"> <name>Signature Algorithms</name> <t>This section provides references to object identifiers and conventions to be employed by CMP implementations that support signature algorithms like RSA, ECDSA, orEdDSA signature algorithms.</t>EdDSA.</t> <t>The signature algorithm is referred to as MSG_SIG_ALG in Appendices <xreftarget="AlgProfLWP"/>, <xref target="RFC4210">RFC 4210 Appendix D and E</xref>,target="RFC4210" sectionFormat="bare" section="D"/> and <xref target="RFC4210" sectionFormat="bare" section="E"/> of <xref target="RFC4210"/>, in the <xreftarget="I-D.ietf-lamps-lightweight-cmp-profile">Lightweighttarget="RFC9483">Lightweight CMPProfile</xref>.</t>Profile</xref>, and in <xref target="AlgProfLWP"/>.</t> <t keepWithNext="true">Signature algorithm identifiers are locatedin:</t>in the:</t> <ul spacing="compact"> <li>protectionAlg field ofPKIHeader</li>PKIHeader,</li> <li>algorithmIdentifier field ofPOPOSigningKey</li>POPOSigningKey, and</li> <li>signatureAlgorithm field of CertificationRequest, SignKeyPairTypes, and SignerInfo</li> </ul> <t keepWithNext="true">Signature values are locatedin:</t>in the:</t> <ul spacing="compact"> <li>protection field ofPKIMessage</li>PKIMessage,</li> <li>signature field ofPOPOSigningKey</li>POPOSigningKey, and</li> <li>signature field of CertificationRequest andSignerInfo</li>SignerInfo.</li> </ul> <sectionanchor="RSASig" title="RSA">anchor="RSASig"> <name>RSA</name> <t>The RSA (RSASSA-PSS andPKCS#1PKCS #1 version 1.5) signature algorithm is defined in <xreftarget="RFC8017">RFC 8017</xref>.</t>target="RFC8017"/>.</t> <t keepWithNext="true">The algorithm identifier for RSASAA-PSS signatures used with SHA2 message digest algorithms is identified by the following OID:</t> <sourcecode type="asn.1"><![CDATA[ id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 } ]]></sourcecode> <t>Specific conventions to be considered are specified in <xreftarget="RFC4056">RFC 4056</xref>.</t>target="RFC4056"/>.</t> <t keepWithNext="true">The signature algorithm RSASSA-PSS used with SHAKE message digest algorithmsareis identified by the following OIDs:</t> <sourcecode type="asn.1"><![CDATA[ id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 30 } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 31 } ]]></sourcecode> <t>Specific conventions to be considered are specified in <xreftarget="RFC8702">RFC 8702 Section 3.2.1</xref>.</t>target="RFC8702" section="3.2.1" sectionFormat="of"/>.</t> <t keepWithNext="true">The signature algorithmPKCS#1PKCS #1 version 1.5 used with SHA2 message digest algorithms is identified by the following OIDs:</t> <sourcecode type="asn.1"><![CDATA[ sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } ]]></sourcecode> <t>Specific conventions to be considered are specified in <xreftarget="RFC5754">RFC 5754 Section 3.2</xref>.</t>target="RFC5754" section="3.2" sectionFormat="of"/>.</t> </section> <sectionanchor="ECDSA" title="ECDSA">anchor="ECDSA"> <name>ECDSA</name> <t>The ECDSA signature algorithm is defined in <xreftarget="NIST.FIPS.186-4">FIPS Pub 186-4</xref>.</t>target="NIST.FIPS.186-5">FIPS Pub 186-5</xref>.</t> <t keepWithNext="true">The signature algorithm ECDSA used with SHA2 message digest algorithms is identified by the following OIDs:</t> <sourcecode type="asn.1"><![CDATA[ ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } ]]></sourcecode> <t keepWithNext="true">As specified inRFC 5480 [RFC5480]<xref target="RFC5480"/>, the NIST-recommendedSECPcurves are identified by the following OIDs:</t> <sourcecode type="asn.1"><![CDATA[ secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } secp224r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 33 } secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } secp384r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 34 } secp521r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 35 } ]]></sourcecode> <t>Specific conventions to be considered are specified in <xreftarget="RFC5754">RFC 5754 Section 3.3</xref>.</t>target="RFC5754" section="3.3" sectionFormat="of" />.</t> <t keepWithNext="true">The signature algorithm ECDSA used with SHAKE message digest algorithmsareis identified by the following OIDs:</t> <sourcecode type="asn.1"><![CDATA[ id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 32 } id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 33 } ]]></sourcecode> <t>Specific conventions to be considered are specified in <xreftarget="RFC8702">RFC 8702 Section 3.2.2</xref>.</t>target="RFC8702" section="3.2.2" sectionFormat="of"/>.</t> </section> <sectionanchor="EdDSA" title="EdDSA">anchor="EdDSA"> <name>EdDSA</name> <t>The EdDSA signature algorithm is defined in <xreftarget="RFC8032">RFC 8032 Section 3.3</xref>target="RFC8032" section="3.3" sectionFormat="of"/> and <xreftarget="NIST.FIPS.186-5">FIPS Pub 186-5 (Draft)</xref>.</t>target="NIST.FIPS.186-5">FIPS Pub 186-5</xref>.</t> <t keepWithNext="true">The signature algorithm Ed25519 thatMUST<bcp14>MUST</bcp14> be used with SHA-512 message digest algorithms is identified by the following OIDs:</t> <sourcecode type="asn.1"><![CDATA[ id-Ed25519 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 112 } ]]></sourcecode> <t keepWithNext="true">The signature algorithm Ed448 thatMUST<bcp14>MUST</bcp14> be used with SHAKE256 message digest algorithms is identified by the following OIDs:</t> <sourcecode type="asn.1"><![CDATA[ id-Ed448 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 113 } ]]></sourcecode> <t>Specific conventions to be considered are specified in <xreftarget="RFC8419">RFC 8419</xref>.</t>target="RFC8419"/>.</t> <t>Note: The hash algorithm used to calculate the certHash in certConf messagesMUST<bcp14>MUST</bcp14> be SHA512 if the certificate to be confirmed has been signed using Ed25519andor SHAKE256 with d=512 if the certificate to be confirmed has been signed using Ed448.</t> </section> </section> <sectionanchor="KeyMan" title="Keyanchor="KeyMan"> <name>Key ManagementAlgorithms">Algorithms</name> <t>CMP utilizes the following general key management techniques: key agreement, key transport, and passwords.</t> <t><xref target="RFC4211">CRMF</xref> and <xreftarget="I-D.ietf-lamps-cmp-updates">CMPtarget="RFC9480">CMP Updates</xref>promotespromote the use of <xreftarget="RFC5652">CMS</xref> EnvelopedDatatarget="RFC5652">CMS EnvelopedData</xref> by deprecating the use of EncryptedValue.</t> <sectionanchor="KeyAgree" title="Keyanchor="KeyAgree"> <name>Key AgreementAlgorithms">Algorithms</name> <t>The key agreement algorithm is referred to as PROT_ENC_ALG in Appendices <xreftarget="RFC4210">RFC 4210 Appendix Dtarget="RFC4210" sectionFormat="bare" section="D"/> andE</xref><xref target="RFC4210" sectionFormat="bare" section="E"/> of <xref target="RFC4210"/> and as KM_KA_ALG in the <xreftarget="I-D.ietf-lamps-lightweight-cmp-profile">Lightweighttarget="RFC9483">Lightweight CMPProfile</xref>, as well as inProfile</xref> and <xref target="AlgProf"/>.</t> <t>Key agreement algorithms are only used in CMP when using <xreftarget="RFC5652">CMS</xref> EnvelopedDatatarget="RFC5652">CMS EnvelopedData</xref> together with the key agreement key management technique. When a key agreement algorithm is used, a key-encryption algorithm (<xref target="SymKeyEnc"/>) is needed next to the content-encryption algorithm (<xref target="Enc"/>).</t> <t keepWithNext="true">Key agreement algorithm identifiers are locatedin:</t>in the:</t> <ul spacing="compact"> <li>keyEncryptionAlgorithm field ofKeyAgreeRecipientInfo</li>KeyAgreeRecipientInfo.</li> </ul> <t keepWithNext="true">Key wrap algorithm identifiers are locatedin:</t>in the:</t> <ul spacing="compact"> <li>KeyWrapAlgorithm parameters within keyEncryptionAlgorithm field ofKeyAgreeRecipientInfo</li>KeyAgreeRecipientInfo.</li> </ul> <t keepWithNext="true">Wrapped content-encryption keys are locatedin:</t>in the:</t> <ul spacing="compact"> <li>encryptedKey field ofRecipientEncryptedKeys</li>RecipientEncryptedKeys.</li> </ul> <sectionanchor="DH" title="Diffie-Hellman"> <t>Diffie-Hellmananchor="DH"> <name>Diffie-Hellman</name> <t>The Diffie-Hellman (DH) key agreement is defined in <xreftarget="RFC2631">RFC 2631</xref>target="RFC2631"/> andSHALL<bcp14>SHALL</bcp14> be used in the ephemeral-static variants, as specified in <xreftarget="RFC3370">RFC 3370</xref>.target="RFC3370"/>. Static-static variantsSHALL NOT<bcp14>SHALL NOT</bcp14> be used.</t> <t keepWithNext="true">TheDiffie-HellmanDH key agreement algorithm is identified by the following OID:</t> <sourcecode type="asn.1"><![CDATA[ id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } ]]></sourcecode> <t>Specific conventions to be considered are specified in <xreftarget="RFC3370">RFC 3370 Section 4.1</xref>.</t>target="RFC3370" section="4.1" sectionFormat="of" />.</t> </section> <sectionanchor="ECDH" title="ECDH"> <t>Ellipticanchor="ECDH"> <name>ECDH</name> <t>The Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined in <xreftarget="RFC5753">RFC 5753</xref>target="RFC5753"/> andSHALL<bcp14>SHALL</bcp14> be used in the ephemeral-staticvariantvariant, as specified in <xreftarget="RFC5753">RFC 5753</xref>target="RFC5753"/>, or the 1-PassECMQV variantElliptic Curve Menezes-Qu-Vanstone (ECMQV) variant, as specified in <xreftarget="RFC5753">RFC 5753</xref>.target="RFC5753"/>. Static-static variantsSHALL NOT<bcp14>SHALL NOT</bcp14> be used.</t> <t keepWithNext="true">The ECDH key agreement algorithm used together with NIST-recommended SECP curves are identified by the following OIDs:</t> <sourcecode type="asn.1"><![CDATA[ dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 11(11) 0 } dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 11(11) 1 } dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 11(11) 2 } dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 11(11) 3 } dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 14(14) 0 } dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 14(14) 1 } dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 14(14) 2 } dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 14(14) 3 } mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 15(15) 0 } mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 15(15) 1 } mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 15(15) 2 } mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 15(15) 3 } ]]></sourcecode> <t keepWithNext="true">As specified in <xreftarget="RFC5480">RFC 5480</xref>target="RFC5480"/>, the NIST-recommended SECP curves are identified by the following OIDs:</t> <sourcecode type="asn.1"><![CDATA[ secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } secp224r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 33 } secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } secp384r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 34 } secp521r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 35 } ]]></sourcecode> <t>Specific conventions to be considered are specified in <xreftarget="RFC5753">RFC 5753</xref>.</t>target="RFC5753"/>.</t> <t keepWithNext="true">The ECDH key agreement algorithm used together with curve25519 or curve448areis identified by the following OIDs:</t> <sourcecode type="asn.1"><![CDATA[ id-X25519 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 110 } id-X448 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 111 } ]]></sourcecode> <t>Specific conventions to be considered are specified in <xreftarget="RFC8418">RFC 8418</xref>.</t>target="RFC8418"/>.</t> </section> </section> <sectionanchor="KeyTrans" title="Keyanchor="KeyTrans"> <name>Key TransportAlgorithms">Algorithms</name> <t>The key transport algorithm is also referred to as PROT_ENC_ALG in Appendices <xreftarget="RFC4210">RFC 4210 Appendix Dtarget="RFC4210" sectionFormat="bare" section="D"/> andE</xref><xref target="RFC4210" sectionFormat="bare" section="E"/> of <xref target="RFC4210"/> and asKM_KL_ALGKM_KT_ALG in the <xreftarget="I-D.ietf-lamps-lightweight-cmp-profile">Lightweighttarget="RFC9483">Lightweight CMPProfile</xref>, as well as inProfile</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 keepWithNext="true">Key transport algorithm identifiers are locatedin:</t>in the:</t> <ul spacing="compact"> <li>keyEncryptionAlgorithm field ofKeyTransRecipientInfo</li>KeyTransRecipientInfo.</li> </ul> <t keepWithNext="true">Key transport encrypted content-encryption keys are locatedin:</t>in the:</t> <ul spacing="compact"> <li>encryptedKey field ofKeyTransRecipientInfo</li>KeyTransRecipientInfo.</li> </ul> <sectionanchor="RSAEnc" title="RSA">anchor="RSAEnc"> <name>RSA</name> <t>The RSA key transport algorithm is the RSA encryption scheme defined in <xreftarget="RFC8017">RFC 8017</xref>.</t>target="RFC8017"/>.</t> <t keepWithNext="true">The algorithm identifier for RSA (PKCS #1 v1.5) is:</t> <sourcecode type="asn.1"><![CDATA[ rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } ]]></sourcecode> <t keepWithNext="true">The algorithm identifier for RSAES-OAEP is:</t> <sourcecode type="asn.1"><![CDATA[ id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } ]]></sourcecode> <t>Further conventions to be considered for PKCS #1 v1.5 are specified in <xreftarget="RFC3370">RFC 3370 Section 4.2.1</xref>target="RFC3370" section="4.2.1" sectionFormat="of" /> and for RSAES-OAEP in <xreftarget="RFC3560">RFC 3560</xref>.</t>target="RFC3560"/>.</t> </section> </section> <sectionanchor="SymKeyEnc" title="Symmetricanchor="SymKeyEnc"> <name>Symmetric Key-EncryptionAlgorithms">Algorithms</name> <t>The symmetric key-encryption algorithm is also referred to as KM_KW_ALG in <xref target="AlgProfLWP"/> andinthe <xreftarget="I-D.ietf-lamps-lightweight-cmp-profile">Lightweighttarget="RFC9483">Lightweight CMP Profile</xref>.</t> <t>As the symmetric key-encryption key management technique is not used by CMP, the symmetric key-encryption algorithm is only needed when using the key agreement or password-based key management technique with <xref target="RFC5652">CMS</xref> EnvelopedData.</t> <t keepWithNext="true">Key wrap algorithm identifiers are locatedin:</t>in the:</t> <ul spacing="compact"> <li>parameters field of the KeyEncryptionAlgorithmIdentifier of KeyAgreeRecipientInfo andPasswordRecipientInfo</li>PasswordRecipientInfo.</li> </ul> <t keepWithNext="true">Wrapped content-encryption keys are locatedin:</t>in the:</t> <ul spacing="compact"> <li>encryptedKey field of RecipientEncryptedKeys (for key agreement) and PasswordRecipientInfo (for password-based keymanagement)</li>management).</li> </ul> <sectionanchor="AESWrap" title="AESanchor="AESWrap"> <name>AES KeyWrap">Wrap</name> <t>The AES encryption algorithm is defined in <xreftarget="NIST.FIPS.197">FIPS Pub 197</xref>target="NIST.FIPS.197">FIPS Pub 197</xref>, and the key wrapping is defined in <xreftarget="RFC3394">RFC 3394</xref>.</t>target="RFC3394"/>.</t> <t keepWithNext="true">AES key encryption has the algorithm identifier:</t> <sourcecode type="asn.1"><![CDATA[ id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 5 } id-aes192-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 25 } id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 45 } ]]></sourcecode> <t>The underlying encryption functions for the key wrap and content-encryption algorithms (as specified inSection 5)<xref target="Enc"/>) and the key sizes for the two algorithmsMUST<bcp14>MUST</bcp14> be the same (e.g., AES-128 key wrap algorithm with AES-128 content-encryptionalgorithm),algorithm); seealso<xreftarget="RFC8551">RFC 8551</xref>.</t>target="RFC8551"/>.</t> <t>Further conventions to be considered for AES key wrap are specified in <xreftarget="RFC3394">RFC 3394 Section 2.2</xref>target="RFC3394" section="2.2" sectionFormat="of" /> and <xreftarget="RFC3565">RFC 3565 Section 2.3.2</xref>.</t>target="RFC3565" section="2.3.2" sectionFormat="of" />.</t> </section> </section> <sectionanchor="KeyDeriv" title="Keyanchor="KeyDeriv"> <name>Key DerivationAlgorithms">Algorithms</name> <t>The key derivation algorithm is also referred to as KM_KD_ALG in <xref target="AlgProfLWP"/> andinthe <xreftarget="I-D.ietf-lamps-lightweight-cmp-profile">Lightweighttarget="RFC9483">Lightweight CMP Profile</xref>.</t> <t>Key derivation algorithms are only used in CMP when using <xreftarget="RFC5652">CMS</xref> EnvelopedDatatarget="RFC5652">CMS EnvelopedData</xref> together with the password-based key management technique.</t> <t keepWithNext="true">Key derivation algorithm identifiers are locatedin:</t>in the:</t> <ul spacing="compact"> <li>keyDerivationAlgorithm field ofPasswordRecipientInfo</li>PasswordRecipientInfo.</li> </ul> <t>When using the password-based key management technique with EnvelopedData as specified inCMP Updates<xref target="RFC9480">CMP Updates</xref> together with PKIProtection based on the message authentication code(MAC)-based PKIProtection,(MAC), the salt for the password-based MAC andKDFkey derivation function (KDF) must be chosen independently to ensure usage of independent symmetric keys.</t> <sectionanchor="PBKDF2" title="PBKDF2"> <t>The password-basedanchor="PBKDF2"> <name>PBKDF2</name> <t>Password-based key derivation function 2 (PBKDF2) is defined in <xreftarget="RFC8018">RFC 8018</xref>.</t>target="RFC8018"/>.</t> <tkeepWithNext="true">Password-based key derivation function 2keepWithNext="true">PBKDF2 has the algorithm identifier:</t> <sourcecode type="asn.1"><![CDATA[ id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) 12 } ]]></sourcecode> <t>Further conventions to be considered for PBKDF2 are specified in <xreftarget="RFC3370">RFC 3370 Section 4.4.1</xref>target="RFC3370" section="4.4.1" sectionFormat="of" /> and <xreftarget="RFC8018">RFC 8018 Section 5.2</xref>.</t>target="RFC8018" section="5.2" sectionFormat="of" />.</t> </section> </section> </section> <sectionanchor="Enc" title="Content Encryption Algorithms ">anchor="Enc"> <name>Content-Encryption Algorithms</name> <t>Thecontent encryptioncontent-encryption algorithm is also referred to as PROT_SYM_ALG in Appendices <xreftarget="AlgProf"/>, <xref target="RFC4210">RFC 4210 Appendix D and E</xref>,target="RFC4210" sectionFormat="bare" section="D"/> and <xref target="RFC4210" sectionFormat="bare" section="E"/> of <xref target="RFC4210"/>, in the <xreftarget="I-D.ietf-lamps-lightweight-cmp-profile">Lightweighttarget="RFC9483">Lightweight CMPProfile</xref>.</t> <t>Content encryptionProfile</xref>, and in <xref target="AlgProf"/>.</t> <t>Content-encryption algorithms areonlyused in CMP when usingCMS [RFC5652] EnvelopedData<xref target="RFC5652">CMS EnvelopedData</xref> to transport a signed private key package in case of central key generation or key archiving, a certificate to facilitate implicit proof-of-possession, or a revocation passphrase in encrypted form.</t> <tkeepWithNext="true">Content encryptionkeepWithNext="true">Content-encryption algorithm identifiers are locatedin:</t>in the:</t> <ul spacing="compact"> <li>contentEncryptionAlgorithm field ofEncryptedContentInfo</li>EncryptedContentInfo.</li> </ul> <t keepWithNext="true">Encrypted content is locatedin:</t>in the:</t> <ul spacing="compact"> <li>encryptedContent field ofEncryptedContentInfo</li>EncryptedContentInfo.</li> </ul> <sectionanchor="AESEnc" title="AES-CBC">anchor="AESEnc"> <name>AES-CBC</name> <t>The AES encryption algorithm is defined in <xref target="NIST.FIPS.197">FIPS Pub 197</xref>.</t> <tkeepWithNext="true">AES-CBCkeepWithNext="true">AES Cipher Block Chaining (AES-CBC) content encryption has the algorithm identifier:</t> <sourcecode type="asn.1"><![CDATA[ id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 2 } id-aes192-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1)22 } id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1)42 } ]]></sourcecode> <t>Specific conventions to be considered for AES-CBC content encryption are specified in <xreftarget="RFC3565">RFC 3565</xref>.</t>target="RFC3565"/>.</t> </section> </section> <sectionanchor="MAC" title="Messageanchor="MAC"> <name>Message Authentication CodeAlgorithms">Algorithms</name> <t>The message authentication code (MAC) is either used for shared secret-based CMP message protection or together with the password-based key derivation function (PBKDF2).</t> <t>Themessage authentication codeMAC algorithm is also referred to as MSG_MAC_ALG in <xref target="AlgProf"/>, Appendices <xreftarget="RFC4210">RFC 4210 Appendix Dtarget="RFC4210" sectionFormat="bare" section="D"/> andE</xref>,<xref target="RFC4210" sectionFormat="bare" section="E"/> of <xref target="RFC4210"/>, and the <xreftarget="I-D.ietf-lamps-lightweight-cmp-profile">Lightweighttarget="RFC9483">Lightweight CMP Profile</xref>.</t> <sectionanchor="PBMac" title="Password-Based MAC">anchor="PBMac"> <name>Password-Based MAC</name> <t>Password-based message authentication code (MAC) algorithms combine the derivation of a symmetric key from a password or other shared secret information and a symmetric key-based MACfunctionfunction, as specified inSection 6.2<xref target="SKMac"/>, using this derived key.</t> <tkeepWithNext="true">Message authentication codekeepWithNext="true">MAC algorithm identifiers are locatedin:</t>in the:</t> <ul spacing="compact"> <li>protectionAlg field ofPKIHeader</li>PKIHeader.</li> </ul> <t keepWithNext="true">Message authentication code values are locatedin:</t>in the:</t> <ul spacing="compact"> <li>PKIProtection field ofPKIMessage</li>PKIMessage.</li> </ul> <sectionanchor="P-BMac" title="PasswordBasedMac">anchor="P-BMac"> <name>PasswordBasedMac</name> <t>The PasswordBasedMac algorithm is defined in <xreftarget="RFC4210">RFC 4210 Section 5.1.3.1</xref>, <xref target="RFC4211">RFC 4211 Section 4.4</xref>,target="RFC4210" section="5.1.3.1" sectionFormat="of" />, <xref target="RFC4211" section="4.4" sectionFormat="of" />, and <xreftarget="RFC9045">Algorithmtarget="RFC9045">"Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format(CRMF)</xref>.</t>(CRMF)"</xref>.</t> <t keepWithNext="true">The PasswordBasedMac algorithm is identified by the following OID:</t> <sourcecode type="asn.1"><![CDATA[ id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) nt(113533) nsn(7) algorithms(66) 13 } ]]></sourcecode> <t>Further conventions to be considered forpassword-based MACPasswordBasedMac are specified in <xreftarget="RFC4210">RFC 4210 Section 5.1.3.1</xref>, <xref target="RFC4211">RFC 4211 Section 4.4</xref>,target="RFC4210" section="5.1.3.1" sectionFormat="of" />, <xref target="RFC4211" section="4.4" sectionFormat="of" />, and <xreftarget="RFC9045">Algorithmtarget="RFC9045">"Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format(CRMF)</xref>.</t>(CRMF)"</xref>.</t> </section> <sectionanchor="PBMAC1" title="PBMAC1"> <t>The Password-Basedanchor="PBMAC1"> <name>PBMAC1</name> <t>Password-Based Message Authentication Code 1 (PBMAC1) is defined in <xreftarget="RFC8018">RFC 8018</xref>.target="RFC8018"/>. PBMAC1 combines a password-based key derivationfunctionfunction, like PBKDF2 (<xreftarget="PBKDF2"/>)target="PBKDF2"/>), with an underlying symmetric key-based message authentication scheme.</t> <t keepWithNext="true">PBMAC1 has the following OID:</t> <sourcecode type="asn.1"><![CDATA[ id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) 14 } ]]></sourcecode> <t>Specific conventions to be considered for PBMAC1 are specified in<xref target="RFC8018">RFC 8018Section7.1<xref target="RFC8018" section="7.1" sectionFormat="bare"/> andA.5</xref>.</t>Appendix <xref target="RFC8018" section="A.5" sectionFormat="bare"/> of <xref target="RFC8018"/>.</t> </section> </section> <sectionanchor="SKMac" title="Symmetricanchor="SKMac"> <name>Symmetric Key-BasedMAC">MAC</name> <t>Symmetric key-based message authentication code (MAC) algorithms are used for deriving the symmetric encryption key when usingPBKDF2PBKDF2, as described in <xreftarget="PBKDF2"/>target="PBKDF2"/>, as well as withPassword-based MACpassword-based MAC, as described in <xref target="PBMac"/>.</t> <tkeepWithNext="true">Message authentication codekeepWithNext="true">MAC algorithm identifiers are locatedin:</t>in the:</t> <ul spacing="compact"> <li>protectionAlg field ofPKIHeader</li>PKIHeader,</li> <li>messageAuthScheme field ofPBMAC1</li>PBMAC1,</li> <li>mac field ofPBMParameter</li>PBMParameter, and</li> <li>prf field ofPBKDF2-params</li>PBKDF2-params.</li> </ul> <tkeepWithNext="true">Message authentication codekeepWithNext="true">MAC values are locatedin:</t>in the:</t> <ul spacing="compact"> <li>PKIProtection field ofPKIMessage</li>PKIMessage.</li> </ul> <sectionanchor="HMAC-SHA2" title="SHA2-Based HMAC">anchor="HMAC-SHA2"> <name>SHA2-Based HMAC</name> <t>The HMAC algorithm is defined in <xreftarget="RFC2104">RFC 2104</xref>target="RFC2104"/> and <xref target="NIST.FIPS.198-1">FIPS Pub 198-1</xref>.</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[ id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 8 } id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 9 } id-hmacWithSHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 10 } id-hmacWithSHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 11 } ]]></sourcecode> <t>Specific conventions to be considered for SHA2-based HMAC are specified in <xreftarget="RFC4231">RFC 4231 Section 3.1</xref>.</t>target="RFC4231" section="3.1" sectionFormat="of"/>.</t> </section> <sectionanchor="AES-GMAC" title="AES-GMAC">anchor="AES-GMAC"> <name>AES-GMAC</name> <t>The AES-GMAC algorithm is defined in <xref target="NIST.FIPS.197">FIPS Pub 197</xref> and <xreftarget="NIST.SP.800-38d">NIST SP 800-38d</xref>.</t>target="NIST_SP_800_38d">NIST SP 800-38d</xref>.</t> <t>Note: The AES-GMACMUST NOT<bcp14>MUST NOT</bcp14> be used twice with the same parameter set, especially the same nonce. Therefore, itMUST NOT<bcp14>MUST NOT</bcp14> be used together with PBKDF2. When using it withPBMAC1PBMAC1, itMUST<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 algorithm is identified by the following OIDs:</t> <sourcecode type="asn.1"><![CDATA[ id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 9 } id-aes192-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 29 } id-aes256-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 49 } ]]></sourcecode> <t>Specific conventions to be considered for the AES-GMAC are specified in <xreftarget="RFC9044">RFC 9044</xref>.</t>target="RFC9044"/>.</t> </section> <sectionanchor="SHAKE-KMAC" title="SHAKE-Based KMAC">anchor="SHAKE-KMAC"> <name>SHAKE-Based KMAC</name> <t>The KMAC algorithm is defined in <xreftarget="RFC8702">RFC 8702</xref>target="RFC8702"/> and <xreftarget="NIST.SP.800-185">FIPS SP 800-185</xref>.</t>target="NIST_SP_800_185">FIPS SP 800-185</xref>.</t> <t keepWithNext="true">The SHAKE-based KMAC algorithm is identified by the following OIDs:</t> <sourcecode type="asn.1"><![CDATA[id-KmacWithSHAKE128id-KMACWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4)2hashAlgs(2) 19 }id-KmacWithSHAKE256id-KMACWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4)2hashAlgs(2) 20 } ]]></sourcecode> <t>Specific conventions to be considered for KMAC with SHAKE are specified in <xreftarget="RFC8702">RFC 8702 Section 3.4</xref>.</t>target="RFC8702" section="3.4" sectionFormat="of" />.</t> </section> </section> </section> <sectionanchor="AlgProf" title="Algorithmanchor="AlgProf"> <name>Algorithm UseProfiles">Profiles</name> <t>This section provides profiles of algorithms and respective conventions for different application use cases.</t> <t>Recommendations like those described in Table 2 of <xreftarget="NIST.SP.800-57pt1r5">NISTtarget="NIST_SP_800_57pt1r5">NIST SP 800-57Recommendation"Recommendation for KeyManagement Table 2</xref>Management"</xref> and Section 4.6 of <xref target="ECRYPT.CSA.D5.4">ECRYPTAlgorithms,"Algorithms, Key Size and Protocols Report(2018) Section 4.6</xref>(2018)"</xref> provide general information on current cryptographic algorithms.</t> <t keepWithNext="true">The overall cryptographic strength ofaCMPdeploymentimplementations will depend on several factors, including:</t> <ul spacing="normal"><li>Capabilities<li>capabilities of the end entity: What kind of algorithms does the end entitysupport.support? The cryptographic strength of the systemSHOULD<bcp14>SHOULD</bcp14> be at least as strong as the algorithms and keys used for the certificate being managed.</li><li>Algorithm<li>algorithm profile: The overall strength of the profile will be the strength of the weakest algorithm it contains.</li> <li> <tkeepWithNext="true">MessagekeepWithNext="true">message protection: The overall strength of theCMCCMP messageprotection</t>protection.</t> <ul spacing="normal"> <li>MAC-based protection: The entropy of the shared secret information or password when MAC-based message protection is used (MSG_MAC_ALG).</li><li>Signature-based<li>signature-based protection: The strength of the key pair and signature algorithm when signature-based protection is used (MSG_SIG_ALG).</li><li>Protection<li>protection of centrally generated keys: The strength of the algorithms used for the key management technique (<xreftarget="AlgProfLWP"/>:target="AlgProf4210"/>: PROT_ENC_ALG or <xreftarget="AlgProf4210"/>:target="AlgProfLWP"/>: KM_KA_ALG, KM_KT_ALG, KM_KD_ALG) and the encryption of the content-encryption key and private key (<xreftarget="AlgProfLWP"/>:target="AlgProf4210"/>: SYM_PENC_ALG, PROT_SYM_ALG or <xreftarget="AlgProf4210"/>:target="AlgProfLWP"/>: KM_KW_ALG, PROT_SYM_ALG).</li> </ul> </li> </ul> <t keepWithNext="true">The following table shows the algorithms listed in this document sorted by their bits of security. If an implementation intends to enroll and managecertificatecertificates for keys of a specific security, itSHALL<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 suitable algorithm, the implementerMUST<bcp14>MUST</bcp14> choose one offering more bits of security.</t> <table anchor="BalacedAlgSets" align="left"> <name>Cryptographic Algorithms Sorted bytheirTheir Bits of Security</name> <thead> <tr> <th align='left'>Bits ofSecu-<br/>rity</th>Security</th> <th align='left'>RSA or DH</th> <th align='left'>EllipticCurve</th>Curve Cryptography</th> <th align='left'>Hash Function or XOF with Specified Output Length (d)</th> <th align='left'>Symmetric Encryption</th> </tr> </thead> <tbody> <tr> <td align="left">112</td> <td align="left">RSA2048,<br/>DH(2048)</td> <td align="left">ECDSA/ECDH (secp224r1)</td> <tdalign="left">SHA224</td>align="left">SHA-224</td> <td align="left"></td> </tr> <tr> <td align="left">128</td> <td align="left">RSA3072,<br/>DH(3072)</td> <td align="left">ECDSA/ECDH (secp256r1),<br/>Ed25519/X25519(Curve25519)</td>(curve25519)</td> <tdalign="left">SHA256,<br/>SHAKE128(d=256)</td>align="left">SHA-256,<br/>SHAKE128(d=256)</td> <td align="left">AES-128</td> </tr> <tr> <td align="left">192</td> <td align="left"></td> <td align="left">ECDSA/ECDH (secp384r1)</td> <tdalign="left">SHA384</td>align="left">SHA-384</td> <td align="left">AES-192</td> </tr> <tr> <td align="left">224</td> <td align="left"></td> <td align="left">Ed448/X448(Curve448)</td>(curve448)</td> <td align="left"></td> <td align="left"></td> </tr> <tr> <td align="left">256</td> <td align="left"></td> <td align="left">ECDSA/ECDH (secp521r1)</td> <tdalign="left">SHA512,<br/>SHAKE256(d=512)</td>align="left">SHA-512,<br/>SHAKE256(d=512)</td> <td align="left">AES-256</td> </tr> </tbody> </table> <t>The following table shows the cryptographic algorithms sorted by their usage in CMP and with more details.</t> <table anchor="BalacedAlgSetsCMP" align="left"> <name>Cryptographic Algorithms Sorted bytheirTheir Bits of Security and Usage by CMP</name> <thead> <tr> <th align='left'>Bitsof<br/>Security</th>of Security</th> <th align='left'>Key Types to Be Certified</th> <th align='left'>CMPProtection</th>Protection<br/>MSG_SIG_ALG, MSG_MAC_ALG</th> <th align='left'>Key ManagementTechnique</th>Technique<br/>PROT_ENC_ALG or KM_KA_ALG, KM_KT_ALG, KM_KD_ALG</th> <th align='left'>Key-Wrap and SymmetricEncryption</th>Encryption<br/>PROT_SYM_ALG,<br/>SYM_PENC_ALG<br/>or<br/>KM_KW_ALG</th> </tr> </thead> <tbody> <tr> <tdalign="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> <tdalign="left">112</td> <td align="left">RSA2048,<br/>secp224r1</td> <td align="left">RSASSA-PSS (2048,SHA224SHA-224 or SHAKE128 (d=256)),<br/>RSAEncryption (2048,SHA224),<br/>ECDSASHA-224),<br/>ECDSA (secp224r1,SHA224SHA-224 or SHAKE128 (d=256)),<br/>PBMAC1(HMAC-SHA224)</td>(HMAC-SHA-224)</td> <td align="left">DH(2048),<br/>RSAES-OAEP (2048,SHA224),<br/>RSAEncryptionSHA-224),<br/>RSAEncryption (2048,SHA224),<br/>ECDHSHA-224),<br/>ECDH (secp224r1,SHA224),<br/>PBKDF2 (HMAC-SHA224)</td>SHA-224),<br/>PBKDF2 (HMAC-SHA-224)</td> <td align="left"></td> </tr> <tr> <td align="left">128</td> <tdalign="left">RSA3072,<br/>secp256r1,<br/>Curve25519</td>align="left">RSA3072,<br/>secp256r1,<br/>curve25519</td> <td align="left">RSASSA-PSS (3072,SHA256SHA-256 or SHAKE128 (d=256)),<br/>RSAEncryption (3072,SHA256),<br/>ECDSASHA-256),<br/>ECDSA (secp256r1,SHA256SHA-256 or SHAKE128 (d=256)),<br/>Ed25519(SHA512),<br/>PBMAC1 (HMAC-SHA256)</td>(SHA-512),<br/>PBMAC1 (HMAC-SHA-256)</td> <td align="left">DH(3072),<br/>RSAES-OAEP (3072,SHA256),<br/>SHA-256),<br/> RSAEncryption (3072,SHA256),<br/>ECDHSHA-256),<br/>ECDH (secp256r1,SHA256),<br/>X25519,<br/>PBKDF2 (HMAC-SHA256)</td>SHA-256),<br/>X25519,<br/>PBKDF2 (HMAC-SHA-256)</td> <td align="left">AES-128</td> </tr> <tr> <td align="left">192</td> <td align="left">secp384r1</td> <td align="left">ECDSA (secp384r1,SHA384),<br/>PBMAC1 (HMAC-SHA384)</td>SHA-384),<br/>PBMAC1 (HMAC-SHA-384)</td> <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> </tr> <tr> <td align="left">224</td> <tdalign="left">Curve448</td>align="left">curve448</td> <td align="left">Ed448 (SHAKE256)</td> <td align="left">X448</td> <td align="left"></td> </tr> <tr> <td align="left">256</td> <td align="left">secp521r1</td> <td align="left">ECDSA (secp521r1,SHA512SHA-512 or SHAKE256 (d=512)),<br/>PBMAC1(HMAC-SHA512)</td>(HMAC-SHA-512)</td> <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> </tr> </tbody> </table> <t>To avoid consuming too many computationalresources it is recommended to chooseresources, choosing a set of algorithms offering roughly the same level ofsecurity.security is recommended. Below areprovidedseveral algorithm profileswhichthat are balanced, assuming the implementer chooses MAC secrets and/or certificate profiles of at least equivalent strength.</t> <sectionanchor="AlgProf4210" title="Algorithmanchor="AlgProf4210"> <name>Algorithm Profile forRFC 4210PKI Management MessageProfiles">Profiles in RFC 4210</name> <t>The following table updates the definitions of algorithms used within PKI Management MessageProfilesProfiles, as defined in <xreftarget="RFC4210">CMP Appendix D.2</xref>.</t>target="RFC4210" sectionFormat="of" section="D.2"/>.</t> <t>The columns in the table are:</t><t>Name: An<dl newline="false" spacing="normal"> <dt>Name:</dt> <dd>An identifier used for messageprofiles</t> <t>Use: Descriptionprofiles</dd> <dt>Use:</dt> <dd>Description of where and for what the algorithm isused</t> <t>Mandatory: Algorithms which MUSTused</dd> <dt>Mandatory:</dt> <dd>Algorithms that <bcp14>MUST</bcp14> be supported by conformingimplementations</t> <t>Optional: Algorithms whichimplementations</dd> <dt>Optional:</dt> <dd>Algorithms that areOPTIONAL<bcp14>OPTIONAL</bcp14> tosupport</t> <t>Deprecated: Algorithmssupport</dd> <dt>Deprecated:</dt> <dd>Algorithms from <xreftarget="RFC4210">RFC 4210</xref> which SHOULD NOTtarget="RFC4210"/> that <bcp14>SHOULD NOT</bcp14> be used anymore</t>more</dd> </dl> <table anchor="AlgProd4210T"> <name>Algorithms UsedWithin RFC 4210within AppendixD.2</name>D.2 of RFC 4210</name> <thead> <tr> <th align='left'>Name</th> <th align='left'>Use</th> <thalign='left'>Manda-<br/>tory</th>align='left'>Mandatory</th> <th align='left'>Optional</th> <th align='left'>Deprecated</th> </tr> </thead> <tbody> <tr> <td align="left">MSG_SIG_ALG</td> <td align="left">protection of PKI messages usingsignature</td>signatures</td> <td align="left">RSA</td> <td align="left">ECDSA, EdDSA</td> <td align="left">DSA, combinations with MD5 and SHA-1</td> </tr> <tr> <td align="left">MSG_MAC_ALG</td> <td align="left">protection of PKI messages usingMACing</td>MACs</td> <td align="left">PBMAC1</td> <td align="left">PasswordBasedMac, HMAC, KMAC</td> <td align="left">X9.9</td> </tr> <tr> <td align="left">SYM_PENC_ALG</td> <td align="left">symmetric encryption of an end entity's private key where the symmetric key is distributedout-of-band</td>out of band</td> <td align="left">AES-wrap</td> <td align="left"></td> <td align="left">3-DES(3-key-EDE, CBC Mode), RC5, CAST-128</td> </tr> <tr> <td align="left">PROT_ENC_ALG</td> <td align="left">asymmetric algorithm used for encryption of (symmetric keys for encryption of) private keys transported in PKIMessages</td> <td align="left">DH</td> <td align="left">ECDH, RSA</td> <td align="left"></td> </tr> <tr> <td align="left">PROT_SYM_ALG</td> <td align="left">symmetric encryption algorithm used for encryption of private key bits (a key of this type is encrypted using PROT_ENC_ALG)</td> <td align="left">AES-CBC</td> <td align="left"></td> <td align="left">3-DES(3-key-EDE, CBC Mode), RC5, CAST-128</td> </tr> </tbody> </table> <tkeepWithNext="true">Mandatory Algorithm IdentifierskeepWithNext="true">The following are the mandatory algorithm identifiers andSpecifications:</t> <t>RSA: sha256WithRSAEncryptionspecifications:</t> <dl newline="false" spacing="normal"> <dt>RSA:</dt> <dd>sha256WithRSAEncryption with 2048 bit, see <xreftarget="RSASig"/></t> <t>PasswordBasedMac: id-PasswordBasedMac,target="RSASig"/></dd> <dt>PasswordBasedMac:</dt> <dd>id-PasswordBasedMac, see <xref target="PBMac"/> (with id-sha256 as the owf parameter, see <xref target="SHA2"/> and id-hmacWithSHA256 as the mac parameter, see <xreftarget="HMAC-SHA2"/>)</t> <t>PBMAC1: id-PBMAC1,target="HMAC-SHA2"/>)</dd> <dt>PBMAC1:</dt> <dd>id-PBMAC1, see <xref target="PBMAC1"/> (with id-PBKDF2 as the key derivation function, see <xref target="PBKDF2"/> and id-hmacWithSHA256 as the message authentication scheme, see <xref target="HMAC-SHA2"/>). It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to prefer the usage of PBMAC1 instead ofPasswordBasedMac.</t> <t>DH: id-alg-ESDH,PasswordBasedMac.</dd> <dt>DH:</dt> <dd>id-alg-ESDH, see <xreftarget="DH"/></t> <t>AES-wrap: id-aes128-wrap,target="DH"/></dd> <dt>AES-wrap:</dt> <dd>id-aes128-wrap, see <xreftarget="AESWrap"/></t> <t>AES-CBC: id-aes128-CBC,target="AESWrap"/></dd> <dt>AES-CBC:</dt> <dd>id-aes128-CBC, see <xreftarget="AESEnc"/></t>target="AESEnc"/></dd> </dl> </section> <sectionanchor="AlgProfLWP" title="Algorithmanchor="AlgProfLWP"> <name>Algorithm Profile for Lightweight CMPProfile">Profile</name> <t>The following table contains definitions of algorithmswhich MAYthat <bcp14>MAY</bcp14> be supported by implementations of the <xreftarget="I-D.ietf-lamps-lightweight-cmp-profile">Lightweighttarget="RFC9483">Lightweight CMP Profile</xref>.</t> <t>As the set of algorithms to be used for implementations of the Lightweight CMP Profile heavily depends on the PKI management operations implemented, the certificates used formessagesmessage protection, and the certificates to be managed, this document will not specify a specific set that is mandatory to support for conforming implementations.</t> <t>The columns in the table are:</t><t>Name: An<dl newline="false" spacing="normal"> <dt>Name:</dt> <dd>An identifier used for messageprofiles</t> <t>Use: Descriptionprofiles</dd> <dt>Use:</dt> <dd>Description of where and for what the algorithm isused</t> <t>Examples: Listsused</dd> <dt>Examples:</dt> <dd>Lists thealgorithmsalgorithms, as described in this document. The list of algorithms depends on the set of PKI management operations to beimplemented.</t>implemented.</dd> </dl> <t>Note: It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to prefer the usage of PBMAC1 instead of PasswordBasedMac.</t> <table anchor="AlgProfLWPT"> <name>Algorithms UsedWithinwithin the Lightweight CMP Profile</name> <thead> <tr> <th align='left'>Name</th> <th align='left'>Use</th> <th align='left'>Examples</th> </tr> </thead> <tbody> <tr> <td align="left">MSG_SIG_ALG</td> <td align="left">protection of PKI messages usingsignaturesignatures and for SignedData, e.g., a private key transported in PKIMessages</td> <td align="left">RSA, ECDSA, EdDSA</td> </tr> <tr> <td align="left">MSG_MAC_ALG</td> <td align="left">protection of PKI messages using MACing</td> <td align="left">PasswordBasedMac (see <xref target="Security"/>), PBMAC1, HMAC, KMAC</td> </tr> <tr> <td align="left">KM_KA_ALG</td> <td align="left">asymmetric key agreement algorithm used for agreement of a symmetric key for use with KM_KW_ALG</td> <td align="left">DH, ECDH</td> </tr> <tr> <td align="left">KM_KT_ALG</td> <td align="left">asymmetrickey encryptionkey-encryption algorithm used for transport of a symmetric key for PROT_SYM_ALG</td> <td align="left">RSA</td> </tr> <tr> <td align="left">KM_KD_ALG</td> <td align="left">symmetric key derivation algorithm used for derivation of a symmetric key for use with KM_KW_ALG</td> <td align="left">PBKDF2</td> </tr> <tr> <td align="left">KM_KW_ALG</td> <td align="left">algorithm to wrap a symmetric key for PROT_SYM_ALG</td> <td align="left">AES-wrap</td> </tr> <tr> <td align="left">PROT_SYM_ALG</td> <td align="left">symmetriccontent encryptioncontent-encryption algorithm used for encryption of EnvelopedData, e.g., a private key transported in PKIMessages</td> <td align="left">AES-CBC</td> </tr> </tbody> </table> </section> </section> <sectionanchor="IANA" title="IANA Considerations">anchor="IANA"> <name>IANA Considerations</name> <t>This documentdoes not request changes to thehas no IANAregistry.</t>actions.</t> </section> <sectionanchor="Security" title="Security Considerations">anchor="Security"> <name>Security Considerations</name> <t>This document lists many cryptographic algorithms usable with CMP to offerimplementerimplementers a more up-to-date choice. Finally, the algorithms to be supported also heavily depend on the certificates and PKI management operations utilized in the target environment. The algorithm with the lowest security strength and the entropy of shared secret informationdefinedefines the security of the overallsolution,solution; see <xref target="AlgProf"/>.</t> <t>When using MAC-based messageprotectionprotection, the use of PBMAC1 is preferable to that of PasswordBasedMac. First, PBMAC1 is a well-known scrutinized algorithm, which is not true for PasswordBasedMac. Second, the PasswordBasedMac algorithm as specified in <xreftarget="RFC4211">RFC 4211 Section 4.4</xref>target="RFC4211" section="4.4" sectionFormat="of"/> is essentially PBKDF1 (as defined in <xreftarget="RFC8018">RFC 8018 Section 5.1</xref>)target="RFC8018" section="5.1" sectionFormat="of"/>) with an HMAC step at the end.HereHere, 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 iteratedhashing,hashing and in removingPBKDF1’sPBKDF1'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 <xreftarget="RFC8018">Section 5.1 of RFC 8018</xref>target="RFC8018" section="5.1" sectionFormat="of"/> and is no longer an approved algorithm by most standardsbodies, and thereforebodies. Therefore, it presents difficulties toimplementerimplementers who are submitting their CMP implementations for certification, hence moving to a PBKDF2-based mechanism. This change is in alignment with <xreftarget="RFC9045"/>target="RFC9045"/>, which updates <xref target="RFC4211"/> to allow the use of PBMAC1 in CRMF.</t><t>AES-GMAC MUST NOT<t>The AES-GMAC <bcp14>MUST NOT</bcp14> be used as thepseudo randompseudorandom 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 thisdocumentdocument, there is also an update tothe<xreftarget="RFC4210">Appendix D.2 of RFC 4210</xref>target="RFC4210" sectionFormat="of" section="D.2"/> and a set of algorithms thatMAY<bcp14>MAY</bcp14> be supported when implementing the <xreftarget="I-D.ietf-lamps-lightweight-cmp-profile">Lightweighttarget="RFC9483">Lightweight CMPProfile</xref>.</t> <t>ItProfile</xref>. It is recognized that there may be older CMP implementations in use that conform to the algorithm use profile from <xreftarget="RFC4210">Appendix D.2 of RFC 4210</xref>.target="RFC4210" sectionFormat="of" section="D.2"/>. For example, the use of AES is now mandatory forPROT_SYM_ALG but in <xref target="RFC4210">RFC 4210</xref>PROT_SYM_ALG, while 3-DES wasmandatory.mandatory in <xref target="RFC4210"/>. Therefore, it is expected that many CMP systems may already support the recommended algorithms in this specification. In suchsystemssystems, the weakened 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 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 <xref target="SKMac"/>MAY<bcp14>MAY</bcp14> be used as MSG_MAC_ALG. The implementerMUST<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 considerations are outside the scope of the profile.</t> </section><section anchor="Acknowledgements" title="Acknowledgements"> <t>Thanks to Russ Housley for supporting this draft with submitting <xref target="RFC9044"/> and <xref target="RFC9045"/>.</t> <t>May thanks also to all reviewers like Serge Mister, Mark Ferreira, Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steffen Fries for their input and feedback to this document. Apologies to all not mentioned reviewers and supporters.</t> </section></middle> <back><!-- References split into informative and normative --> <!-- There are 2 ways to insert reference entries from the citation libraries: 1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown) 2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml") Both are cited textually in the same manner: by using xref elements. If you use the PI option, xml2rfc will, by default, try to find included files in the same directory as the including file. You can also define the XML_LIBRARY environment variable with a value containing a set of directories to search. These can be either in the local filing system or remote ones accessed by http (http://domain/dir/... ).--> <!-- <references title="Normative References"> --><displayreference target="NIST_FIPS_180_4" to="NIST.FIPS.180-4"/> <displayreference target="NIST_FIPS_202" to="NIST.FIPS.202"/> <displayreference target="NIST_SP_800_38d" to="NIST.SP.800-38d"/> <displayreference target="NIST_SP_800_57pt1r5" to="NIST.SP.800-57pt1r5"/> <displayreference target="NIST_SP_800_185" to="NIST.SP.800-185]"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2631.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3370.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3394.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3560.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3565.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2631.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4056.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3370.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4210.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3394.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4211.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3560.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4231.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3565.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4056.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4210.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5753.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4211.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5754.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4231.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8018.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5753.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5754.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8418.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8419.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8018.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8702.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9044.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9045.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8418.xml"/> <xi:includehref="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-lamps-cmp-updates.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-lamps-lightweight-cmp-profile.xml"/> <!-- A reference written by an organization not a person. -->href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8419.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-nist/reference.NIST.FIPS.180-4.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-nist/reference.NIST.FIPS.202.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8692.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-nist/reference.NIST.SP.800-38d.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8702.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-nist/reference.NIST.SP.800-185.xml"/> <!--href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9044.xml"/> <xi:includehref="http://xml2rfc.tools.ietf.org/public/rfc/bibxml-nist/reference.NIST.FIPS.186-4.xml"/> <xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml-nist/reference.NIST.FIPS.197.xml"/> <xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml-nist/reference.NIST.FIPS.198-1.xml"/> -->href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9045.xml"/> <referenceanchor="NIST.FIPS.186-4" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf">anchor='RFC9480' target='https://www.rfc-editor.org/info/rfc9480'> <front><title>Digital Signature Standard (DSS)</title> <author><title>Certificate Management Protocol (CMP) Updates</title> <author initials='H' surname='Brockhaus' fullname='Hendrik Brockhaus'> <organizationshowOnFrontPage="true">National Institute of Standards and Technology (NIST)</organization>/> </author> <author initials='D' surname='von Oheimb' fullname='David von Oheimb'> <organization /> </author> <author initials='J' surname='Gray' fullname='John Gray'> <organization /> </author> <dateyear="2013" month="July"/>year='2023' month='October'/> </front> <seriesInfoname="NIST" value="NIST FIPS 186-4"/>name="RFC" value="9480"/> <seriesInfo name="DOI"value="10.6028/NIST.FIPS.186-4"/>value="10.17487/RFC9480"/> </reference> <reference anchor='RFC9483' target='https://www.rfc-editor.org/info/rfc9483'> <front> <title>Lightweight Certificate Management Protocol (CMP) Profile</title> <author initials='H' surname='Brockhaus' fullname='Hendrik Brockhaus'> <organization /> </author> <author initials='S' surname='Fries' fullname='Steffen Fries'> <organization /> </author> <author initials='D' surname='von Oheimb' fullname='David von Oheimb'> <organization /> </author> <date year='2023' month='October'/> </front> <seriesInfo name="RFC" value="9483"/> <seriesInfo name="DOI" value="10.17487/RFC9483"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml-nist/reference.NIST.FIPS.180-4.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml-nist/reference.NIST.FIPS.202.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml-nist/reference.NIST.SP.800-38d.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml-nist/reference.NIST.SP.800-185.xml"/> <reference anchor="NIST.FIPS.197" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf"> <front> <title>Advancedencryption standardEncryption Standard (AES)</title> <author> <organization showOnFrontPage="true">National Institute of Standards and Technology (NIST)</organization> </author> <date year="2001" month="November"/> </front> <seriesInfoname="NIST" value="NIST FIPS 197"/>name="NIST FIPS" value="197"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.197"/> </reference> <reference anchor="NIST.FIPS.198-1" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf"> <front> <title>The Keyed-Hash Message Authentication Code (HMAC)</title> <author> <organization showOnFrontPage="true">National Institute of Standards and Technology (NIST)</organization> </author> <date year="2008" month="July"/> </front> <seriesInfoname="NIST" value="NIST FIPS 198-1"/>name="FIPS PUB" value="198-1"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.198-1"/> </reference> <reference anchor="NIST.FIPS.186-5"target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5-draft.pdf">target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf"> <front><title>FIPS Pub 186-5 (Draft): Digital<title>Digital Signature Standard (DSS)</title> <author> <organization showOnFrontPage="true">National Institute of Standards and Technology (NIST)</organization> </author> <datemonth="October" year="2019"/>month="February" year="2023"/> </front> <seriesInfo name="FIPS PUB" value="186-5"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/> </reference> </references><references title="Informative References"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8692.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/> <!-- A reference written by an organization not a person. --><references> <name>Informative References</name> <reference anchor="ECRYPT.CSA.D5.4" target="https://www.ecrypt.eu.org/csa/documents/D5.4-FinalAlgKeySizeProt.pdf"> <front> <title>Algorithms, Key Size and Protocols Report (2018)</title><author initials="" surname="" fullname=""><author> <organization showOnFrontPage="true">University of Bristol</organization> </author> <date month="March" year="2015"/> </front> </reference> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-nist/reference.NIST.SP.800-57pt1r5.xml"/>href="https://bib.ietf.org/public/rfc/bibxml-nist/reference.NIST.SP.800-57pt1r5.xml"/> </references> </references> <sectionanchor="History" title="History of Changes"> <t>Note: This appendix will be deleted in the final version of the document.</t> <t keepWithNext="true">From version 14 -> 15:</t> <ul spacing="compact"> <li>Providing changes addressing comment from Martin Duke and Zaheduzzaman Sarker regarding the introduction</li> </ul> <t keepWithNext="true">From version 13 -> 14:</t> <ul spacing="compact"> <li>Providing changes addressing comments from GEN AD review</li> </ul> <t keepWithNext="true">From version 12 -> 13:</t> <ul spacing="compact"> <li>Providing changes addressing comments from OPSDIR 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 direct 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, (see thread "Quynh Action: draft-ietf-lamps-cmp-algorithms-08.txt") and removed markers 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 regarding usage of SHAKE and KMAC and added ToDo regarding checking respective notes</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 SHAKE, PasswordBasedMac, KMAC, and symmetric key-based MAC functions and added ToDo 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 clearly specify the hash algorithm to use for certConf messages for certificates signed with EdDSA (see thread "[CMP Updates] Hash algorithmanchor="Acknowledgements" numbered="false"> <name>Acknowledgements</name> <t>Thanks tous for calculating certHash")</li> <li>Updated new RFC numbers<contact fullname="Russ Housley"/> forI-D.ietf-lamps-cms-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 tohisextensive support and valuable feedback</li> <li>Added some clarification of the use AES-GMAC to Section 6.2.1</li> <li>Extended the guidancework onhow to select a set of algorithms in Section 7 and deleted former Section 7.1</li> <li>Deleted the algorithms mandatory to support in Section 7.2 as discussed at IETF 110</li> <li>Extended the Security considerations in Section 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 suggested by Rich<xref target="RFC9044"/> andRuss (see thread "I-D Action: draft-ietf-lamps-cmp-algorithms-02.txt")</li> <li>Added a column to Table 1 in Section 7.2 to reflect the changes to RFC 4210</li> <li>Updated Table 2 in Section 7.3</li> <li>Added a paragraph to Section 9 to discuss backward compatibility with<xref target="RFC9045"/> upon which this RFC4210</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 Serge 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 IETF 109</li> <li>Added RSASSA-PSS with SHAKE to Section 3</li> <li>Added SECP curves the section on ECDSA with SHA2, ECDSA with SHAKE, and EdDSA to Section 3 as discussed at IETF 109</li> <li>Deleted static-static D-H and ECDH from Section 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 ECDH with curve25519 and curve448 to Section 4.1 as discussed at IETF 109</li> <li>Deleted RSA-OAEP from Section 4.2 first as discussed at IETF 109, but re-added it after discussion on the mailing list (see thread "Mail regarding draft-ietf-lamps-cmp-algorithms")</li> <li>Added a paragraph to Section 4.3.1relies heavily.</t> <t>May thanks also toexplain that the algorithmsall reviewers like <contact fullname="Serge Mister"/>, <contact fullname="Mark Ferreira"/>, <contact fullname="Yuefei Lu"/>, <contact fullname="Tomas Gustavsson"/>, <contact fullname="Lijun Liao"/>, <contact fullname="David von Oheimb"/>, andkey length<contact fullname="Steffen Fries"/> forcontent encryption and key wrapping must be aligned as discussed on the mailing list (see thread "[CMP Algorithms] Use Key-Wrap with or without padding in Section 4.3 and Section 5")</li> <li>Deleted AES-CCM and AES-GMC from and added AES-CBC to Section 5 as discussed at IETF 109</li> <li>Added Section 6.1.2 to offer PBMAC1 as discusses 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 between password- and shared-key-based MAC</li> <li>Deleted Diffie-Hellmann based MAC from Section 6 as is only relevant when using enrolling Diffie-Hellmann certificates</li> <li>Added AES-GMAC and SHAKE-based KMAC to Section 6 as discussed at IETF 109</li> <li>Extended Section 9 to mention Russ supporting with two additional I-Dstheir input andname further supporters of the draft</li> <li>Added a first draft of a generic algorithm selection guidelinefeedback toAppendix A</li> <li>Added a first proposal for mandatory algorithms for the Lightweight CMP Profilethis document. Apologies toAppendix 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 Algorithms and Content Encryption Algorithms based on the discussion on the mailing list (see thread "[CMP Algorithms] Use Key-Wrap with or without padding in Section 4.3 and Section 5")</li> <li>Added Appendix A with updated algorithms profile for RDC4210 Appendix D.2all not mentioned reviewers andfirst proposal for the Lightweight CMP Profile</li> <li>Minor changes in wording</li> </ul>supporters.</t> </section> </back> </rfc>