idnits 2.17.1 draft-ietf-lamps-cmp-algorithms-14.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 directly say this. It does mention RFC4210 though, so this could be OK. 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 (25 May 2022) is 692 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-19 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-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 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: 26 November 2022 J. Gray 7 Entrust 8 25 May 2022 10 Certificate Management Protocol (CMP) Algorithms 11 draft-ietf-lamps-cmp-algorithms-14 13 Abstract 15 This document describes the conventions for using several 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. This document also updates the algorithm use 19 profile from RFC 4210 Appendix D.2. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 26 November 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Message Digest Algorithms . . . . . . . . . . . . . . . . . . 3 57 2.1. SHA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5 60 3.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.3. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4. Key Management Algorithms . . . . . . . . . . . . . . . . . . 7 64 4.1. Key Agreement Algorithms . . . . . . . . . . . . . . . . 8 65 4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 8 66 4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 10 68 4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.3. Symmetric Key-Encryption Algorithms . . . . . . . . . . . 11 70 4.3.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 11 71 4.4. Key Derivation Algorithms . . . . . . . . . . . . . . . . 12 72 4.4.1. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . 12 73 5. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12 74 5.1. AES-CBC . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 6. Message Authentication Code Algorithms . . . . . . . . . . . 13 76 6.1. Password-Based MAC . . . . . . . . . . . . . . . . . . . 13 77 6.1.1. PasswordBasedMac . . . . . . . . . . . . . . . . . . 14 78 6.1.2. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . 14 79 6.2. Symmetric Key-Based MAC . . . . . . . . . . . . . . . . . 14 80 6.2.1. SHA2-Based HMAC . . . . . . . . . . . . . . . . . . . 15 81 6.2.2. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . 15 82 6.2.3. SHAKE-Based KMAC . . . . . . . . . . . . . . . . . . 16 83 7. Algorithm Use Profiles . . . . . . . . . . . . . . . . . . . 16 84 7.1. Algorithm Profile for RFC 4210 PKI Management Message 85 Profiles . . . . . . . . . . . . . . . . . . . . . . . . 19 86 7.2. Algorithm Profile for Lightweight CMP Profile . . . . . . 21 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 90 11. Normative References . . . . . . . . . . . . . . . . . . . . 24 91 12. Informative References . . . . . . . . . . . . . . . . . . . 28 92 Appendix A. History of Changes . . . . . . . . . . . . . . . . . 29 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 95 1. Introduction 97 1.1. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 In the following sections ASN.1 values and types are used to indicate 106 where algorithm identifier and output values are provided. These 107 ASN.1 values and types are defined in CMP [RFC4210], CRMF [RFC4211], 108 CMP Updates [I-D.ietf-lamps-cmp-updates], or CMS [RFC5652]. 110 2. Message Digest Algorithms 112 This section provides references to object identifiers and 113 conventions to be employed by CMP implementations that support SHA2 114 or SHAKE message digest algorithms. 116 Digest algorithm identifiers are located in: 118 * hashAlg field of OOBCertHash and CertStatus 119 * owf field of Challenge, PBMParameter, and DHBMParameter 120 * digestAlgorithms field of SignedData 121 * digestAlgorithm field of SignerInfo 123 Digest values are located in: 125 * hashVal field of OOBCertHash 126 * certHash field of CertStatus 127 * witness field of Challenge 129 In addition, digest values are input to signature algorithms. 131 2.1. SHA2 133 The SHA2 algorithm family is defined in FIPS Pub 180-4 134 [NIST.FIPS.180-4]. 136 The message digest algorithms SHA-224, SHA-256, SHA-384, and SHA-512 137 are identified by the following OIDs: 139 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 140 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 141 hashalgs(2) 4 } 142 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 143 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 144 hashalgs(2) 1 } 145 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 146 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 147 hashalgs(2) 2 } 148 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 149 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 150 hashalgs(2) 3 } 152 Specific conventions to be considered are specified in RFC 5754 153 Section 2 [RFC5754]. 155 2.2. SHAKE 157 The SHA-3 family of hash functions is defined in FIPS Pub 202 158 [NIST.FIPS.202] and includes fixed output length variants SHA3-224, 159 SHA3-256, SHA3-384, and SHA3-512, as well as extendable-output 160 functions (SHAKEs) SHAKE128 and SHAKE256. Currently, SHAKE128 and 161 SHAKE256 are the only members of the SHA3-family which are specified 162 for use in X.509 certificates [RFC8692] and CMS [RFC8702] as one-way 163 hash function for use with RSASSA-PSS and ECDSA. 165 SHAKE is an extendable-output function and FIPS Pub 202 166 [NIST.FIPS.202] prohibits using SHAKE as general-purpose hash 167 function. When SHAKE is used in CMP as a message digest algorithm, 168 the output length MUST be 256 bits for SHAKE128 and 512 bits for 169 SHAKE256. 171 The message digest algorithms SHAKE128 and SHAKE256 are identified by 172 the following OIDs: 174 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 175 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 176 hashalgs(2) 11 } 177 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 178 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 179 hashalgs(2) 12 } 181 Specific conventions to be considered are specified in RFC 8702 182 Section 3.1 [RFC8702]. 184 3. Signature Algorithms 186 This section provides references to object identifiers and 187 conventions to be employed by CMP implementations that support RSA, 188 ECDSA, or EdDSA signature algorithms. 190 The signature algorithm is referred to as MSG_SIG_ALG in Section 7.2, 191 RFC 4210 Appendix D and E [RFC4210], and in the Lightweight CMP 192 Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 194 Signature algorithm identifiers are located in: 196 * protectionAlg field of PKIHeader 197 * algorithmIdentifier field of POPOSigningKey 198 * signatureAlgorithm field of CertificationRequest, 199 SignKeyPairTypes, and SignerInfo 201 Signature values are located in: 203 * protection field of PKIMessage 204 * signature field of POPOSigningKey 205 * signature field of CertificationRequest and SignerInfo 207 3.1. RSA 209 The RSA (RSASSA-PSS and PKCS#1 version 1.5) signature algorithm is 210 defined in RFC 8017 [RFC8017]. 212 The algorithm identifier for RSASAA-PSS signatures used with SHA2 213 message digest algorithms is identified by the following OID: 215 id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2) 216 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 } 218 Specific conventions to be considered are specified in RFC 4056 219 [RFC4056]. 221 The signature algorithm RSASSA-PSS used with SHAKE message digest 222 algorithms are identified by the following OIDs: 224 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) 225 identified-organization(3) dod(6) internet(1) security(5) 226 mechanisms(5) pkix(7) algorithms(6) 30 } 227 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) 228 identified-organization(3) dod(6) internet(1) security(5) 229 mechanisms(5) pkix(7) algorithms(6) 31 } 231 Specific conventions to be considered are specified in RFC 8702 232 Section 3.2.1 [RFC8702]. 234 The signature algorithm PKCS#1 version 1.5 used with SHA2 message 235 digest algorithms is identified by the following OIDs: 237 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 238 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } 239 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 240 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } 241 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 242 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } 243 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 244 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } 246 Specific conventions to be considered are specified in RFC 5754 247 Section 3.2 [RFC5754]. 249 3.2. ECDSA 251 The ECDSA signature algorithm is defined in FIPS Pub 186-4 252 [NIST.FIPS.186-4]. 254 The signature algorithm ECDSA used with SHA2 message digest 255 algorithms is identified by the following OIDs: 257 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 258 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } 259 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 260 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 261 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 262 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 263 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 264 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 266 As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves 267 are identified by the following OIDs: 269 secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 270 us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } 271 secp224r1 OBJECT IDENTIFIER ::= { iso(1) 272 identified-organization(3) certicom(132) curve(0) 33 } 273 secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 274 us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } 275 secp384r1 OBJECT IDENTIFIER ::= { iso(1) 276 identified-organization(3) certicom(132) curve(0) 34 } 277 secp521r1 OBJECT IDENTIFIER ::= { iso(1) 278 identified-organization(3) certicom(132) curve(0) 35 } 280 Specific conventions to be considered are specified in RFC 5754 281 Section 3.3 [RFC5754]. 283 The signature algorithm ECDSA used with SHAKE message digest 284 algorithms are identified by the following OIDs: 286 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) 287 identified-organization(3) dod(6) internet(1) security(5) 288 mechanisms(5) pkix(7) algorithms(6) 32 } 289 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) 290 identified-organization(3) dod(6) internet(1) security(5) 291 mechanisms(5) pkix(7) algorithms(6) 33 } 293 Specific conventions to be considered are specified in RFC 8702 294 Section 3.2.2 [RFC8702]. 296 3.3. EdDSA 298 The EdDSA signature algorithm is defined in RFC 8032 Section 3.3 299 [RFC8032] and FIPS Pub 186-5 (Draft) [NIST.FIPS.186-5]. 301 The signature algorithm Ed25519 that MUST be used with SHA-512 302 message digest algorithms is identified by the following OIDs: 304 id-Ed25519 OBJECT IDENTIFIER ::= { iso(1) 305 identified-organization(3) thawte(101) 112 } 307 The signature algorithm Ed448 that MUST be used with SHAKE256 message 308 digest algorithms is identified by the following OIDs: 310 id-Ed448 OBJECT IDENTIFIER ::= { iso(1) 311 identified-organization(3) thawte(101) 113 } 313 Specific conventions to be considered are specified in RFC 8419 314 [RFC8419]. 316 Note: The hash algorithm used to calculate the certHash in certConf 317 messages MUST be SHA512 if the certificate to be confirmed has been 318 signed using Ed25519 and SHAKE256 with d=512 if signed using Ed448. 320 4. Key Management Algorithms 322 CMP utilizes the following general key management techniques: key 323 agreement, key transport, and passwords. 325 CRMF [RFC4211] and CMP Updates [I-D.ietf-lamps-cmp-updates] promotes 326 the use of CMS [RFC5652] EnvelopedData by deprecating the use of 327 EncryptedValue. 329 4.1. Key Agreement Algorithms 331 The key agreement algorithm is referred to as PROT_ENC_ALG in 332 RFC 4210 Appendix D and E [RFC4210] and as KM_KA_ALG in the 333 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as 334 well as in Section 7. 336 Key agreement algorithms are only used in CMP when using CMS 337 [RFC5652] EnvelopedData together with the key agreement key 338 management technique. When a key agreement algorithm is used, a key- 339 encryption algorithm (Section 4.3) is needed next to the content- 340 encryption algorithm (Section 5). 342 Key agreement algorithm identifiers are located in: 344 * keyEncryptionAlgorithm field of KeyAgreeRecipientInfo 346 Key wrap algorithm identifiers are located in: 348 * KeyWrapAlgorithm parameters within keyEncryptionAlgorithm field of 349 KeyAgreeRecipientInfo 351 Wrapped content-encryption keys are located in: 353 * encryptedKey field of RecipientEncryptedKeys 355 4.1.1. Diffie-Hellman 357 Diffie-Hellman key agreement is defined in RFC 2631 [RFC2631] and 358 SHALL be used in the ephemeral-static as specified in RFC 3370 359 [RFC3370]. Static-static variants SHALL NOT be used. 361 The Diffie-Hellman key agreement algorithm is identified by the 362 following OID: 364 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) 365 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 367 Specific conventions to be considered are specified in RFC 3370 368 Section 4.1 [RFC3370]. 370 4.1.2. ECDH 372 Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined in 373 RFC 5753 [RFC5753] and SHALL be used in the ephemeral-static variant 374 as specified in RFC 5753 [RFC5753] or the 1-Pass ECMQV variant as 375 specified in RFC 5753 [RFC5753]. Static-static variants SHALL NOT be 376 used. 378 The ECDH key agreement algorithm used together with NIST-recommended 379 SECP curves are identified by the following OIDs: 381 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 382 identified-organization(3) certicom(132) schemes(1) 11(11) 0 } 383 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 384 identified-organization(3) certicom(132) schemes(1) 11(11) 1 } 385 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 386 identified-organization(3) certicom(132) schemes(1) 11(11) 2 } 387 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 388 identified-organization(3) certicom(132) schemes(1) 11(11) 3 } 389 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 390 iso(1) identified-organization(3) certicom(132) schemes(1) 391 14(14) 0 } 392 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 393 iso(1) identified-organization(3) certicom(132) schemes(1) 394 14(14) 1 } 395 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 396 iso(1) identified-organization(3) certicom(132) schemes(1) 397 14(14) 2 } 398 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 399 iso(1) identified-organization(3) certicom(132) schemes(1) 400 14(14) 3 } 401 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 402 identified-organization(3) certicom(132) schemes(1) 15(15) 0 } 403 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 404 identified-organization(3) certicom(132) schemes(1) 15(15) 1 } 405 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 406 identified-organization(3) certicom(132) schemes(1) 15(15) 2 } 407 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 408 identified-organization(3) certicom(132) schemes(1) 15(15) 3 } 410 As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves 411 are identified by the following OIDs: 413 secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 414 us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } 415 secp224r1 OBJECT IDENTIFIER ::= { iso(1) 416 identified-organization(3) certicom(132) curve(0) 33 } 417 secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 418 us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } 419 secp384r1 OBJECT IDENTIFIER ::= { iso(1) 420 identified-organization(3) certicom(132) curve(0) 34 } 421 secp521r1 OBJECT IDENTIFIER ::= { iso(1) 422 identified-organization(3) certicom(132) curve(0) 35 } 424 Specific conventions to be considered are specified in RFC 5753 425 [RFC5753]. 427 The ECDH key agreement algorithm used together with curve25519 or 428 curve448 are identified by the following OIDs: 430 id-X25519 OBJECT IDENTIFIER ::= { iso(1) 431 identified-organization(3) thawte(101) 110 } 432 id-X448 OBJECT IDENTIFIER ::= { iso(1) 433 identified-organization(3) thawte(101) 111 } 435 Specific conventions to be considered are specified in RFC 8418 436 [RFC8418]. 438 4.2. Key Transport Algorithms 440 The key transport algorithm is also referred to as PROT_ENC_ALG in 441 RFC 4210 Appendix D and E [RFC4210] and as KM_KL_ALG in the 442 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as 443 well as in Section 7. 445 Key transport algorithms are only used in CMP when using CMS 446 [RFC5652] EnvelopedData together with the key transport key 447 management technique. 449 Key transport algorithm identifiers are located in: 451 * keyEncryptionAlgorithm field of KeyTransRecipientInfo 453 Key transport encrypted content-encryption keys are located in: 455 * encryptedKey field of KeyTransRecipientInfo 457 4.2.1. RSA 459 The RSA key transport algorithm is the RSA encryption scheme defined 460 in RFC 8017 [RFC8017]. 462 The algorithm identifier for RSA (PKCS #1 v1.5) is: 464 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 465 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 467 The algorithm identifier for RSAES-OAEP is: 469 id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) 470 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } 472 Further conventions to be considered for PKCS #1 v1.5 are specified 473 in RFC 3370 Section 4.2.1 [RFC3370] and for RSAES-OAEP in RFC 3560 474 [RFC3560]. 476 4.3. Symmetric Key-Encryption Algorithms 478 The symmetric key-encryption algorithm is also referred to as 479 KM_KW_ALG in Section 7.2 and in the Lightweight CMP Profile 480 [I-D.ietf-lamps-lightweight-cmp-profile]. 482 As symmetric key-encryption key management technique is not used by 483 CMP, the symmetric key-encryption algorithm is only needed when using 484 the key agreement or password-based key management technique with CMS 485 [RFC5652] EnvelopedData. 487 Key wrap algorithm identifiers are located in: 489 * parameters field of the KeyEncryptionAlgorithmIdentifier of 490 KeyAgreeRecipientInfo and PasswordRecipientInfo 492 Wrapped content-encryption keys are located in: 494 * encryptedKey field of RecipientEncryptedKeys (for key agreement) 495 and PasswordRecipientInfo (for password-based key management) 497 4.3.1. AES Key Wrap 499 The AES encryption algorithm is defined in FIPS Pub 197 500 [NIST.FIPS.197] and the key wrapping is defined in RFC 3394 501 [RFC3394]. 503 AES key encryption has the algorithm identifier: 505 id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 506 country(16) us(840) organization(1) gov(101) csor(3) 507 nistAlgorithm(4) aes(1) 5 } 508 id-aes192-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 509 country(16) us(840) organization(1) gov(101) csor(3) 510 nistAlgorithm(4) aes(1) 25 } 511 id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 512 country(16) us(840) organization(1) gov(101) csor(3) 513 nistAlgorithm(4) aes(1) 45 } 515 The underlying encryption functions for the key wrap and content- 516 encryption algorithms (as specified in Section 5) and the key sizes 517 for the two algorithms MUST be the same (e.g., AES-128 key wrap 518 algorithm with AES-128 content-encryption algorithm), see also 519 RFC 8551 [RFC8551]. 521 Further conventions to be considered for AES key wrap are specified 522 in RFC 3394 Section 2.2 [RFC3394] and RFC 3565 Section 2.3.2 523 [RFC3565]. 525 4.4. Key Derivation Algorithms 527 The key derivation algorithm is also referred to as KM_KD_ALG in 528 Section 7.2 and in the Lightweight CMP Profile 529 [I-D.ietf-lamps-lightweight-cmp-profile]. 531 Key derivation algorithms are only used in CMP when using CMS 532 [RFC5652] EnvelopedData together with password-based key management 533 technique. 535 Key derivation algorithm identifiers are located in: 537 * keyDerivationAlgorithm field of PasswordRecipientInfo 539 When using the password-based key management technique with 540 EnvelopedData as specified in CMP Updates together with message 541 authentication code (MAC)-based PKIProtection, the salt for the 542 password-based MAC and KDF must be chosen independently to ensure 543 usage of independent symmetric keys. 545 4.4.1. PBKDF2 547 The password-based key derivation function 2 (PBKDF2) is defined in 548 RFC 8018 [RFC8018]. 550 Password-based key derivation function 2 has the algorithm 551 identifier: 553 id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 554 rsadsi(113549) pkcs(1) pkcs-5(5) 12 } 556 Further conventions to be considered for PBKDF2 are specified in 557 RFC 3370 Section 4.4.1 [RFC3370] and RFC 8018 Section 5.2 [RFC8018]. 559 5. Content Encryption Algorithms 561 The content encryption algorithm is also referred to as PROT_SYM_ALG 562 in Section 7, RFC 4210 Appendix D and E [RFC4210], and the 563 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 565 Content encryption algorithms are only used in CMP when using CMS 566 [RFC5652] EnvelopedData to transport a signed private key package in 567 case of central key generation or key archiving, a certificate to 568 facilitate implicit proof-of-possession, or a revocation passphrase 569 in encrypted form. 571 Content encryption algorithm identifiers are located in: 573 * contentEncryptionAlgorithm field of EncryptedContentInfo 575 Encrypted content is located in: 577 * encryptedContent field of EncryptedContentInfo 579 5.1. AES-CBC 581 The AES encryption algorithm is defined in FIPS Pub 197 582 [NIST.FIPS.197]. 584 AES-CBC content encryption has the algorithm identifier: 586 id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 587 country(16) us(840) organization(1) gov(101) csor(3) 588 nistAlgorithm(4) aes(1) 2 } 589 id-aes192-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 590 country(16) us(840) organization(1) gov(101) csor(3) 591 nistAlgorithm(4) aes(1)22 } 592 id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 593 country(16) us(840) organization(1) gov(101) csor(3) 594 nistAlgorithm(4) aes(1)42 } 596 Specific conventions to be considered for AES-CBC content encryption 597 are specified in RFC 3565 [RFC3565]. 599 6. Message Authentication Code Algorithms 601 The message authentication code (MAC) is either used for shared 602 secret-based CMP message protection or together with the password- 603 based key derivation function (PBKDF2). 605 The message authentication code algorithm is also referred to as 606 MSG_MAC_ALG in Section 7, RFC 4210 Appendix D and E [RFC4210], and 607 the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 609 6.1. Password-Based MAC 611 Password-based message authentication code (MAC) algorithms combine 612 the derivation of a symmetric key from a password or other shared 613 secret information and a symmetric key-based MAC function as 614 specified in Section 6.2 using this derived key. 616 Message authentication code algorithm identifiers are located in: 618 * protectionAlg field of PKIHeader 620 Message authentication code values are located in: 622 * PKIProtection field of PKIMessage 624 6.1.1. PasswordBasedMac 626 The PasswordBasedMac algorithm is defined in RFC 4210 Section 5.1.3.1 627 [RFC4210], RFC 4211 Section 4.4 [RFC4211], and Algorithm Requirements 628 Update to the Internet X.509 Public Key Infrastructure Certificate 629 Request Message Format (CRMF) [RFC9045]. 631 The PasswordBasedMac algorithm is identified by the following OID: 633 id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 634 us(840) nt(113533) nsn(7) algorithms(66) 13 } 636 Further conventions to be considered for password-based MAC are 637 specified in RFC 4210 Section 5.1.3.1 [RFC4210], RFC 4211 Section 4.4 638 [RFC4211], and Algorithm Requirements Update to the Internet X.509 639 Public Key Infrastructure Certificate Request Message Format (CRMF) 640 [RFC9045]. 642 6.1.2. PBMAC1 644 The Password-Based Message Authentication Code 1 (PBMAC1) is defined 645 in RFC 8018 [RFC8018]. PBMAC1 combines a password-based key 646 derivation function like PBKDF2 (Section 4.4.1) with an underlying 647 symmetric key-based message authentication scheme. 649 PBMAC1 has the following OID: 651 id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 652 rsadsi(113549) pkcs(1) pkcs-5(5) 14 } 654 Specific conventions to be considered for PBMAC1 are specified in 655 RFC 8018 Section 7.1 and A.5 [RFC8018]. 657 6.2. Symmetric Key-Based MAC 659 Symmetric key-based message authentication code (MAC) algorithms are 660 used for deriving the symmetric encryption key when using PBKDF2 as 661 described in Section 4.4.1 as well as with Password-based MAC as 662 described in Section 6.1. 664 Message authentication code algorithm identifiers are located in: 666 * protectionAlg field of PKIHeader 667 * messageAuthScheme field of PBMAC1 668 * mac field of PBMParameter 669 * prf field of PBKDF2-params 670 Message authentication code values are located in: 672 * PKIProtection field of PKIMessage 674 6.2.1. SHA2-Based HMAC 676 The HMAC algorithm is defined in RFC 2104 [RFC2104] and 677 FIPS Pub 198-1 [NIST.FIPS.198-1]. 679 The HMAC algorithm used with SHA2 message digest algorithms is 680 identified by the following OIDs: 682 id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 683 us(840) rsadsi(113549) digestAlgorithm(2) 8 } 684 id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 685 us(840) rsadsi(113549) digestAlgorithm(2) 9 } 686 id-hmacWithSHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 687 us(840) rsadsi(113549) digestAlgorithm(2) 10 } 688 id-hmacWithSHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 689 us(840) rsadsi(113549) digestAlgorithm(2) 11 } 691 Specific conventions to be considered for SHA2-based HMAC are 692 specified in RFC 4231 Section 3.1 [RFC4231]. 694 6.2.2. AES-GMAC 696 The AES-GMAC algorithm is defined in FIPS Pub 197 [NIST.FIPS.197] and 697 NIST SP 800-38d [NIST.SP.800-38d]. 699 Note: AES-GMAC MUST NOT be used twice with the same parameter set, 700 especially the same nonce. Therefore, it MUST NOT be used together 701 with PBKDF2. When using it with PBMAC1 it MUST be ensured that AES- 702 GMAC is only used as message authentication scheme and not for the 703 key derivation function PBKDF2. 705 The AES-GMAC algorithm is identified by the following OIDs: 707 id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 708 country(16) us(840) organization(1) gov(101) csor(3) 709 nistAlgorithm(4) aes(1) 9 } 710 id-aes192-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 711 country(16) us(840) organization(1) gov(101) csor(3) 712 nistAlgorithm(4) aes(1) 29 } 713 id-aes256-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 714 country(16) us(840) organization(1) gov(101) csor(3) 715 nistAlgorithm(4) aes(1) 49 } 717 Specific conventions to be considered for AES-GMAC are specified in 718 RFC 9044 [RFC9044]. 720 6.2.3. SHAKE-Based KMAC 722 The KMAC algorithm is defined in RFC 8702 [RFC8702] and 723 FIPS SP 800-185 [NIST.SP.800-185]. 725 The SHAKE-based KMAC algorithm is identified by the following OIDs: 727 id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 728 country(16) us(840) organization(1) gov(101) csor(3) 729 nistAlgorithm(4) 2 19 } 730 id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 731 country(16) us(840) organization(1) gov(101) csor(3) 732 nistAlgorithm(4) 2 20 } 734 Specific conventions to be considered for KMAC with SHAKE are 735 specified in RFC 8702 Section 3.4 [RFC8702]. 737 7. Algorithm Use Profiles 739 This section provides profiles of algorithms and respective 740 conventions for different application use cases. 742 Recommendations like NIST SP 800-57 Recommendation for Key Management 743 Table 2 [NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and 744 Protocols Report (2018) Section 4.6 [ECRYPT.CSA.D5.4] provide general 745 information on current cryptographic algorithms. 747 The overall cryptographic strength of a CMP deployment will depend on 748 several factors, including: 750 * Capabilities of the end entity: What kind of algorithms does the 751 end entity support. The cryptographic strength of the system 752 SHOULD be at least as strong as the algorithms and keys used for 753 the certificate being managed. 755 * Algorithm profile: The overall strength of the profile will be the 756 strength of the weakest algorithm it contains. 758 * Message protection: The overall strength of the CMC message 759 protection 761 - MAC-based protection: The entropy of the shared secret 762 information or password when MAC-based message protection is 763 used (MSG_MAC_ALG). 765 - Signature-based protection: The strength of the key pair and 766 signature algorithm when signature-based protection is used 767 (MSG_SIG_ALG). 769 - Protection of centrally generated keys: The strength of the 770 algorithms used for the key management technique (Section 7.2: 771 PROT_ENC_ALG or Section 7.1: KM_KA_ALG, KM_KT_ALG, KM_KD_ALG) 772 and the encryption of the content-encryption key and private 773 key (Section 7.2: SYM_PENC_ALG, PROT_SYM_ALG or Section 7.1: 774 KM_KW_ALG, PROT_SYM_ALG). 776 The following table shows the algorithms listed in this document 777 sorted by their bits of security. If an implementation intends to 778 enroll and manage certificate for keys of a specific security, it 779 SHALL implement and use algorithms of at least that strength for the 780 respective PKI management operation. If one row does not provide a 781 suitable algorithm, the implementer MUST choose one offering more 782 bits of security. 784 +=======+==========+================+==================+============+ 785 | Bits | RSA or | Elliptic | Hash Function or | Symmetric | 786 | of | DH | Curve | XOF with | Encryption | 787 | Secu- | | | Specified Output | | 788 | rity | | | Length (d) | | 789 +=======+==========+================+==================+============+ 790 | 112 | RSA2048, | ECDSA/ECDH | SHA224 | | 791 | | DH(2048) | (secp224r1) | | | 792 +-------+----------+----------------+------------------+------------+ 793 | 128 | RSA3072, | ECDSA/ECDH | SHA256, | AES-128 | 794 | | DH(3072) | (secp256r1), | SHAKE128(d=256) | | 795 | | | Ed25519/ | | | 796 | | | X25519 | | | 797 | | | (Curve25519) | | | 798 +-------+----------+----------------+------------------+------------+ 799 | 192 | | ECDSA/ECDH | SHA384 | AES-192 | 800 | | | (secp384r1) | | | 801 +-------+----------+----------------+------------------+------------+ 802 | 224 | | Ed448/X448 | | | 803 | | | (Curve448) | | | 804 +-------+----------+----------------+------------------+------------+ 805 | 256 | | ECDSA/ECDH | SHA512, | AES-256 | 806 | | | (secp521r1) | SHAKE256(d=512) | | 807 +-------+----------+----------------+------------------+------------+ 809 Table 1: Cryptographic Algorithms Sorted by their Bits of Security 811 The following table shows the cryptographic algorithms sorted by 812 their usage in CMP and with more details. 814 +========+==========+===============+===============+===============+ 815 |Bits of |Key Types |CMP Protection |Key Management | Key-Wrap and | 816 |Security|to Be | |Technique | Symmetric | 817 | |Certified | | | Encryption | 818 +========+==========+===============+===============+===============+ 819 | | |MSG_SIG_ALG, |PROT_ENC_ALG or| PROT_SYM_ALG, | 820 | | |MSG_MAC_ALG |KM_KA_ALG, | SYM_PENC_ALG | 821 | | | |KM_KT_ALG, | or | 822 | | | |KM_KD_ALG | KM_KW_ALG | 823 +--------+----------+---------------+---------------+---------------+ 824 |112 |RSA2048, |RSASSA-PSS |DH(2048), | | 825 | |secp224r1 |(2048, SHA224 |RSAES-OAEP | | 826 | | |or SHAKE128 |(2048, SHA224),| | 827 | | |(d=256)), |RSAEncryption | | 828 | | |RSAEncryption |(2048, SHA224),| | 829 | | |(2048, SHA224),|ECDH | | 830 | | |ECDSA |(secp224r1, | | 831 | | |(secp224r1, |SHA224), | | 832 | | |SHA224 or |PBKDF2 (HMAC- | | 833 | | |SHAKE128 |SHA224) | | 834 | | |(d=256)), | | | 835 | | |PBMAC1 (HMAC- | | | 836 | | |SHA224) | | | 837 +--------+----------+---------------+---------------+---------------+ 838 |128 |RSA3072, |RSASSA-PSS |DH(3072), | AES-128 | 839 | |secp256r1,|(3072, SHA256 |RSAES-OAEP | | 840 | |Curve25519|or SHAKE128 |(3072, SHA256),| | 841 | | |(d=256)), |RSAEncryption | | 842 | | |RSAEncryption |(3072, SHA256),| | 843 | | |(3072, SHA256),|ECDH | | 844 | | |ECDSA |(secp256r1, | | 845 | | |(secp256r1, |SHA256), | | 846 | | |SHA256 or |X25519, | | 847 | | |SHAKE128 |PBKDF2 (HMAC- | | 848 | | |(d=256)), |SHA256) | | 849 | | |Ed25519 | | | 850 | | |(SHA512), | | | 851 | | |PBMAC1 (HMAC- | | | 852 | | |SHA256) | | | 853 +--------+----------+---------------+---------------+---------------+ 854 |192 |secp384r1 |ECDSA |ECDH | AES-192 | 855 | | |(secp384r1, |(secp384r1, | | 856 | | |SHA384), |SHA384), | | 857 | | |PBMAC1 (HMAC- |PBKDF2 (HMAC- | | 858 | | |SHA384) |SHA384) | | 859 +--------+----------+---------------+---------------+---------------+ 860 |224 |Curve448 |Ed448 |X448 | | 861 | | |(SHAKE256) | | | 862 +--------+----------+---------------+---------------+---------------+ 863 |256 |secp521r1 |ECDSA |ECDH | AES-256 | 864 | | |(secp521r1, |(secp521r1, | | 865 | | |SHA512 or |SHA512), | | 866 | | |SHAKE256 |PBKDF2 (HMAC- | | 867 | | |(d=512)), |SHA512) | | 868 | | |PBMAC1 (HMAC- | | | 869 | | |SHA512) | | | 870 +--------+----------+---------------+---------------+---------------+ 872 Table 2: Cryptographic Algorithms Sorted by their Bits of 873 Security and Usage by CMP 875 To avoid consuming too many computational resources it is recommended 876 to choose a set of algorithms offering roughly the same level of 877 security. Below are provided several algorithm profiles which are 878 balanced, assuming the implementer chooses MAC secrets and/or 879 certificate profiles of at least equivalent strength. 881 7.1. Algorithm Profile for RFC 4210 PKI Management Message Profiles 883 The following table updates the definitions of algorithms used within 884 PKI Management Message Profiles as defined in CMP Appendix D.2 885 [RFC4210]. 887 The columns in the table are: 889 Name: An identifier used for message profiles 891 Use: Description of where and for what the algorithm is used 893 Mandatory: Algorithms which MUST be supported by conforming 894 implementations 896 Optional: Algorithms which are OPTIONAL to support 898 Deprecated: Algorithms from RFC 4210 [RFC4210] which SHOULD NOT be 899 used any more 900 +============+==============+======+===================+============+ 901 |Name |Use |Manda-| Optional |Deprecated | 902 | | |tory | | | 903 +============+==============+======+===================+============+ 904 |MSG_SIG_ALG |protection of |RSA | ECDSA, EdDSA |DSA, | 905 | |PKI messages | | |combinations| 906 | |using | | |with MD5 and| 907 | |signature | | |SHA-1 | 908 +------------+--------------+------+-------------------+------------+ 909 |MSG_MAC_ALG |protection of |PBMAC1| PasswordBasedMac, |X9.9 | 910 | |PKI messages | | HMAC, KMAC | | 911 | |using MACing | | | | 912 +------------+--------------+------+-------------------+------------+ 913 |SYM_PENC_ALG|symmetric |AES- | |3-DES(3-key-| 914 | |encryption of |wrap | |EDE, CBC | 915 | |an end | | |Mode), RC5, | 916 | |entity's | | |CAST-128 | 917 | |private key | | | | 918 | |where | | | | 919 | |symmetric key | | | | 920 | |is distributed| | | | 921 | |out-of-band | | | | 922 +------------+--------------+------+-------------------+------------+ 923 |PROT_ENC_ALG|asymmetric |DH | ECDH, RSA | | 924 | |algorithm used| | | | 925 | |for encryption| | | | 926 | |of (symmetric | | | | 927 | |keys for | | | | 928 | |encryption of)| | | | 929 | |private keys | | | | 930 | |transported in| | | | 931 | |PKIMessages | | | | 932 +------------+--------------+------+-------------------+------------+ 933 |PROT_SYM_ALG|symmetric |AES- | |3-DES(3-key-| 934 | |encryption |CBC | |EDE, CBC | 935 | |algorithm used| | |Mode), RC5, | 936 | |for encryption| | |CAST-128 | 937 | |of private key| | | | 938 | |bits (a key of| | | | 939 | |this type is | | | | 940 | |encrypted | | | | 941 | |using | | | | 942 | |PROT_ENC_ALG) | | | | 943 +------------+--------------+------+-------------------+------------+ 945 Table 3: Algorithms Used Within RFC 4210 Appendix D.2 947 Mandatory Algorithm Identifiers and Specifications: 949 RSA: sha256WithRSAEncryption with 2048 bit, see Section 3.1 951 PasswordBasedMac: id-PasswordBasedMac, see Section 6.1 (with id- 952 sha256 as the owf parameter, see Section 2.1 and id-hmacWithSHA256 as 953 the mac parameter, see Section 6.2.1) 955 PBMAC1: id-PBMAC1, see Section 6.1.2 (with id-PBKDF2 as the key 956 derivation function, see Section 4.4.1 and id-hmacWithSHA256 as 957 message authentication scheme, see Section 6.2.1). It is RECOMMENDED 958 to prefer the usage of PBMAC1 instead of PasswordBasedMac. 960 DH: id-alg-ESDH, see Section 4.1.1 962 AES-wrap: id-aes128-wrap, see Section 4.3.1 964 AES-CBC: id-aes128-CBC, see Section 5.1 966 7.2. Algorithm Profile for Lightweight CMP Profile 968 The following table contains definitions of algorithms which MAY be 969 supported by implementations of the Lightweight CMP Profile 970 [I-D.ietf-lamps-lightweight-cmp-profile]. 972 As the set of algorithms to be used for implementations of the 973 Lightweight CMP Profile heavily depends on the PKI management 974 operations implemented, the certificates used for messages 975 protection, and the certificates to be managed, this document will 976 not specify a specific set that is mandatory to support for 977 conforming implementations. 979 The columns in the table are: 981 Name: An identifier used for message profiles 983 Use: Description of where and for what the algorithm is used 985 Examples: Lists the algorithms as described in this document. The 986 list of algorithms depends on the set of PKI management operations to 987 be implemented. 989 Note: It is RECOMMENDED to prefer the usage of PBMAC1 instead of 990 PasswordBasedMac. 992 +==============+================================+==================+ 993 | Name | Use | Examples | 994 +==============+================================+==================+ 995 | MSG_SIG_ALG | protection of PKI messages | RSA, ECDSA, | 996 | | using signature and for | EdDSA | 997 | | SignedData, e.g., a private | | 998 | | key transported in PKIMessages | | 999 +--------------+--------------------------------+------------------+ 1000 | MSG_MAC_ALG | protection of PKI messages | PasswordBasedMac | 1001 | | using MACing | (see Section 9), | 1002 | | | PBMAC1, HMAC, | 1003 | | | KMAC | 1004 +--------------+--------------------------------+------------------+ 1005 | KM_KA_ALG | asymmetric key agreement | DH, ECDH | 1006 | | algorithm used for agreement | | 1007 | | of a symmetric key for use | | 1008 | | with KM_KW_ALG | | 1009 +--------------+--------------------------------+------------------+ 1010 | KM_KT_ALG | asymmetric key encryption | RSA | 1011 | | algorithm used for transport | | 1012 | | of a symmetric key for | | 1013 | | PROT_SYM_ALG | | 1014 +--------------+--------------------------------+------------------+ 1015 | KM_KD_ALG | symmetric key derivation | PBKDF2 | 1016 | | algorithm used for derivation | | 1017 | | of a symmetric key for use | | 1018 | | with KM_KW_ALG | | 1019 +--------------+--------------------------------+------------------+ 1020 | KM_KW_ALG | algorithm to wrap a symmetric | AES-wrap | 1021 | | key for PROT_SYM_ALG | | 1022 +--------------+--------------------------------+------------------+ 1023 | PROT_SYM_ALG | symmetric content encryption | AES-CBC | 1024 | | algorithm used for encryption | | 1025 | | of EnvelopedData, e.g., a | | 1026 | | private key transported in | | 1027 | | PKIMessages | | 1028 +--------------+--------------------------------+------------------+ 1030 Table 4: Algorithms Used Within Lightweight CMP Profile 1032 8. IANA Considerations 1034 This document does not request changes to the IANA registry. 1036 9. Security Considerations 1038 RFC 4210 Appendix D.2 [RFC4210] contains a set of algorithms, 1039 mandatory to be supported by conforming implementations. These 1040 algorithms were appropriate at the time CMP was released, but as 1041 cryptographic algorithms weaken over time, some of them should not be 1042 used anymore. In general, new attacks are emerging due to research 1043 cryptoanalysis or increase in computing power. New algorithms were 1044 introduced that are more resistant to today's attacks. 1046 This document lists many cryptographic algorithms usable with CMP to 1047 offer implementer a more up-to-date choice. Finally, the algorithms 1048 to be supported also heavily depend on the certificates and PKI 1049 management operations utilized in the target environment. The 1050 algorithm with the lowest security strength and the entropy of shared 1051 secret information define the security of the overall solution, see 1052 Section 7. 1054 When using MAC-based message protection the use of PBMAC1 is 1055 preferable to that of PasswordBasedMac. First, PBMAC1 is a well- 1056 known scrutinized algorithm, which is not true for PasswordBasedMac. 1057 Second, the PasswordBasedMac algorithm as specified in RFC 4211 1058 Section 4.4 [RFC4211] is essentially PBKDF1 (as defined in RFC 8018 1059 Section 5.1 [RFC8018]) with an HMAC step at the end. Here we update 1060 to use the PBKDF2-HMAC construct defined as PBMAC1 in [RFC8018]. 1061 PBKDF2 is superior to PBKDF1 in an improved internal construct for 1062 iterated hashing, and in removing PBKDF1's limitation of only being 1063 able to derive keys up to the size of the underlying hash function. 1064 Additionally, PBKDF1 is not recommended for new applications as 1065 stated in Section 5.1 of RFC 8018 [RFC8018] and no longer an approved 1066 algorithm by most standards bodies, and therefore presents 1067 difficulties to implementer who are submitting their CMP 1068 implementations for certification, hence moving to a PBKDF2-based 1069 mechanism. This change is in alignment with [RFC9045] which updates 1070 [RFC4211] to allow the use of PBMAC1 in CRMF. 1072 AES-GMAC MUST NOT be used as the pseudo random function in PBKDF2; 1073 the use of AES-GMAC more than once with the same key and the same 1074 nonce will break the security. 1076 In Section 7 of this document there is also an update to the 1077 Appendix D.2 of RFC 4210 [RFC4210] and a set of algorithms that MAY 1078 be supported when implementing the Lightweight CMP Profile 1079 [I-D.ietf-lamps-lightweight-cmp-profile]. 1081 It is recognized that there may be older CMP implementations in use 1082 that conform to the algorithm use profile from Appendix D.2 of 1083 RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for 1084 PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory. 1085 Therefore, it is expected that many CMP systems may already support 1086 the recommended algorithms in this specification. In such systems 1087 the weakened algorithms should be disabled from further use. If 1088 critical systems cannot be immediately updated to conform to the 1089 recommended algorithm use profile, it is recommended a plan to 1090 migrate the infrastructure to conforming profiles be adopted as soon 1091 as possible. 1093 Symmetric key-based MAC algorithms as described in Section 6.2 MAY be 1094 used as MSG_MAC_ALG. The implementer MUST choose a suitable PRF and 1095 ensure that the key has sufficient entropy to match the overall 1096 security level of the algorithm profile. These considerations are 1097 outside the scope of the profile. 1099 10. Acknowledgements 1101 Thanks to Russ Housley for supporting this draft with submitting 1102 [RFC9044] and [RFC9045]. 1104 May thanks also to all reviewers like Serge Mister, Mark Ferreira, 1105 Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steffen 1106 Fries for their input and feedback to this document. Apologies to 1107 all not mentioned reviewers and supporters. 1109 11. Normative References 1111 [I-D.ietf-lamps-cmp-updates] 1112 Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate 1113 Management Protocol (CMP) Updates", Work in Progress, 1114 Internet-Draft, draft-ietf-lamps-cmp-updates-19, 25 May 1115 2022, . 1118 [I-D.ietf-lamps-lightweight-cmp-profile] 1119 Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight 1120 Certificate Management Protocol (CMP) Profile", Work in 1121 Progress, Internet-Draft, draft-ietf-lamps-lightweight- 1122 cmp-profile-12, 13 May 2022, 1123 . 1126 [NIST.FIPS.180-4] 1127 Dang, Quynh H., "Secure Hash Standard", NIST NIST FIPS 1128 180-4, DOI 10.6028/NIST.FIPS.180-4, July 2015, 1129 . 1132 [NIST.FIPS.186-4] 1133 National Institute of Standards and Technology (NIST), 1134 "Digital Signature Standard (DSS)", NIST NIST FIPS 186-4, 1135 DOI 10.6028/NIST.FIPS.186-4, July 2013, 1136 . 1139 [NIST.FIPS.186-5] 1140 National Institute of Standards and Technology (NIST), 1141 "FIPS Pub 186-5 (Draft): Digital Signature Standard 1142 (DSS)", October 2019, 1143 . 1146 [NIST.FIPS.197] 1147 National Institute of Standards and Technology (NIST), 1148 "Advanced encryption standard (AES)", NIST NIST FIPS 197, 1149 DOI 10.6028/NIST.FIPS.197, November 2001, 1150 . 1153 [NIST.FIPS.198-1] 1154 National Institute of Standards and Technology (NIST), 1155 "The Keyed-Hash Message Authentication Code (HMAC)", 1156 NIST NIST FIPS 198-1, DOI 10.6028/NIST.FIPS.198-1, July 1157 2008, . 1160 [NIST.FIPS.202] 1161 Dworkin, Morris J., "SHA-3 Standard: Permutation-Based 1162 Hash and Extendable-Output Functions", NIST NIST FIPS 202, 1163 DOI 10.6028/NIST.FIPS.202, July 2015, 1164 . 1167 [NIST.SP.800-185] 1168 Kelsey, John., Change, Shu-jen., and Ray. Perlner, "SHA-3 1169 derived functions: cSHAKE, KMAC, TupleHash and 1170 ParallelHash", NIST NIST SP 800-185, 1171 DOI 10.6028/NIST.SP.800-185, December 2016, 1172 . 1175 [NIST.SP.800-38d] 1176 Dworkin, M J., "Recommendation for block cipher modes of 1177 operation :GaloisCounter Mode (GCM) and GMAC", NIST NIST 1178 SP 800-38d, DOI 10.6028/NIST.SP.800-38d, 2007, 1179 . 1182 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1183 Hashing for Message Authentication", RFC 2104, 1184 DOI 10.17487/RFC2104, February 1997, 1185 . 1187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1188 Requirement Levels", BCP 14, RFC 2119, 1189 DOI 10.17487/RFC2119, March 1997, 1190 . 1192 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1193 RFC 2631, DOI 10.17487/RFC2631, June 1999, 1194 . 1196 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1197 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 1198 . 1200 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1201 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 1202 September 2002, . 1204 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport 1205 Algorithm in Cryptographic Message Syntax (CMS)", 1206 RFC 3560, DOI 10.17487/RFC3560, July 2003, 1207 . 1209 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1210 Encryption Algorithm in Cryptographic Message Syntax 1211 (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, 1212 . 1214 [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in 1215 Cryptographic Message Syntax (CMS)", RFC 4056, 1216 DOI 10.17487/RFC4056, June 2005, 1217 . 1219 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1220 "Internet X.509 Public Key Infrastructure Certificate 1221 Management Protocol (CMP)", RFC 4210, 1222 DOI 10.17487/RFC4210, September 2005, 1223 . 1225 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1226 Certificate Request Message Format (CRMF)", RFC 4211, 1227 DOI 10.17487/RFC4211, September 2005, 1228 . 1230 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 1231 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 1232 RFC 4231, DOI 10.17487/RFC4231, December 2005, 1233 . 1235 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1236 "Elliptic Curve Cryptography Subject Public Key 1237 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 1238 . 1240 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1241 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1242 . 1244 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 1245 Cryptography (ECC) Algorithms in Cryptographic Message 1246 Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 1247 2010, . 1249 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 1250 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 1251 2010, . 1253 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1254 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1255 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1256 . 1258 [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: 1259 Password-Based Cryptography Specification Version 2.1", 1260 RFC 8018, DOI 10.17487/RFC8018, January 2017, 1261 . 1263 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1264 Signature Algorithm (EdDSA)", RFC 8032, 1265 DOI 10.17487/RFC8032, January 2017, 1266 . 1268 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1269 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1270 May 2017, . 1272 [RFC8418] Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key 1273 Agreement Algorithm with X25519 and X448 in the 1274 Cryptographic Message Syntax (CMS)", RFC 8418, 1275 DOI 10.17487/RFC8418, August 2018, 1276 . 1278 [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature 1279 Algorithm (EdDSA) Signatures in the Cryptographic Message 1280 Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 1281 2018, . 1283 [RFC8702] Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash 1284 Functions in the Cryptographic Message Syntax (CMS)", 1285 RFC 8702, DOI 10.17487/RFC8702, January 2020, 1286 . 1288 [RFC9044] Housley, R., "Using the AES-GMAC Algorithm with the 1289 Cryptographic Message Syntax (CMS)", RFC 9044, 1290 DOI 10.17487/RFC9044, June 2021, 1291 . 1293 [RFC9045] Housley, R., "Algorithm Requirements Update to the 1294 Internet X.509 Public Key Infrastructure Certificate 1295 Request Message Format (CRMF)", RFC 9045, 1296 DOI 10.17487/RFC9045, June 2021, 1297 . 1299 12. Informative References 1301 [ECRYPT.CSA.D5.4] 1302 University of Bristol, "Algorithms, Key Size and Protocols 1303 Report (2018)", March 2015, 1304 . 1307 [NIST.SP.800-57pt1r5] 1308 Barker, Elaine., "Recommendation for key management:part 1 1309 - general", NIST NIST SP 800-57pt1r5, 1310 DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, 1311 . 1314 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1315 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1316 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 1317 April 2019, . 1319 [RFC8692] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key 1320 Infrastructure: Additional Algorithm Identifiers for 1321 RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, 1322 DOI 10.17487/RFC8692, December 2019, 1323 . 1325 Appendix A. History of Changes 1327 Note: This appendix will be deleted in the final version of the 1328 document. 1330 From version 13 -> 14: 1332 * Providing changes addressing comments from GEN AD review 1334 From version 12 -> 13: 1336 * Providing changes addressing comments from OPSDIR and GENART last 1337 call reviews 1339 From version 11 -> 12: 1341 * Capitalized all headlines 1343 From version 10 -> 11: 1345 * Changes on the tables in Section 7 after direct exchange with 1346 Quynh 1348 From version 09 -> 10: 1350 * Removed the pre-RFC5378 work disclaimer after the RFC 4210 authors 1351 granted BCP78 rights to the IETF Trust 1352 * Implemented the changes proposed by Quynh, (see thread "Quynh 1353 Action: draft-ietf-lamps-cmp-algorithms-08.txt") and removed 1354 markers for ToDos regarding this review of SHAKE and KMAC usage as 1355 well as on the tables in Section 7 1357 From version 08 -> 09: 1359 * Updated IPR disclaimer 1361 From version 07 -> 08: 1363 * Fixing issues from WG and AD review 1364 * Adding Note to Section 2.2, 3.3, and 6.2.3 regarding usage of 1365 SHAKE and KMAC and added ToDo regarding checking respective notes 1366 * Added two tables showing algorithms sorted by their strength to 1367 Section 7 and added ToDo regarding checking these tables 1368 * Updates the algorithm use profile in Section 7.1 1369 * Updated and added security consideration on SHAKE, 1370 PasswordBasedMac, KMAC, and symmetric key-based MAC functions and 1371 added ToDo regarding checking the security consideration on SHAKE 1373 From version 06 -> 07: 1375 * Fixing minor formatting nits 1377 From version 05 -> 06: 1379 * Added text to Section 2 and Section 3.3 to clearly specify the 1380 hash algorithm to use for certConf messages for certificates 1381 signed with EdDSA (see thread "[CMP Updates] Hash algorithm to us 1382 for calculating certHash") 1383 * Updated new RFC numbers for I-D.ietf-lamps-cms-aes-gmac-alg and I- 1384 D.ietf-lamps-crmf-update-algs 1386 From version 04 -> 05: 1388 * Minor changes and corrections in wording 1390 From version 03 -> 04: 1392 * Added John Gray to the list of authors due to his extensive 1393 support and valuable feedback 1394 * Added some clarification of the use AES-GMAC to Section 6.2.1 1395 * Extended the guidance on how to select a set of algorithms in 1396 Section 7 and deleted former Section 7.1 1397 * Deleted the algorithms mandatory to support in Section 7.2 as 1398 discussed at IETF 110 1399 * Extended the Security considerations in Section 9 1400 * Minor changes in wording 1402 From version 02 -> 03: 1404 * Moved former Appendix A to new Section 7 as suggested by Rich and 1405 Russ (see thread "I-D Action: draft-ietf-lamps-cmp-algorithms- 1406 02.txt") 1407 * Added a column to Table 1 in Section 7.2 to reflect the changes to 1408 RFC 4210 1409 * Updated Table 2 in Section 7.3 1410 * Added a paragraph to Section 9 to discuss backward compatibility 1411 with RFC 4210 1412 * Minor changes in wording 1414 From version 01 -> 02: 1416 * Added Hans Aschauer, Mike Ounsworth, and Serge Mister as co-author 1417 * Changed to XML V3 1418 * Added SHAKE digest algorithm to Section 2 as discussed at IETF 109 1419 * Deleted DSA from Section 3 as discussed at IETF 109 1420 * Added RSASSA-PSS with SHAKE to Section 3 1421 * Added SECP curves the section on ECDSA with SHA2, ECDSA with 1422 SHAKE, and EdDSA to Section 3 as discussed at IETF 109 1423 * Deleted static-static D-H and ECDH from Section 4.1 based on the 1424 discussion on the mailing list (see thread "[CMP Algorithms] 1425 Section 4.1.1 and 4.1.2 drop static-static (EC)DH key agreement 1426 algorithms for use in CMP") 1427 * Added ECDH OIDs and SECP curves, as well as ECDH with curve25519 1428 and curve448 to Section 4.1 as discussed at IETF 109 1429 * Deleted RSA-OAEP from Section 4.2 first as discussed at IETF 109, 1430 but re-added it after discussion on the mailing list (see thread 1431 "Mail regarding draft-ietf-lamps-cmp-algorithms") 1432 * Added a paragraph to Section 4.3.1 to explain that the algorithms 1433 and key length for content encryption and key wrapping must be 1434 aligned as discussed on the mailing list (see thread "[CMP 1435 Algorithms] Use Key-Wrap with or without padding in Section 4.3 1436 and Section 5") 1437 * Deleted AES-CCM and AES-GMC from and added AES-CBC to Section 5 as 1438 discussed at IETF 109 1439 * Added Section 6.1.2 to offer PBMAC1 as discusses on the mailing 1440 list (see thread "Mail regarding draft-ietf-lamps-crmf-update- 1441 algs-02") and restructured text in Section 6 to be easier to 1442 differentiate between password- and shared-key-based MAC 1443 * Deleted Diffie-Hellmann based MAC from Section 6 as is only 1444 relevant when using enrolling Diffie-Hellmann certificates 1445 * Added AES-GMAC and SHAKE-based KMAC to Section 6 as discussed at 1446 IETF 109 1447 * Extended Section 9 to mention Russ supporting with two additional 1448 I-Ds and name further supporters of the draft 1449 * Added a first draft of a generic algorithm selection guideline to 1450 Appendix A 1451 * Added a first proposal for mandatory algorithms for the 1452 Lightweight CMP Profile to Appendix A 1453 * Minor changes in wording 1455 From version 00 -> 01: 1457 * Changed sections Symmetric Key-Encryption Algorithms and Content 1458 Encryption Algorithms based on the discussion on the mailing list 1459 (see thread "[CMP Algorithms] Use Key-Wrap with or without padding 1460 in Section 4.3 and Section 5") 1461 * Added Appendix A with updated algorithms profile for RDC4210 1462 Appendix D.2 and first proposal for the Lightweight CMP Profile 1463 * Minor changes in wording 1465 Authors' Addresses 1467 Hendrik Brockhaus (editor) 1468 Siemens AG 1469 Email: hendrik.brockhaus@siemens.com 1471 Hans Aschauer 1472 Siemens AG 1473 Email: hans.aschauer@siemens.com 1475 Mike Ounsworth 1476 Entrust 1477 Email: mike.ounsworth@entrust.com 1479 John Gray 1480 Entrust 1481 Email: john.gray@entrust.com