idnits 2.17.1 draft-ietf-lamps-cmp-algorithms-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4210, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4210, updated by this document, for RFC5378 checks: 2000-03-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 August 2021) is 978 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-23) exists of draft-ietf-lamps-cmp-updates-12 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 3394 ** Downref: Normative reference to an Informational RFC: RFC 5753 ** Downref: Normative reference to an Informational RFC: RFC 8017 ** Downref: Normative reference to an Informational RFC: RFC 8018 ** Downref: Normative reference to an Informational RFC: RFC 8032 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-06 Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS Working Group H. Brockhaus, Ed. 3 Internet-Draft H. Aschauer 4 Updates: 4210 (if approved) Siemens 5 Intended status: Standards Track M. Ounsworth 6 Expires: 23 February 2022 J. Gray 7 Entrust 8 22 August 2021 10 Certificate Management Protocol (CMP) Algorithms 11 draft-ietf-lamps-cmp-algorithms-07 13 Abstract 15 This document describes the conventions for using concrete 16 cryptographic algorithms with the Certificate Management Protocol 17 (CMP). CMP is used to enroll and further manage the lifecycle of 18 X.509 certificates. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 23 February 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Message Digest Algorithms . . . . . . . . . . . . . . . . . . 3 56 2.1. SHA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5 59 3.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.3. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. Key Management Algorithms . . . . . . . . . . . . . . . . . . 7 63 4.1. Key Agreement Algorithms . . . . . . . . . . . . . . . . 8 64 4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 8 65 4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 10 67 4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 4.3. Symmetric Key-Encryption Algorithms . . . . . . . . . . . 11 69 4.3.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 11 70 4.4. Key Derivation Algorithms . . . . . . . . . . . . . . . . 12 71 4.4.1. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . 12 72 5. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12 73 5.1. AES-CBC . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6. Message Authentication Code Algorithms . . . . . . . . . . . 13 75 6.1. Password-based MAC . . . . . . . . . . . . . . . . . . . 13 76 6.1.1. PasswordBasedMac . . . . . . . . . . . . . . . . . . 14 77 6.1.2. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . 14 78 6.2. Symmetric key-based MAC . . . . . . . . . . . . . . . . . 14 79 6.2.1. SHA2-based HMAC . . . . . . . . . . . . . . . . . . . 15 80 6.2.2. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . 15 81 6.2.3. SHAKE-based KMAC . . . . . . . . . . . . . . . . . . 16 82 7. Algorithm Use Profiles . . . . . . . . . . . . . . . . . . . 16 83 7.1. Algorithm Profile for RFC 4210 PKI Management Message 84 Profiles . . . . . . . . . . . . . . . . . . . . . . . . 17 85 7.2. Algorithm Profile for Lightweight CMP Profile . . . . . . 19 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 89 11. Normative References . . . . . . . . . . . . . . . . . . . . 22 90 12. Informative References . . . . . . . . . . . . . . . . . . . 26 91 Appendix A. History of changes . . . . . . . . . . . . . . . . . 27 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 94 1. Introduction 96 1.1. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14 [RFC2119] [RFC8174] when, and only when, they appear in all 102 capitals, as shown here. 104 2. Message Digest Algorithms 106 This section provides references to object identifiers and 107 conventions to be employed by CMP implementations that support SHA2 108 or SHAKE message digest algorithms. 110 Digest algorithm identifiers are located in the hashAlg field of 111 OOBCertHash, the owf field of Challenge, PBMParameter, CertStatus, 112 and DHBMParameter, and the digestAlgorithms field of SignedData and 113 the digestAlgorithm field of SignerInfo. 115 Digest values are located in the hashVal field of OOBCertHash, the 116 witness field of Challenge, and the certHash field of CertStatus. In 117 addition, digest values are input to signature algorithms. 119 Note: Specific conventions are needed for CertStatus content in 120 certConf messages when confirming certificates where the 121 AlgorithmIdentifier of the certificate signature does not clearly 122 imply a specific hash algorithm. In such cases the hash algorithm to 123 use to build certHash should be specified, e.g., as done in 124 Section 2.1 and Section 2.2 for certificates signed using EdDSA. 126 2.1. SHA2 128 The SHA2 algorithm family is defined in FIPS Pub 180-4 129 [NIST.FIPS.180-4]. 131 The message digest algorithms SHA-224, SHA-256, SHA-384, and SHA-512 132 are identified by the following OIDs: 134 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 135 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 136 hashalgs(2) 4 } 137 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 138 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 139 hashalgs(2) 1 } 140 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 141 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 142 hashalgs(2) 2 } 143 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 144 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 145 hashalgs(2) 3 } 147 Specific conventions to be considered are specified in RFC 5754 148 Section 2 [RFC5754]. 150 The hash algorithm used to calculate the certHash in certConf 151 messages MUST be SHA512 if the certificate to be confirmed has been 152 signed using EdDSA with Ed25519. 154 2.2. SHAKE 156 The SHA-3 family of hash functions is defined in FIPS Pub 202 157 [NIST.FIPS.202] and includes fixed output length variants SHA3-224, 158 SHA3-256, SHA3-384, and SHA3-512, as well as extendable-output 159 functions (SHAKEs) SHAKE128 and SHAKE256. Currently SHAKE128 and 160 SHAKE256 are the only members of the SHA3-family which are specified 161 for use in X.509 and PKIX [RFC8692], and CMS [RFC8702]. Therefore, 162 CMP specifies them as defined in RFC 8702 [RFC8702], which are 163 identified by the following OIDs: 165 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 166 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 167 hashalgs(2) 11 } 168 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 169 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 170 hashalgs(2) 12 } 172 Specific conventions to be considered are specified in RFC 8702 173 Section 3.1 [RFC8702]. 175 The hash algorithm used to calculate the certHash in certConf 176 messages MUST be SHAKE256 if the certificate to be confirmed has been 177 signed using EdDSA with Ed448. 179 3. Signature Algorithms 181 This section provides references to object identifiers and 182 conventions to be employed by CMP implementations that support RSA, 183 ECDSA, or EdDSA signature algorithms. 185 The signature algorithm is referred to as MSG_SIG_ALG in 186 Section 7.2,RFC 4210 Appendix D and E [RFC4210], and in the 187 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 189 Signature algorithm identifiers are located in the protectionAlg 190 field of PKIHeader, the algorithmIdentifier field of POPOSigningKey, 191 signatureAlgorithm field of CertificationRequest, SignKeyPairTypes, 192 and the SignerInfo signatureAlgorithm field of SignedData. 194 Signature values are located in the protection field of PKIMessage, 195 signature field of POPOSigningKey, signature field of 196 CertificationRequest, and SignerInfo signature field of SignedData. 198 3.1. RSA 200 The RSA (RSASSA-PSS and PKCS#1 version 1.5) signature algorithm is 201 defined in RFC 8017 [RFC8017]. 203 The algorithm identifiers for RSASAA-PSS signatures used with SHA2 204 message digest algorithms is identified by the following OID: 206 id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2) 207 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 } 209 Specific conventions to be considered are specified in RFC 4056 210 [RFC4056]. 212 The signature algorithm RSASSA-PSS used with SHAKE message digest 213 algorithms are identified by the following OIDs: 215 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) 216 identified-organization(3) dod(6) internet(1) security(5) 217 mechanisms(5) pkix(7) algorithms(6) 30 } 218 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) 219 identified-organization(3) dod(6) internet(1) security(5) 220 mechanisms(5) pkix(7) algorithms(6) 31 } 222 Specific conventions to be considered are specified in RFC 8702 223 Section 3.2.1 [RFC8702]. 225 The signature algorithm PKCS#1 version 1.5 used with SHA2 message 226 digest algorithms is identified by the following OIDs: 228 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 229 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } 230 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 231 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } 232 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 233 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } 234 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 235 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } 237 Specific conventions to be considered are specified in RFC 5754 238 Section 3.2 [RFC5754]. 240 3.2. ECDSA 242 The ECDSA signature algorithm is defined in FIPS Pub 186-4 243 [NIST.FIPS.186-4]. 245 The signature algorithm ECDSA used with SHA2 message digest 246 algorithms is identified by the following OIDs: 248 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 249 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } 250 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 251 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 252 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 253 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 254 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 255 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 257 As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves 258 are identified by the following OIDs: 260 secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 261 us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } 262 secp224r1 OBJECT IDENTIFIER ::= { iso(1) 263 identified-organization(3) certicom(132) curve(0) 33 } 264 secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 265 us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } 266 secp384r1 OBJECT IDENTIFIER ::= { iso(1) 267 identified-organization(3) certicom(132) curve(0) 34 } 268 secp521r1 OBJECT IDENTIFIER ::= { iso(1) 269 identified-organization(3) certicom(132) curve(0) 35 } 271 Specific conventions to be considered are specified in RFC 5754 272 Section 3.3 [RFC5754]. 274 The signature algorithm ECDSA used with SHAKE message digest 275 algorithms are identified by the following OIDs: 277 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) 278 identified-organization(3) dod(6) internet(1) security(5) 279 mechanisms(5) pkix(7) algorithms(6) 32 } 280 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) 281 identified-organization(3) dod(6) internet(1) security(5) 282 mechanisms(5) pkix(7) algorithms(6) 33 } 284 Specific conventions to be considered are specified in RFC 8702 285 Section 3.2.2 [RFC8702]. 287 3.3. EdDSA 289 The EdDSA signature algorithm is defined in RFC 8032 Section 3.3 290 [RFC8032] and FIPS Pub 186-5 (Draft) [NIST.FIPS.186-5]. 292 The signature algorithm Ed25519 MUST be used with SHA-512 message 293 digest algorithms is identified by the following OIDs: 295 id-Ed25519 OBJECT IDENTIFIER ::= { iso(1) 296 identified-organization(3) thawte(101) 112 } 298 The signature algorithm Ed448 MUST be used with SHAKE256 message 299 digest algorithms is identified by the following OIDs: 301 id-Ed448 OBJECT IDENTIFIER ::= { iso(1) 302 identified-organization(3) thawte(101) 113 } 304 Specific conventions to be considered are specified in RFC 8419 305 [RFC8419]. 307 Note: The hash algorithm used to calculate the certHash in certConf 308 messages MUST be SHA512 if the certificate to be confirmed has been 309 signed using Ed25519, see Section 2.1, and SHAKE256 if signed using 310 Ed448, see Section 2.2. 312 4. Key Management Algorithms 314 CMP utilizes the following general key management techniques: key 315 agreement, key transport, and passwords. 317 CRMF [RFC4211] and CMP Updates [I-D.ietf-lamps-cmp-updates] promotes 318 the use of CMS [RFC5652] EnvelopedData by deprecating the use of 319 EncryptedValue. 321 4.1. Key Agreement Algorithms 323 The key agreement algorithm is referred to as PROT_ENC_ALG in 324 RFC 4210 Appendix D and E [RFC4210] and as KM_KA_ALG in the 325 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as 326 well as in Section 7. 328 Key agreement algorithms are only used in CMP when using CMS 329 [RFC5652] EnvelopedData together with the key agreement key 330 management technique. When a key agreement algorithm is used, a key- 331 encryption algorithm (Section 4.3) is needed next to the content- 332 encryption algorithm (Section 5). 334 Key agreement algorithm identifiers are located in the EnvelopedData 335 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. 337 Key encryption algorithm identifiers are located in the EnvelopedData 338 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field. 340 Wrapped content-encryption keys are located in the EnvelopedData 341 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 342 encryptedKey field. 344 4.1.1. Diffie-Hellman 346 Diffie-Hellman key agreement is defined in RFC 2631 [RFC2631] and 347 SHALL be used in the ephemeral-static as specified in RFC 3370 348 [RFC3370]. Static-static variants SHALL NOT be used. 350 The Diffie-Hellman key agreement algorithm is identified by the 351 following OID: 353 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) 354 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 356 Specific conventions to be considered are specified in RFC 3370 357 Section 4.1 [RFC3370]. 359 4.1.2. ECDH 361 Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined in 362 RFC 5753 [RFC5753] and SHALL be used in the ephemeral-static variant 363 as specified in RFC 5753 [RFC5753] or the 1-Pass ECMQV variant as 364 specified in RFC 5753 [RFC5753]. Static-static variants SHALL NOT be 365 used. 367 The ECDH key agreement algorithm used together with NIST-recommended 368 SECP curves are identified by the following OIDs: 370 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 371 identified-organization(3) certicom(132) schemes(1) 11(11) 0 } 372 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 373 identified-organization(3) certicom(132) schemes(1) 11(11) 1 } 374 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 375 identified-organization(3) certicom(132) schemes(1) 11(11) 2 } 376 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 377 identified-organization(3) certicom(132) schemes(1) 11(11) 3 } 378 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 379 iso(1) identified-organization(3) certicom(132) schemes(1) 380 14(14) 0 } 381 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 382 iso(1) identified-organization(3) certicom(132) schemes(1) 383 14(14) 1 } 384 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 385 iso(1) identified-organization(3) certicom(132) schemes(1) 386 14(14) 2 } 387 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 388 iso(1) identified-organization(3) certicom(132) schemes(1) 389 14(14) 3 } 390 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 391 identified-organization(3) certicom(132) schemes(1) 15(15) 0 } 392 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 393 identified-organization(3) certicom(132) schemes(1) 15(15) 1 } 394 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 395 identified-organization(3) certicom(132) schemes(1) 15(15) 2 } 396 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 397 identified-organization(3) certicom(132) schemes(1) 15(15) 3 } 399 As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves 400 are identified by the following OIDs: 402 secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 403 us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } 404 secp224r1 OBJECT IDENTIFIER ::= { iso(1) 405 identified-organization(3) certicom(132) curve(0) 33 } 406 secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 407 us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } 408 secp384r1 OBJECT IDENTIFIER ::= { iso(1) 409 identified-organization(3) certicom(132) curve(0) 34 } 410 secp521r1 OBJECT IDENTIFIER ::= { iso(1) 411 identified-organization(3) certicom(132) curve(0) 35 } 413 Specific conventions to be considered are specified in RFC 5753 414 [RFC5753]. 416 The ECDH key agreement algorithm used together with curve25519 or 417 curve448 are identified by the following OIDs: 419 id-X25519 OBJECT IDENTIFIER ::= { iso(1) 420 identified-organization(3) thawte(101) 110 } 421 id-X448 OBJECT IDENTIFIER ::= { iso(1) 422 identified-organization(3) thawte(101) 111 } 424 Specific conventions to be considered are specified in RFC 8418 425 [RFC8418]. 427 4.2. Key Transport Algorithms 429 The key transport algorithm is also referred to as PROT_ENC_ALG in 430 RFC 4210 Appendix D and E [RFC4210] and as KM_KL_ALG in the 431 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as 432 well as in Section 7. 434 Key transport algorithms are only used in CMP when using CMS 435 [RFC5652] EnvelopedData together with the key transport key 436 management technique. 438 Key transport algorithm identifiers are located in the EnvelopedData 439 RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field. 441 Key transport encrypted content-encryption keys are located in the 442 EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey 443 field. 445 4.2.1. RSA 447 The RSA key transport algorithm is the RSA encryption scheme defined 448 in RFC 8017 [RFC8017]. 450 The algorithm identifier for RSA (PKCS #1 v1.5) is: 452 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 453 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 455 The algorithm identifier for RSAES-OAEP is: 457 id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) 458 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } 460 Further conventions to be considered for PKCS #1 v1.5 are specified 461 in RFC 3370 Section 4.2.1 [RFC3370] and for RSAES-OAEP in RFC 3560 462 [RFC3560]. 464 4.3. Symmetric Key-Encryption Algorithms 466 The symmetric key-encryption algorithm is also referred to as 467 KM_KW_ALG in Section 7.2 and in the Lightweight CMP Profile 468 [I-D.ietf-lamps-lightweight-cmp-profile]. 470 As symmetric key-encryption key management technique is not used by 471 CMP, the symmetric key-encryption algorithm is only needed when using 472 the key agreement or password-based key management technique with CMS 473 [RFC5652] EnvelopedData. 475 Key-encryption algorithm identifiers are located in the EnvelopedData 476 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 477 EnvelopedData RecipientInfos PasswordRecipientInfo 478 keyEncryptionAlgorithm fields. 480 Wrapped content-encryption keys are located in the EnvelopedData 481 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 482 encryptedKey and EnvelopedData RecipientInfos PasswordRecipientInfo 483 encryptedKey fields. 485 4.3.1. AES Key Wrap 487 The AES encryption algorithm is defined in FIPS Pub 197 488 [NIST.FIPS.197] and the key wrapping is defined in RFC 3394 489 [RFC3394]. 491 AES key encryption has the algorithm identifier: 493 id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 494 country(16) us(840) organization(1) gov(101) csor(3) 495 nistAlgorithm(4) aes(1) 5 } 496 id-aes192-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 497 country(16) us(840) organization(1) gov(101) csor(3) 498 nistAlgorithm(4) aes(1) 25 } 499 id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 500 country(16) us(840) organization(1) gov(101) csor(3) 501 nistAlgorithm(4) aes(1) 45 } 503 The underlying encryption functions for the key wrap and content- 504 encryption algorithms (as specified in Section 5) and the key sizes 505 for the two algorithms MUST be the same (e.g., AES-128 key wrap 506 algorithm with AES-128 content-encryption algorithm), see also 507 RFC 8551 [RFC8551]. 509 Further conventions to be considered for AES key wrap are specified 510 in RFC 3394 Section 2.2 [RFC3394] and RFC 3565 Section 2.3.2 511 [RFC3565]. 513 4.4. Key Derivation Algorithms 515 The key derivation algorithm is also referred to as KM_KD_ALG in 516 Section 7.2 and in the Lightweight CMP Profile 517 [I-D.ietf-lamps-lightweight-cmp-profile]. 519 Key derivation algorithms are only used in CMP when using CMS 520 [RFC5652] EnvelopedData together with password-based key management 521 technique. 523 Key derivation algorithm identifiers are located in the EnvelopedData 524 RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm field. 526 When using the password-based key management technique with 527 EnvelopedData as specified in CMP Updates together with MAC-based 528 PKIProtection, the salt for the password-based MAC and KDF must be 529 chosen independently to ensure usage of independent symmetric keys. 531 4.4.1. PBKDF2 533 The password-based key derivation function 2 (PBKDF2) is defined in 534 RFC 8018 [RFC8018]. 536 Password-based key derivation function 2 has the algorithm 537 identifier: 539 id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 540 rsadsi(113549) pkcs(1) pkcs-5(5) 12 } 542 Further conventions to be considered for PBKDF2 are specified in 543 RFC 3370 Section 4.4.1 [RFC3370] and RFC 8018 Section 5.2 [RFC8018]. 545 5. Content Encryption Algorithms 547 The content encryption algorithm is also referred to as PROT_SYM_ALG 548 in Section 7,RFC 4210 Appendix D and E [RFC4210], and the Lightweight 549 CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 551 Content encryption algorithms are only used in CMP when using CMS 552 [RFC5652] EnvelopedData to transport a signed private key package in 553 case of central key generation or key archiving, a certificate to 554 facilitate implicit proof-of-possession, or a revocation passphrase 555 in encrypted form. 557 Content encryption algorithm identifiers are located in the 558 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field. 560 Encrypted content is located in the EnvelopedData 561 EncryptedContentInfo encryptedContent field. 563 5.1. AES-CBC 565 The AES encryption algorithm is defined in FIPS Pub 197 566 [NIST.FIPS.197]. 568 AES-CBC content encryption has the algorithm identifier: 570 id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 571 country(16) us(840) organization(1) gov(101) csor(3) 572 nistAlgorithm(4) aes(1) 2 } 573 id-aes192-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 574 country(16) us(840) organization(1) gov(101) csor(3) 575 nistAlgorithm(4) aes(1)22 } 576 id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 577 country(16) us(840) organization(1) gov(101) csor(3) 578 nistAlgorithm(4) aes(1)42 } 580 Specific conventions to be considered for AES-CBC content encryption 581 are specified in RFC 3565 [RFC3565]. 583 6. Message Authentication Code Algorithms 585 The message authentication code is either used for shared secret- 586 based CMP message protection or together with the password-based key 587 derivation function (PBKDF2). 589 The message authentication code algorithm is also referred to as 590 MSG_MAC_ALG in Section 7,RFC 4210 Appendix D and E [RFC4210], and the 591 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 593 6.1. Password-based MAC 595 Password-based MAC algorithms combine the derivation of a symmetric 596 key from a password or other shared secret information and a 597 symmetric key-based MAC function as specified in Section 6.2 using 598 this derived key. 600 Message authentication code algorithm identifiers are located in the 601 protectionAlg field of PKIHeader. 603 Message authentication code values are located in the PKIProtection 604 field. 606 6.1.1. PasswordBasedMac 608 The PasswordBasedMac algorithm is defined in RFC 4210 Section 5.1.3.1 609 [RFC4210], RFC 4211 Section 4.4 [RFC4211], andAlgorithm Requirements 610 Update to the Internet X.509 Public Key Infrastructure Certificate 611 Request Message Format (CRMF) [RFC9045]. 613 The PasswordBasedMac algorithm is identified by the following OID: 615 id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 616 us(840) nt(113533) nsn(7) algorithms(66) 13 } 618 Further conventions to be considered for password-based MAC are 619 specified in RFC 4210 Section 5.1.3.1 [RFC4210], RFC 4211 Section 4.4 620 [RFC4211], and Algorithm Requirements Update to the Internet X.509 621 Public Key Infrastructure Certificate Request Message Format (CRMF) 622 [RFC9045]. 624 6.1.2. PBMAC1 626 The Password-Based Message Authentication Code 1 (PBMAC1) is defined 627 in RFC 8018 [RFC8018]. PBMAC1 combines a password-based key 628 derivation function like PBKDF2 (Section 4.4.1) with an underlying 629 symmetric key-based message authentication scheme. 631 PBMAC1 has the following OID: 633 id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 634 rsadsi(113549) pkcs(1) pkcs-5(5) 14 } 636 Specific conventions to be considered for PBMAC1 are specified in 637 RFC 8018 Section 7.1 and A.5 [RFC8018]. 639 6.2. Symmetric key-based MAC 641 Symmetric key-based MAC algorithms are used for deriving the 642 symmetric encryption key when using PBKDF2 as described in 643 Section 4.4.1 as well as with Password-based MAC as described in 644 Section 6.1. 646 Message authentication code algorithm identifiers are located in the 647 protectionAlg field of PKIHeader, the mac field of PBMParameter, the 648 messageAuthScheme field of PBMAC1, and the prf field of 649 PBKDF2-params. 651 Message authentication code values are located in the PKIProtection 652 field. 654 6.2.1. SHA2-based HMAC 656 The HMAC algorithm is defined in RFC 2104 [RFC2104] and 657 FIPS Pub 198-1 [NIST.FIPS.198-1]. 659 The HMAC algorithm used with SHA2 message digest algorithms is 660 identified by the following OIDs: 662 id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 663 us(840) rsadsi(113549) digestAlgorithm(2) 8 } 664 id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 665 us(840) rsadsi(113549) digestAlgorithm(2) 9 } 666 id-hmacWithSHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 667 us(840) rsadsi(113549) digestAlgorithm(2) 10 } 668 id-hmacWithSHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 669 us(840) rsadsi(113549) digestAlgorithm(2) 11 } 671 Specific conventions to be considered for SHA2-based HMAC are 672 specified in RFC 4231 Section 3.1 [RFC4231]. 674 6.2.2. AES-GMAC 676 The AES-GMAC algorithm is defined in FIPS Pub 197 [NIST.FIPS.197] and 677 NIST SP 800-38d [NIST.SP.800-38d]. 679 NOTE: AES-GMAC MUST NOT be used twice with the same parameter set, 680 especially the same nonce. Therefore, it MUST NOT be used together 681 with PBKDF2. When using it with PBMAC1 it MUST be ensured that AES- 682 GMAC is only used as message authentication scheme and not for the 683 key derivation function PBKDF2. 685 The AES-GMAC algorithm is identified by the following OIDs: 687 id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 688 country(16) us(840) organization(1) gov(101) csor(3) 689 nistAlgorithm(4) aes(1) 9 } 690 id-aes192-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 691 country(16) us(840) organization(1) gov(101) csor(3) 692 nistAlgorithm(4) aes(1) 29 } 693 id-aes256-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 694 country(16) us(840) organization(1) gov(101) csor(3) 695 nistAlgorithm(4) aes(1) 49 } 697 Specific conventions to be considered for AES-GMAC are specified in 698 RFC 9044 [RFC9044]. 700 6.2.3. SHAKE-based KMAC 702 The KMAC algorithm is defined in RFC 8702 [RFC8702] and 703 FIPS SP 800-185 [NIST.SP.800-185]. 705 The SHAKE-based KMAC algorithm is identified by the following OIDs: 707 id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 708 country(16) us(840) organization(1) gov(101) csor(3) 709 nistAlgorithm(4) 2 19 } 710 id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 711 country(16) us(840) organization(1) gov(101) csor(3) 712 nistAlgorithm(4) 2 20 } 714 Specific conventions to be considered for KMAC with SHAKE are 715 specified in RFC 8702 Section 3.4 [RFC8702]. 717 7. Algorithm Use Profiles 719 This section provides profiles of algorithms and respective 720 conventions for different application use cases. 722 Recommendations like NIST SP 800-57 Recommendation for Key Management 723 [NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and Protocols 724 Report (2018) [ECRYPT.CSA.D5.4] provide general information on 725 current cryptographic algorithms. 727 The following criteria will help implementers choose appropriate 728 algorithms for managing certificates: 730 * The cryptographic strength of the algorithm with the lowest 731 security. 733 Note: To avoid consuming too much computational resources it is 734 recommended to choose a set of algorithms offering roughly the 735 same level of security. 737 * The entropy of the shared secret information or password when MAC- 738 based message protection is used, e.g., MSG_MAC_ALG. 740 Finally, the cryptographic strength of the system SHOULD be at least 741 as strong as the algorithms and keys used for the certificate being 742 managed. 744 7.1. Algorithm Profile for RFC 4210 PKI Management Message Profiles 746 The following table contains definitions of algorithms used within 747 PKI Management Message Profiles as defined in CMP Appendix D.2 748 [RFC4210]. 750 The columns in the table are: 752 Name: An identifier used for message profiles 754 Use: Description of where and for what the algorithm is used 756 Mandatory: Algorithms which MUST be supported by conforming 757 implementations 759 Change from 4210: Shows the changes in the Mandatory and Other 760 algorithms from RFC 4210 [RFC4210]. These are included for backwards 761 compatibility considerations. 763 +============+===============+==================+===================+ 764 |Name |Use | Mandatory |Change from 4210 | 765 +============+===============+==================+===================+ 766 |MSG_SIG_ALG |protection of | RSA |DSA/SHA1 | 767 | |PKI messages | |Others: RSA/MD5, | 768 | |using signature| |ECDSA | 769 +------------+---------------+------------------+-------------------+ 770 |MSG_MAC_ALG |protection of | PasswordBasedMac |PasswordBasedMac | 771 | |PKI messages | (RECOMMENDED: |Others: HMAC, X9.9 | 772 | |using MACing | PBMAC1) | | 773 +------------+---------------+------------------+-------------------+ 774 |SYM_PENC_ALG|symmetric | AES-wrap |3-DES(3-key-EDE), | 775 | |encryption of | |CBC Mode | 776 | |an end entity's| |Others: AES, RC5, | 777 | |private key | |CAST-128 | 778 | |where symmetric| | | 779 | |key is | | | 780 | |distributed | | | 781 | |out-of-band | | | 782 +------------+---------------+------------------+-------------------+ 783 |PROT_ENC_ALG|asymmetric | D-H |D-H | 784 | |algorithm used | |Others: RSA, ECDH | 785 | |for encryption | | | 786 | |of (symmetric | | | 787 | |keys for | | | 788 | |encryption of) | | | 789 | |private keys | | | 790 | |transported in | | | 791 | |PKIMessages | | | 792 +------------+---------------+------------------+-------------------+ 793 |PROT_SYM_ALG|symmetric | AES-CBC |3-DES(3-key-EDE), | 794 | |encryption | |CBC Mode | 795 | |algorithm used | |Others: AES, RC5, | 796 | |for encryption | |CAST-128 | 797 | |of private key | | | 798 | |bits (a key of | | | 799 | |this type is | | | 800 | |encrypted using| | | 801 | |PROT_ENC_ALG) | | | 802 +------------+---------------+------------------+-------------------+ 804 Table 1 806 Mandatory Algorithm Identifiers and Specifications: 808 RSA: sha256WithRSAEncryption with 2048 bit, see Section 3.1 809 PasswordBasedMac: id-PasswordBasedMac, see Section 6.1 (with id- 810 sha256 as the owf parameter, see Section 2.1 and id-hmacWithSHA256 as 811 the mac parameter, see Section 6.2.1) 813 PBMAC1: id-PBMAC1, see Section 6.1.2 (with id-PBKDF2 as the key 814 derivation function, see Section 4.4.1 and id-hmacWithSHA256 as 815 message authentication scheme, see Section 6.2.1). It is RECOMMENDED 816 to prefer the usage of PBMAC1 instead of PasswordBasedMac. 818 D-H: id-alg-ESDH, see Section 4.1.1 820 AES-wrap: id-aes256-wrap, see Section 4.3.1 822 AES-CBC: id-aes256-CBC, see Section 5.1 824 7.2. Algorithm Profile for Lightweight CMP Profile 826 The following table contains definitions of algorithms which MAY be 827 supported by implementations of the Lightweight CMP Profile 828 [I-D.ietf-lamps-lightweight-cmp-profile]. 830 As the set of algorithms to be used for implementations of the 831 Lightweight CMP Profile heavily depends on the PKI management 832 operations implemented, the certificates used for messages 833 protection, and the certificates to be managed, this document will 834 not specify a specific set that is mandatory to support for 835 conforming implementations. 837 The columns in the table are: 839 Name: An identifier used for message profiles 841 Use: Description of where and for what the algorithm is used 843 Examples: Lists the algorithms as described in this document. The 844 list of algorithms depends on the set of PKI management operations to 845 be implemented. 847 Note: It is RECOMMENDED to prefer the usage of PBMAC1 instead of 848 PasswordBasedMac. 850 +==============+================================+==================+ 851 | Name | Use | Examples | 852 +==============+================================+==================+ 853 | MSG_SIG_ALG | protection of PKI messages | RSA, ECDSA, | 854 | | using signature and for | EdDSA | 855 | | SignedData, e.g., a private | | 856 | | key transported in PKIMessages | | 857 +--------------+--------------------------------+------------------+ 858 | MSG_MAC_ALG | protection of PKI messages | PasswordBasedMac | 859 | | using MACing | (see Section 9), | 860 | | | PBMAC1 | 861 +--------------+--------------------------------+------------------+ 862 | KM_KA_ALG | asymmetric key agreement | D-H, ECDH | 863 | | algorithm used for agreement | | 864 | | of a symmetric key for use | | 865 | | with KM_KW_ALG | | 866 +--------------+--------------------------------+------------------+ 867 | KM_KT_ALG | asymmetric key encryption | RSA | 868 | | algorithm used for transport | | 869 | | of a symmetric key for | | 870 | | PROT_SYM_ALG | | 871 +--------------+--------------------------------+------------------+ 872 | KM_KD_ALG | symmetric key derivation | PBKDF2 | 873 | | algorithm used for derivation | | 874 | | of a symmetric key for use | | 875 | | with KM_KW_ALG | | 876 +--------------+--------------------------------+------------------+ 877 | KM_KW_ALG | algorithm to wrap a symmetric | AES-wrap | 878 | | key for PROT_SYM_ALG | | 879 +--------------+--------------------------------+------------------+ 880 | PROT_SYM_ALG | symmetric content encryption | AES-CBC | 881 | | algorithm used for encryption | | 882 | | of EnvelopedData, e.g., a | | 883 | | private key transported in | | 884 | | PKIMessages | | 885 +--------------+--------------------------------+------------------+ 887 Table 2 889 8. IANA Considerations 891 This document does not request changes to the IANA registry. 893 9. Security Considerations 895 RFC 4210 Appendix D.2 [RFC4210] contains a set of algorithms, 896 mandatory to be supported by conforming implementations. Theses 897 algorithms were appropriate at the time CMP was released, but as 898 cryptographic algorithms weaken over time, some of them should not be 899 used anymore. In general, new attacks are emerging due to research 900 cryptoanalysis or increase in computing power. New algorithms were 901 introduced that are more resistant to today's attacks. 903 This document lists many cryptographic algorithms usable with CMP to 904 offer implementers a more up to date choice. Finally, the algorithms 905 to be supported also heavily depend on the certificates and PKI 906 management operations utilized in the target environment. The 907 algorithm with the lowest security strength and the entropy of shared 908 secret information define the security of the overall solution, see 909 Section 7. 911 When using MAC-based message protection the use of PBMAC1 is 912 preferable to that of PasswordBasedMac: first, PBMAC1 is a well-known 913 scrutinized algorithm, which is not true for PasswordBasedMac and 914 second, there exists a theoretical weakness in PasswordBasedMac, 915 where the generated MAC key can be easily distinguished from a random 916 key. 918 AES-GMAC MUST NOT be used as the pseudo random function in PBKDF2; 919 the use of AES-GMAC more than once with the same key and the same 920 nonce will break the security. 922 In Section 7 of this document there is also an update to the 923 Appendix D.2 of RFC 4210 [RFC4210] and a set of algorithms that MAY 924 be supported when implementing the Lightweight CMP Profile 925 [I-D.ietf-lamps-lightweight-cmp-profile]. 927 To keep the list of algorithms to be used with CMP up to date and to 928 enlist secure algorithms resisting known attack scenarios, future 929 algorithms should be added and weakened algorithms should be 930 deprecated. 932 It is recognized that there may be older CMP implementations in use 933 that conform to the algorithm use profile from Appendix D.2 of 934 RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for 935 PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory. In most 936 cases the newer mandatory algorithms were listed as "other" 937 algorithms in RFC 4210 [RFC4210]. Therefore, it is expected that 938 many CMP systems may already support the recommended algorithms in 939 this specification. In such systems the weakened algorithms should 940 be disabled from further use. If critical systems cannot be 941 immediately updated to conform to the recommended algorithm use 942 profile, it is recommended a plan to migrate the infrastructure to 943 conforming profiles be adopted as soon as possible. 945 10. Acknowledgements 947 Thanks to Russ Housley for supporting this draft with submitting 948 [RFC9044] and [RFC9045]. 950 May thanks also to all reviewers like Serge Mister, Mark Ferreira, 951 Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steffen 952 Fries for their input and feedback to this document. Apologies to 953 all not mentioned reviewers and supporters. 955 11. Normative References 957 [I-D.ietf-lamps-cmp-updates] 958 Brockhaus, H. and D. V. Oheimb, "Certificate Management 959 Protocol (CMP) Updates", Work in Progress, Internet-Draft, 960 draft-ietf-lamps-cmp-updates-12, 9 July 2021, 961 . 964 [NIST.FIPS.180-4] 965 Dang, Quynh H., "Secure Hash Standard", NIST NIST FIPS 966 180-4, DOI 10.6028/NIST.FIPS.180-4, July 2015, 967 . 970 [NIST.FIPS.186-4] 971 National Institute of Standards and Technology (NIST), 972 "Digital Signature Standard (DSS)", NIST NIST FIPS 186-4, 973 DOI 10.6028/NIST.FIPS.186-4, July 2013, 974 . 977 [NIST.FIPS.186-5] 978 National Institute of Standards and Technology (NIST), 979 "FIPS Pub 186-5 (Draft): Digital Signature Standard 980 (DSS)", October 2019, 981 . 984 [NIST.FIPS.197] 985 National Institute of Standards and Technology (NIST), 986 "Advanced encryption standard (AES)", NIST NIST FIPS 197, 987 DOI 10.6028/NIST.FIPS.197, November 2001, 988 . 991 [NIST.FIPS.198-1] 992 National Institute of Standards and Technology (NIST), 993 "The Keyed-Hash Message Authentication Code (HMAC)", 994 NIST NIST FIPS 198-1, DOI 10.6028/NIST.FIPS.198-1, July 995 2008, . 998 [NIST.FIPS.202] 999 Dworkin, Morris J., "SHA-3 Standard: Permutation-Based 1000 Hash and Extendable-Output Functions", NIST NIST FIPS 202, 1001 DOI 10.6028/NIST.FIPS.202, July 2015, 1002 . 1005 [NIST.SP.800-185] 1006 Kelsey, John., Change, Shu-jen., and Ray. Perlner, "SHA-3 1007 derived functions: cSHAKE, KMAC, TupleHash and 1008 ParallelHash", NIST NIST SP 800-185, 1009 DOI 10.6028/NIST.SP.800-185, December 2016, 1010 . 1013 [NIST.SP.800-38d] 1014 Dworkin, M J., "Recommendation for block cipher modes of 1015 operation :GaloisCounter Mode (GCM) and GMAC", NIST NIST 1016 SP 800-38d, DOI 10.6028/NIST.SP.800-38d, 2007, 1017 . 1020 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1021 Hashing for Message Authentication", RFC 2104, 1022 DOI 10.17487/RFC2104, February 1997, 1023 . 1025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1026 Requirement Levels", BCP 14, RFC 2119, 1027 DOI 10.17487/RFC2119, March 1997, 1028 . 1030 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1031 RFC 2631, DOI 10.17487/RFC2631, June 1999, 1032 . 1034 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1035 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 1036 . 1038 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1039 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 1040 September 2002, . 1042 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport 1043 Algorithm in Cryptographic Message Syntax (CMS)", 1044 RFC 3560, DOI 10.17487/RFC3560, July 2003, 1045 . 1047 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1048 Encryption Algorithm in Cryptographic Message Syntax 1049 (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, 1050 . 1052 [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in 1053 Cryptographic Message Syntax (CMS)", RFC 4056, 1054 DOI 10.17487/RFC4056, June 2005, 1055 . 1057 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1058 "Internet X.509 Public Key Infrastructure Certificate 1059 Management Protocol (CMP)", RFC 4210, 1060 DOI 10.17487/RFC4210, September 2005, 1061 . 1063 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1064 Certificate Request Message Format (CRMF)", RFC 4211, 1065 DOI 10.17487/RFC4211, September 2005, 1066 . 1068 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 1069 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 1070 RFC 4231, DOI 10.17487/RFC4231, December 2005, 1071 . 1073 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1074 "Elliptic Curve Cryptography Subject Public Key 1075 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 1076 . 1078 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1079 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1080 . 1082 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 1083 Cryptography (ECC) Algorithms in Cryptographic Message 1084 Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 1085 2010, . 1087 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 1088 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 1089 2010, . 1091 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1092 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1093 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1094 . 1096 [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: 1097 Password-Based Cryptography Specification Version 2.1", 1098 RFC 8018, DOI 10.17487/RFC8018, January 2017, 1099 . 1101 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1102 Signature Algorithm (EdDSA)", RFC 8032, 1103 DOI 10.17487/RFC8032, January 2017, 1104 . 1106 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1107 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1108 May 2017, . 1110 [RFC8418] Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key 1111 Agreement Algorithm with X25519 and X448 in the 1112 Cryptographic Message Syntax (CMS)", RFC 8418, 1113 DOI 10.17487/RFC8418, August 2018, 1114 . 1116 [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature 1117 Algorithm (EdDSA) Signatures in the Cryptographic Message 1118 Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 1119 2018, . 1121 [RFC8702] Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash 1122 Functions in the Cryptographic Message Syntax (CMS)", 1123 RFC 8702, DOI 10.17487/RFC8702, January 2020, 1124 . 1126 [RFC9044] Housley, R., "Using the AES-GMAC Algorithm with the 1127 Cryptographic Message Syntax (CMS)", RFC 9044, 1128 DOI 10.17487/RFC9044, June 2021, 1129 . 1131 [RFC9045] Housley, R., "Algorithm Requirements Update to the 1132 Internet X.509 Public Key Infrastructure Certificate 1133 Request Message Format (CRMF)", RFC 9045, 1134 DOI 10.17487/RFC9045, June 2021, 1135 . 1137 12. Informative References 1139 [ECRYPT.CSA.D5.4] 1140 University of Bristol, "Algorithms, Key Size and Protocols 1141 Report (2018)", March 2015, 1142 . 1145 [I-D.ietf-lamps-lightweight-cmp-profile] 1146 Brockhaus, H., Fries, S., and D. V. Oheimb, "Lightweight 1147 Certificate Management Protocol (CMP) Profile", Work in 1148 Progress, Internet-Draft, draft-ietf-lamps-lightweight- 1149 cmp-profile-06, 9 July 2021, 1150 . 1153 [NIST.SP.800-57pt1r5] 1154 Barker, Elaine., "Recommendation for key management:part 1 1155 - general", NIST NIST SP 800-57pt1r5, 1156 DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, 1157 . 1160 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1161 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1162 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 1163 April 2019, . 1165 [RFC8692] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key 1166 Infrastructure: Additional Algorithm Identifiers for 1167 RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, 1168 DOI 10.17487/RFC8692, December 2019, 1169 . 1171 Appendix A. History of changes 1173 Note: This appendix will be deleted in the final version of the 1174 document. 1176 From version 06 -> 07: 1178 * Fixing minor formatting nits 1180 From version 05 -> 06: 1182 * Added text to Section 2 and Section 3.3 to clearly specify the 1183 hash algorithm to use for certConf messages for certificates 1184 signed with EdDSA (see thread "[CMP Updates] Hash algorithm to us 1185 for calculating certHash") 1186 * Updated new RFC numbers for I-D.ietf-lamps-cms-aes-gmac-alg and I- 1187 D.ietf-lamps-crmf-update-algs 1189 From version 04 -> 05: 1191 * Minor changes and corrections in wording 1193 From version 03 -> 04: 1195 * Added John Gray to the list of authors due to his extensive 1196 support and valuable feedback 1197 * Added some clarification of the use AES-GMAC to Section 6.2.1 1198 * Extended the guidance on how to select a set of algorithms in 1199 Section 7 and deleted former Section 7.1 1200 * Deleted the algorithms mandatory to support in Section 7.2 as 1201 discussed at IETF 110 1202 * Extended the Security considerations in Section 9 1203 * Minor changes in wording 1205 From version 02 -> 03: 1207 * Moved former Appendix A to new Section 7 as suggested by Rich and 1208 Russ (see thread "I-D Action: draft-ietf-lamps-cmp-algorithms- 1209 02.txt") 1210 * Added a column to Table 1 in Section 7.2 to reflect the changes to 1211 RFC 4210 1212 * Updated Table 2 in Section 7.3 1213 * Added a paragraph to Section 9 to discuss backward compatibility 1214 with RFC 4210 1215 * Minor changes in wording 1217 From version 01 -> 02: 1219 * Added Hans Aschauer, Mike Ounsworth, and Serge Mister as co-author 1220 * Changed to XML V3 1221 * Added SHAKE digest algorithm to Section 2 as discussed at IETF 109 1222 * Deleted DSA from Section 3 as discussed at IETF 109 1223 * Added RSASSA-PSS with SHAKE to Section 3 1224 * Added SECP curves the section on ECDSA with SHA2, ECDSA with 1225 SHAKE, and EdDSA to Section 3 as discussed at IETF 109 1226 * Deleted static-static D-H and ECDH from Section 4.1 based on the 1227 discussion on the mailing list (see thread "[CMP Algorithms] 1228 Section 4.1.1 and 4.1.2 drop static-static (EC)DH key agreement 1229 algorithms for use in CMP") 1230 * Added ECDH OIDs and SECP curves, as well as ECDH with curve25519 1231 and curve448 to Section 4.1 as discussed at IETF 109 1232 * Deleted RSA-OAEP from Section 4.2 first as discussed at IETF 109, 1233 but re-added it after discussion on the mailing list (see thread 1234 "Mail regarding draft-ietf-lamps-cmp-algorithms") 1235 * Added a paragraph to Section 4.3.1 to explain that the algorithms 1236 and key length for content encryption and key wrapping must be 1237 aligned as discussed on the mailing list (see thread "[CMP 1238 Algorithms] Use Key-Wrap with or without padding in Section 4.3 1239 and Section 5") 1240 * Deleted AES-CCM and AES-GMC from and added AES-CBC to Section 5 as 1241 discussed at IETF 109 1242 * Added Section 6.1.2 to offer PBMAC1 as discusses on the mailing 1243 list (see thread "Mail regarding draft-ietf-lamps-crmf-update- 1244 algs-02") and restructured text in Section 6 to be easier to 1245 differentiate between password- and shared-key-based MAC 1246 * Deleted Diffie-Hellmann based MAC from Section 6 as is only 1247 relevant when using enrolling Diffie-Hellmann certificates 1248 * Added AES-GMAC and SHAKE-based KMAC to Section 6 as discussed at 1249 IETF 109 1250 * Extended Section 9 to mention Russ supporting with two additional 1251 I-Ds and name further supporters of the draft 1252 * Added a first draft of a generic algorithm selection guideline to 1253 Appendix A 1254 * Added a first proposal for mandatory algorithms for the 1255 Lightweight CMP Profile to Appendix A 1256 * Minor changes in wording 1258 From version 00 -> 01: 1260 * Changed sections Symmetric Key-Encryption Algorithms and Content 1261 Encryption Algorithms based on the discussion on the mailing list 1262 (see thread "[CMP Algorithms] Use Key-Wrap with or without padding 1263 in Section 4.3 and Section 5") 1264 * Added Appendix A with updated algorithms profile for RDC4210 1265 Appendix D.2 and first proposal for the Lightweight CMP Profile 1266 * Minor changes in wording 1268 Authors' Addresses 1270 Hendrik Brockhaus (editor) 1271 Siemens AG 1273 Email: hendrik.brockhaus@siemens.com 1275 Hans Aschauer 1276 Siemens AG 1278 Email: hans.aschauer@siemens.com 1280 Mike Ounsworth 1281 Entrust 1283 Email: mike.ounsworth@entrust.com 1285 John Gray 1286 Entrust 1288 Email: john.gray@entrust.com