idnits 2.17.1 draft-ietf-lamps-cmp-algorithms-08.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 : ---------------------------------------------------------------------------- No issues found here. 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 (17 November 2021) is 889 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-13 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-07 ** 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 (==), 2 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: 21 May 2022 J. Gray 7 Entrust 8 17 November 2021 10 Certificate Management Protocol (CMP) Algorithms 11 draft-ietf-lamps-cmp-algorithms-08 13 Abstract 15 This document updates RFC 4210 describing the conventions for using 16 concrete cryptographic algorithms with the Certificate Management 17 Protocol (CMP). CMP is used to enroll and further manage the 18 lifecycle of 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 21 May 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 . . . . . . . . . . . . . . . . . . 8 63 4.1. Key Agreement Algorithms . . . . . . . . . . . . . . . . 8 64 4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 8 65 4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 10 67 4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . 13 73 5.1. AES-CBC . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6. Message Authentication Code Algorithms . . . . . . . . . . . 14 75 6.1. Password-based MAC . . . . . . . . . . . . . . . . . . . 14 76 6.1.1. PasswordBasedMac . . . . . . . . . . . . . . . . . . 14 77 6.1.2. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . 15 78 6.2. Symmetric key-based MAC . . . . . . . . . . . . . . . . . 15 79 6.2.1. SHA2-based HMAC . . . . . . . . . . . . . . . . . . . 15 80 6.2.2. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . 16 81 6.2.3. SHAKE-based KMAC . . . . . . . . . . . . . . . . . . 16 82 7. Algorithm Use Profiles . . . . . . . . . . . . . . . . . . . 17 83 7.1. Algorithm Profile for RFC 4210 PKI Management Message 84 Profiles . . . . . . . . . . . . . . . . . . . . . . . . 20 85 7.2. Algorithm Profile for Lightweight CMP Profile . . . . . . 22 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 89 11. Normative References . . . . . . . . . . . . . . . . . . . . 25 90 12. Informative References . . . . . . . . . . . . . . . . . . . 29 91 Appendix A. History of changes . . . . . . . . . . . . . . . . . 30 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 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: 112 * hashAlg field of OOBCertHash and CertStatus 113 * owf field of Challenge, PBMParameter, and DHBMParameter 114 * digestAlgorithms field of SignedData 115 * digestAlgorithm field of SignerInfo 117 Digest values are located in: 119 * hashVal field of OOBCertHash 120 * certHash field of CertStatus 121 * witness field of Challenge 123 In addition, digest values are input to signature algorithms. 125 2.1. SHA2 127 The SHA2 algorithm family is defined in FIPS Pub 180-4 128 [NIST.FIPS.180-4]. 130 The message digest algorithms SHA-224, SHA-256, SHA-384, and SHA-512 131 are identified by the following OIDs: 133 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 134 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 135 hashalgs(2) 4 } 136 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 137 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 138 hashalgs(2) 1 } 139 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 140 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 141 hashalgs(2) 2 } 142 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 143 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 144 hashalgs(2) 3 } 146 Specific conventions to be considered are specified in RFC 5754 147 Section 2 [RFC5754]. 149 2.2. SHAKE 151 The SHA-3 family of hash functions is defined in FIPS Pub 202 152 [NIST.FIPS.202] and includes fixed output length variants SHA3-224, 153 SHA3-256, SHA3-384, and SHA3-512, as well as extendable-output 154 functions (SHAKEs) SHAKE128 and SHAKE256. Currently SHAKE128 and 155 SHAKE256 are the only members of the SHA3-family which are specified 156 for use in X.509 and PKIX [RFC8692], and CMS [RFC8702] as one-way 157 hash function for use with RSASSA-PSS and ECDSA as one-way hash 158 function for use with RSASSA-PSS and ECDSA. 160 SHAKE is an extendable-output function and FIPS Pub 202 161 [NIST.FIPS.202] prohibits using SHAKE as general-purpose hash 162 function. When SHAKE is used in CMP as a message digest algorithm, 163 the message digested by the SHAKE function MUST be appended with the 164 OCTET_STRING equivalent of "CMP_SHAKE128" for SHAKE128 and 165 "CMP_SHAKE256" for SHAKE 256 and the output length MUST be 256 bits 166 for SHAKE128 and 512 bits for SHAKE256. 168 < ToDo: This note must be checked and confirmed by experts. > 170 The message digest algorithms SHAKE128 and SHAKE256 are identified by 171 the following OIDs: 173 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 174 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 175 hashalgs(2) 11 } 176 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 177 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 178 hashalgs(2) 12 } 180 Specific conventions to be considered are specified in RFC 8702 181 Section 3.1 [RFC8702]. 183 3. Signature Algorithms 185 This section provides references to object identifiers and 186 conventions to be employed by CMP implementations that support RSA, 187 ECDSA, or EdDSA signature algorithms. 189 The signature algorithm is referred to as MSG_SIG_ALG in Section 7.2, 190 RFC 4210 Appendix D and E [RFC4210], and in the Lightweight CMP 191 Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 193 Signature algorithm identifiers are located in: 195 * protectionAlg field of PKIHeader 196 * algorithmIdentifier field of POPOSigningKey 197 * signatureAlgorithm field of CertificationRequest, 198 SignKeyPairTypes, and SignerInfo 200 Signature values are located in: 202 * protection field of PKIMessage 203 * signature field of POPOSigningKey 204 * signature field of CertificationRequest and SignerInfo 206 3.1. RSA 208 The RSA (RSASSA-PSS and PKCS#1 version 1.5) signature algorithm is 209 defined in RFC 8017 [RFC8017]. 211 The algorithm identifier for RSASAA-PSS signatures used with SHA2 212 message digest algorithms is identified by the following OID: 214 id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2) 215 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 } 217 Specific conventions to be considered are specified in RFC 4056 218 [RFC4056]. 220 The signature algorithm RSASSA-PSS used with SHAKE message digest 221 algorithms are identified by the following OIDs: 223 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) 224 identified-organization(3) dod(6) internet(1) security(5) 225 mechanisms(5) pkix(7) algorithms(6) 30 } 226 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) 227 identified-organization(3) dod(6) internet(1) security(5) 228 mechanisms(5) pkix(7) algorithms(6) 31 } 230 Specific conventions to be considered are specified in RFC 8702 231 Section 3.2.1 [RFC8702]. 233 The signature algorithm PKCS#1 version 1.5 used with SHA2 message 234 digest algorithms is identified by the following OIDs: 236 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 237 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } 238 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 239 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } 240 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 241 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } 242 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 243 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } 245 Specific conventions to be considered are specified in RFC 5754 246 Section 3.2 [RFC5754]. 248 3.2. ECDSA 250 The ECDSA signature algorithm is defined in FIPS Pub 186-4 251 [NIST.FIPS.186-4]. 253 The signature algorithm ECDSA used with SHA2 message digest 254 algorithms is identified by the following OIDs: 256 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 257 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } 258 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 259 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 260 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 261 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 262 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 263 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 265 As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves 266 are identified by the following OIDs: 268 secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 269 us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } 270 secp224r1 OBJECT IDENTIFIER ::= { iso(1) 271 identified-organization(3) certicom(132) curve(0) 33 } 272 secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 273 us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } 274 secp384r1 OBJECT IDENTIFIER ::= { iso(1) 275 identified-organization(3) certicom(132) curve(0) 34 } 276 secp521r1 OBJECT IDENTIFIER ::= { iso(1) 277 identified-organization(3) certicom(132) curve(0) 35 } 279 Specific conventions to be considered are specified in RFC 5754 280 Section 3.3 [RFC5754]. 282 The signature algorithm ECDSA used with SHAKE message digest 283 algorithms are identified by the following OIDs: 285 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) 286 identified-organization(3) dod(6) internet(1) security(5) 287 mechanisms(5) pkix(7) algorithms(6) 32 } 288 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) 289 identified-organization(3) dod(6) internet(1) security(5) 290 mechanisms(5) pkix(7) algorithms(6) 33 } 292 Specific conventions to be considered are specified in RFC 8702 293 Section 3.2.2 [RFC8702]. 295 3.3. EdDSA 297 The EdDSA signature algorithm is defined in RFC 8032 Section 3.3 298 [RFC8032] and FIPS Pub 186-5 (Draft) [NIST.FIPS.186-5]. 300 The signature algorithm Ed25519 that MUST be used with SHA-512 301 message digest algorithms is identified by the following OIDs: 303 id-Ed25519 OBJECT IDENTIFIER ::= { iso(1) 304 identified-organization(3) thawte(101) 112 } 306 The signature algorithm Ed448 that MUST be used with SHAKE256 message 307 digest algorithms is identified by the following OIDs: 309 id-Ed448 OBJECT IDENTIFIER ::= { iso(1) 310 identified-organization(3) thawte(101) 113 } 312 Specific conventions to be considered are specified in RFC 8419 313 [RFC8419]. 315 Note: The hash algorithm used to calculate the certHash in certConf 316 messages MUST be SHA512 if the certificate to be confirmed has been 317 signed using Ed25519 and SHAKE256 with d=512 if signed using Ed448. 319 < ToDo: This note must be checked and confirmed by experts. > 321 4. Key Management Algorithms 323 CMP utilizes the following general key management techniques: key 324 agreement, key transport, and passwords. 326 CRMF [RFC4211] and CMP Updates [I-D.ietf-lamps-cmp-updates] promotes 327 the use of CMS [RFC5652] EnvelopedData by deprecating the use of 328 EncryptedValue. 330 4.1. Key Agreement Algorithms 332 The key agreement algorithm is referred to as PROT_ENC_ALG in 333 RFC 4210 Appendix D and E [RFC4210] and as KM_KA_ALG in the 334 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as 335 well as in Section 7. 337 Key agreement algorithms are only used in CMP when using CMS 338 [RFC5652] EnvelopedData together with the key agreement key 339 management technique. When a key agreement algorithm is used, a key- 340 encryption algorithm (Section 4.3) is needed next to the content- 341 encryption algorithm (Section 5). 343 Key agreement algorithm identifiers are located in: 345 * keyEncryptionAlgorithm field of KeyAgreeRecipientInfo 347 Key wrap algorithm identifiers are located in: 349 * KeyWrapAlgorithm parameters within keyEncryptionAlgorithm field of 350 KeyAgreeRecipientInfo 352 Wrapped content-encryption keys are located in: 354 * encryptedKey field of RecipientEncryptedKeys 356 4.1.1. Diffie-Hellman 358 Diffie-Hellman key agreement is defined in RFC 2631 [RFC2631] and 359 SHALL be used in the ephemeral-static as specified in RFC 3370 360 [RFC3370]. Static-static variants SHALL NOT be used. 362 The Diffie-Hellman key agreement algorithm is identified by the 363 following OID: 365 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) 366 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 368 Specific conventions to be considered are specified in RFC 3370 369 Section 4.1 [RFC3370]. 371 4.1.2. ECDH 373 Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined in 374 RFC 5753 [RFC5753] and SHALL be used in the ephemeral-static variant 375 as specified in RFC 5753 [RFC5753] or the 1-Pass ECMQV variant as 376 specified in RFC 5753 [RFC5753]. Static-static variants SHALL NOT be 377 used. 379 The ECDH key agreement algorithm used together with NIST-recommended 380 SECP curves are identified by the following OIDs: 382 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 383 identified-organization(3) certicom(132) schemes(1) 11(11) 0 } 384 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 385 identified-organization(3) certicom(132) schemes(1) 11(11) 1 } 386 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 387 identified-organization(3) certicom(132) schemes(1) 11(11) 2 } 388 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 389 identified-organization(3) certicom(132) schemes(1) 11(11) 3 } 390 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 391 iso(1) identified-organization(3) certicom(132) schemes(1) 392 14(14) 0 } 393 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 394 iso(1) identified-organization(3) certicom(132) schemes(1) 395 14(14) 1 } 396 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 397 iso(1) identified-organization(3) certicom(132) schemes(1) 398 14(14) 2 } 399 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 400 iso(1) identified-organization(3) certicom(132) schemes(1) 401 14(14) 3 } 402 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 403 identified-organization(3) certicom(132) schemes(1) 15(15) 0 } 404 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 405 identified-organization(3) certicom(132) schemes(1) 15(15) 1 } 406 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 407 identified-organization(3) certicom(132) schemes(1) 15(15) 2 } 408 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 409 identified-organization(3) certicom(132) schemes(1) 15(15) 3 } 411 As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves 412 are identified by the following OIDs: 414 secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 415 us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } 416 secp224r1 OBJECT IDENTIFIER ::= { iso(1) 417 identified-organization(3) certicom(132) curve(0) 33 } 418 secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 419 us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } 420 secp384r1 OBJECT IDENTIFIER ::= { iso(1) 421 identified-organization(3) certicom(132) curve(0) 34 } 422 secp521r1 OBJECT IDENTIFIER ::= { iso(1) 423 identified-organization(3) certicom(132) curve(0) 35 } 425 Specific conventions to be considered are specified in RFC 5753 426 [RFC5753]. 428 The ECDH key agreement algorithm used together with curve25519 or 429 curve448 are identified by the following OIDs: 431 id-X25519 OBJECT IDENTIFIER ::= { iso(1) 432 identified-organization(3) thawte(101) 110 } 433 id-X448 OBJECT IDENTIFIER ::= { iso(1) 434 identified-organization(3) thawte(101) 111 } 436 Specific conventions to be considered are specified in RFC 8418 437 [RFC8418]. 439 4.2. Key Transport Algorithms 441 The key transport algorithm is also referred to as PROT_ENC_ALG in 442 RFC 4210 Appendix D and E [RFC4210] and as KM_KL_ALG in the 443 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as 444 well as in Section 7. 446 Key transport algorithms are only used in CMP when using CMS 447 [RFC5652] EnvelopedData together with the key transport key 448 management technique. 450 Key transport algorithm identifiers are located in: 452 * keyEncryptionAlgorithm field of KeyTransRecipientInfo 454 Key transport encrypted content-encryption keys are located in: 456 * encryptedKey field of KeyTransRecipientInfo 458 4.2.1. RSA 460 The RSA key transport algorithm is the RSA encryption scheme defined 461 in RFC 8017 [RFC8017]. 463 The algorithm identifier for RSA (PKCS #1 v1.5) is: 465 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 466 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 468 The algorithm identifier for RSAES-OAEP is: 470 id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) 471 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } 473 Further conventions to be considered for PKCS #1 v1.5 are specified 474 in RFC 3370 Section 4.2.1 [RFC3370] and for RSAES-OAEP in RFC 3560 475 [RFC3560]. 477 4.3. Symmetric Key-Encryption Algorithms 479 The symmetric key-encryption algorithm is also referred to as 480 KM_KW_ALG in Section 7.2 and in the Lightweight CMP Profile 481 [I-D.ietf-lamps-lightweight-cmp-profile]. 483 As symmetric key-encryption key management technique is not used by 484 CMP, the symmetric key-encryption algorithm is only needed when using 485 the key agreement or password-based key management technique with CMS 486 [RFC5652] EnvelopedData. 488 Key wrap algorithm identifiers are located in: 490 * parameters field of the KeyEncryptionAlgorithmIdentifier of 491 KeyAgreeRecipientInfo and PasswordRecipientInfo 493 Wrapped content-encryption keys are located in: 495 * encryptedKey field of RecipientEncryptedKeys (for key agreement) 496 and PasswordRecipientInfo (for password-based key management) 498 4.3.1. AES Key Wrap 500 The AES encryption algorithm is defined in FIPS Pub 197 501 [NIST.FIPS.197] and the key wrapping is defined in RFC 3394 502 [RFC3394]. 504 AES key encryption has the algorithm identifier: 506 id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 507 country(16) us(840) organization(1) gov(101) csor(3) 508 nistAlgorithm(4) aes(1) 5 } 509 id-aes192-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 510 country(16) us(840) organization(1) gov(101) csor(3) 511 nistAlgorithm(4) aes(1) 25 } 512 id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 513 country(16) us(840) organization(1) gov(101) csor(3) 514 nistAlgorithm(4) aes(1) 45 } 516 The underlying encryption functions for the key wrap and content- 517 encryption algorithms (as specified in Section 5) and the key sizes 518 for the two algorithms MUST be the same (e.g., AES-128 key wrap 519 algorithm with AES-128 content-encryption algorithm), see also 520 RFC 8551 [RFC8551]. 522 Further conventions to be considered for AES key wrap are specified 523 in RFC 3394 Section 2.2 [RFC3394] and RFC 3565 Section 2.3.2 524 [RFC3565]. 526 4.4. Key Derivation Algorithms 528 The key derivation algorithm is also referred to as KM_KD_ALG in 529 Section 7.2 and in the Lightweight CMP Profile 530 [I-D.ietf-lamps-lightweight-cmp-profile]. 532 Key derivation algorithms are only used in CMP when using CMS 533 [RFC5652] EnvelopedData together with password-based key management 534 technique. 536 Key derivation algorithm identifiers are located in: 538 * keyDerivationAlgorithm field of PasswordRecipientInfo 540 When using the password-based key management technique with 541 EnvelopedData as specified in CMP Updates together with MAC-based 542 PKIProtection, the salt for the password-based MAC and KDF must be 543 chosen independently to ensure 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 is either used for shared secret- 602 based CMP message protection or together with the password-based key 603 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 MAC algorithms combine the derivation of a symmetric 612 key from a password or other shared secret information and a 613 symmetric key-based MAC function as specified in Section 6.2 using 614 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 MAC algorithms are used for deriving the 660 symmetric encryption key when using PBKDF2 as described in 661 Section 4.4.1 as well as with Password-based MAC as described in 662 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 671 Message authentication code values are located in: 673 * PKIProtection field of PKIMessage 675 6.2.1. SHA2-based HMAC 677 The HMAC algorithm is defined in RFC 2104 [RFC2104] and 678 FIPS Pub 198-1 [NIST.FIPS.198-1]. 680 The HMAC algorithm used with SHA2 message digest algorithms is 681 identified by the following OIDs: 683 id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 684 us(840) rsadsi(113549) digestAlgorithm(2) 8 } 685 id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 686 us(840) rsadsi(113549) digestAlgorithm(2) 9 } 687 id-hmacWithSHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 688 us(840) rsadsi(113549) digestAlgorithm(2) 10 } 689 id-hmacWithSHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 690 us(840) rsadsi(113549) digestAlgorithm(2) 11 } 692 Specific conventions to be considered for SHA2-based HMAC are 693 specified in RFC 4231 Section 3.1 [RFC4231]. 695 6.2.2. AES-GMAC 697 The AES-GMAC algorithm is defined in FIPS Pub 197 [NIST.FIPS.197] and 698 NIST SP 800-38d [NIST.SP.800-38d]. 700 Note: AES-GMAC MUST NOT be used twice with the same parameter set, 701 especially the same nonce. Therefore, it MUST NOT be used together 702 with PBKDF2. When using it with PBMAC1 it MUST be ensured that AES- 703 GMAC is only used as message authentication scheme and not for the 704 key derivation function PBKDF2. 706 The AES-GMAC algorithm is identified by the following OIDs: 708 id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 709 country(16) us(840) organization(1) gov(101) csor(3) 710 nistAlgorithm(4) aes(1) 9 } 711 id-aes192-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 712 country(16) us(840) organization(1) gov(101) csor(3) 713 nistAlgorithm(4) aes(1) 29 } 714 id-aes256-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 715 country(16) us(840) organization(1) gov(101) csor(3) 716 nistAlgorithm(4) aes(1) 49 } 718 Specific conventions to be considered for AES-GMAC are specified in 719 RFC 9044 [RFC9044]. 721 6.2.3. SHAKE-based KMAC 723 The KMAC algorithm is defined in RFC 8702 [RFC8702] and 724 FIPS SP 800-185 [NIST.SP.800-185]. 726 Note: Currently it is assumed that the advantage of a HW 727 implementation over a SW implementation of KMAC is greater than of 728 HMAC-SHA2. Therefore, the advantage of an attacker is greater if 729 KMAC is used as a prf in PasswordBasedMac and PBKDF2. For this 730 reason, the use of KMAC as a prf in PasswordBasedMac and PBKDF2 is 731 discouraged. 733 < ToDo: This note must be checked and confirmed by experts. > 735 The SHAKE-based KMAC algorithm is identified by the following OIDs: 737 id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 738 country(16) us(840) organization(1) gov(101) csor(3) 739 nistAlgorithm(4) 2 19 } 740 id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 741 country(16) us(840) organization(1) gov(101) csor(3) 742 nistAlgorithm(4) 2 20 } 744 Specific conventions to be considered for KMAC with SHAKE are 745 specified in RFC 8702 Section 3.4 [RFC8702]. 747 7. Algorithm Use Profiles 749 This section provides profiles of algorithms and respective 750 conventions for different application use cases. 752 Recommendations like NIST SP 800-57 Recommendation for Key Management 753 Table2 [NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and 754 Protocols Report (2018) Section 4.6 [ECRYPT.CSA.D5.4] provide general 755 information on current cryptographic algorithms. 757 The overall cryptographic strength of a CMP deployment will depend on 758 several factors, including: 760 * Capabilities of the end entity: What kind of algorithms does the 761 end entity support. The cryptographic strength of the system 762 SHOULD be at least as strong as the algorithms and keys used for 763 the certificate being managed. 765 * Algorithm profile: The overall strength of the profile will be the 766 strength of the weakest algorithm it contains. 768 * Message protection: The overall strength of the CMC message 769 protection 771 - MAC-based protection: The entropy of the shared secret 772 information or password when MAC-based message protection is 773 used (MSG_MAC_ALG). 775 - Signature-based protection: The strength of the key pair and 776 signature algorithm when signature-based protection is used 777 (MSG_SIG_ALG). 779 - Protection of centrally generated keys: The strength of the 780 algorithms used for the key management technique (Section 7.2: 781 PROT_ENC_ALG or Section 7.1: KM_KA_ALG, KM_KT_ALG, KM_KD_ALG) 782 and the encryption of the content-encryption key and private 783 key (Section 7.2: SYM_PENC_ALG, PROT_SYM_ALG or Section 7.1: 784 KM_KW_ALG, PROT_SYM_ALG). 786 The following table shows the algorithms listed in this document 787 sorted by their bits of security. If an implementation intends to 788 enroll and manage certificate for keys of a specific security, it 789 SHALL implement and use algorithms of at least that strength for the 790 respective PKI management operation. If one column does not provide 791 a suitable algorithm, the implementer MUST choose one offering more 792 bits of security. 794 +========+===========+=========+=========+===============+==========+ 795 |Bits of |Recommended|RSA / D-H|Elliptic |Hash function |Symmetric | 796 |security|for | |curve |or XOF with |encryption| 797 | |managing | | |specified | | 798 | |keys up to | | |output length | | 799 | | | | |(d) | | 800 +========+===========+=========+=========+===============+==========+ 801 |112 |RSA2048 |RSA2048 |secp224r1|SHA224 | | 802 | |secp224r1 |D-H(2048)| | | | 803 +--------+-----------+---------+---------+---------------+----------+ 804 |128 |RSA3072 |RSA3072 |secp256r1|SHA256 |AES-128 | 805 | |secp256r1 |D-H(3072)|Ed25519/ |SHAKE128(d=256)| | 806 | |Ed25519 | |X25519 | | | 807 +--------+-----------+---------+---------+---------------+----------+ 808 |192 |secp384r1 | |secp384r1|SHA384 |AES-192 | 809 +--------+-----------+---------+---------+---------------+----------+ 810 |224 |Ed448 | |Ed448/ | | | 811 | | | |X448 | | | 812 +--------+-----------+---------+---------+---------------+----------+ 813 |256 |secp521r1 | |secp521r1|SHA512 |AES-256 | 814 | | | | |SHAKE256(d=512)| | 815 +--------+-----------+---------+---------+---------------+----------+ 817 Table 1: Cryptographic algorithms sorted by their bits of security 819 The following table shows the cryptographic algorithms sorted by 820 their usage in CMP and with more details. 822 +=====+=============+===============+===============+===============+ 823 |Bits |Recommended |CMP protection |Key management | Key-wrap and | 824 |of |for managing | |technique | symmetric | 825 |secu-|keys up to | | | encryption | 826 |rity | | | | | 827 +=====+=============+===============+===============+===============+ 828 | | |MSG_SIG_ALG, |PROT_ENC_ALG or| PROT_SYM_ALG, | 829 | | |MSG_MAC_ALG |KM_KA_ALG, | SYM_PENC_ALG | 830 | | | |KM_KT_ALG, | or | 831 | | | |KM_KD_ALG | KM_KW_ALG | 832 +-----+-------------+---------------+---------------+---------------+ 833 |112 |RSA2048, |RSASSA-PSS |ESDH (2048), | | 834 | |secp224r1 |(2048, SHA224 |RSAES-OAEP | | 835 | | |or SHAKE128), |(2048, SHA224),| | 836 | | |RSAEncryption |RSAEncryption | | 837 | | |(2048, SHA224),|(2048), | | 838 | | |ECDSA |ECDH | | 839 | | |(secp224r1, |(secp224r1, | | 840 | | |SHA224 or |SHA224), | | 841 | | |SHAKE128), |PBKDF2 (HMAC- | | 842 | | |PBMAC1 (HMAC- |SHA224) | | 843 | | |SHA224) | | | 844 +-----+-------------+---------------+---------------+---------------+ 845 |128 |RSA3072, |RSASSA-PSS |ESDH (3072), | AES-128 | 846 | |secp256r1, |(3072, SHA256 |RSAES-OAEP | | 847 | |Ed25519 |or SHAKE128), |(3072, SHA256),| | 848 | | |RSAEncryption |RSAEncryption | | 849 | | |(3072, SHA256),|(3072), | | 850 | | |ECDSA |ECDH | | 851 | | |(secp256r1, |(secp256r1, | | 852 | | |SHA256 or |SHA256), | | 853 | | |SHAKE128), |ECDH (X25519), | | 854 | | |Ed25519 |PBKDF2 (HMAC- | | 855 | | |(SHA512), |SHA256) | | 856 | | |PBMAC1 (HMAC- | | | 857 | | |SHA256) | | | 858 +-----+-------------+---------------+---------------+---------------+ 859 |192 |secp384r1 |ECDSA |ECDH | AES-192 | 860 | | |(secp384r1, |(secp384r1, | | 861 | | |SHA384), |SHA384), | | 862 | | |PBMAC1 (HMAC- |PBKDF2 (HMAC- | | 863 | | |SHA384) |SHA384) | | 864 +-----+-------------+---------------+---------------+---------------+ 865 |224 |Ed448 |Ed448 |ECDH (X448) | | 866 | | |(SHAKE256) | | | 867 +-----+-------------+---------------+---------------+---------------+ 868 |256 |secp521r1 |ECDSA |ECDH | AES-256 | 869 | | |(secp521r1, |(secp521r1, | | 870 | | |SHA512 or |SHA512), | | 871 | | |SHAKE256), |PBKDF2 (HMAC- | | 872 | | |PBMAC1 (HMAC- |SHA512) | | 873 | | |SHA512) | | | 874 +-----+-------------+---------------+---------------+---------------+ 876 Table 2: Cryptographic algorithms sorted by their bits of 877 security and usage by CMP 879 < ToDo: Table 1 and 2 above must be checked and confirmed by experts. 880 > 882 To avoid consuming too much computational resources it is recommended 883 to choose a set of algorithms offering roughly the same level of 884 security. Below are provided several algorithm profiles which are 885 balanced, assuming the implementer chooses MAC secrets and/or 886 certificate profiles of at least equivalent strength. 888 7.1. Algorithm Profile for RFC 4210 PKI Management Message Profiles 890 The following table updates the definitions of algorithms used within 891 PKI Management Message Profiles as defined in CMP Appendix D.2 892 [RFC4210]. 894 The columns in the table are: 896 Name: An identifier used for message profiles 898 Use: Description of where and for what the algorithm is used 900 Mandatory: Algorithms which MUST be supported by conforming 901 implementations 903 Optional: Algorithms which are OPTIONAL to support 905 Deprecated: Algorithms from RFC 4210 [RFC4210] which SHOULD NOT be 906 used anymore 908 +============+=============+=========+=================+============+ 909 |Name |Use |Mandatory|Optional |Deprecated | 910 +============+=============+=========+=================+============+ 911 |MSG_SIG_ALG |protection of|RSA |ECDSA, EdDSA |DSA, | 912 | |PKI messages | | |combinations| 913 | |using | | |with MD5 and| 914 | |signature | | |SHA-1 | 915 +------------+-------------+---------+-----------------+------------+ 916 |MSG_MAC_ALG |protection of|PBMAC1 |PasswordBasedMac,|X9.9 | 917 | |PKI messages | |HMAC, KMAC | | 918 | |using MACing | | | | 919 +------------+-------------+---------+-----------------+------------+ 920 |SYM_PENC_ALG|symmetric |AES-wrap | |3-DES(3-key-| 921 | |encryption of| | |EDE, CBC | 922 | |an end | | |Mode), RC5, | 923 | |entity's | | |CAST-128 | 924 | |private key | | | | 925 | |where | | | | 926 | |symmetric key| | | | 927 | |is | | | | 928 | |distributed | | | | 929 | |out-of-band | | | | 930 +------------+-------------+---------+-----------------+------------+ 931 |PROT_ENC_ALG|asymmetric |D-H |ECDH, RSA | | 932 | |algorithm | | | | 933 | |used for | | | | 934 | |encryption of| | | | 935 | |(symmetric | | | | 936 | |keys for | | | | 937 | |encryption | | | | 938 | |of) private | | | | 939 | |keys | | | | 940 | |transported | | | | 941 | |in | | | | 942 | |PKIMessages | | | | 943 +------------+-------------+---------+-----------------+------------+ 944 |PROT_SYM_ALG|symmetric |AES-CBC | |3-DES(3-key-| 945 | |encryption | | |EDE, CBC | 946 | |algorithm | | |Mode), RC5, | 947 | |used for | | |CAST-128 | 948 | |encryption of| | | | 949 | |private key | | | | 950 | |bits (a key | | | | 951 | |of this type | | | | 952 | |is encrypted | | | | 953 | |using | | | | 954 | |PROT_ENC_ALG)| | | | 955 +------------+-------------+---------+-----------------+------------+ 957 Table 3: Algorithms used within RFC 4210 Appendix D.2 [RFC4210] 959 Mandatory Algorithm Identifiers and Specifications: 961 RSA: sha256WithRSAEncryption with 2048 bit, see Section 3.1 963 PasswordBasedMac: id-PasswordBasedMac, see Section 6.1 (with id- 964 sha256 as the owf parameter, see Section 2.1 and id-hmacWithSHA256 as 965 the mac parameter, see Section 6.2.1) 966 PBMAC1: id-PBMAC1, see Section 6.1.2 (with id-PBKDF2 as the key 967 derivation function, see Section 4.4.1 and id-hmacWithSHA256 as 968 message authentication scheme, see Section 6.2.1). It is RECOMMENDED 969 to prefer the usage of PBMAC1 instead of PasswordBasedMac. 971 D-H: id-alg-ESDH, see Section 4.1.1 973 AES-wrap: id-aes128-wrap, see Section 4.3.1 975 AES-CBC: id-aes128-CBC, see Section 5.1 977 7.2. Algorithm Profile for Lightweight CMP Profile 979 The following table contains definitions of algorithms which MAY be 980 supported by implementations of the Lightweight CMP Profile 981 [I-D.ietf-lamps-lightweight-cmp-profile]. 983 As the set of algorithms to be used for implementations of the 984 Lightweight CMP Profile heavily depends on the PKI management 985 operations implemented, the certificates used for messages 986 protection, and the certificates to be managed, this document will 987 not specify a specific set that is mandatory to support for 988 conforming implementations. 990 The columns in the table are: 992 Name: An identifier used for message profiles 994 Use: Description of where and for what the algorithm is used 996 Examples: Lists the algorithms as described in this document. The 997 list of algorithms depends on the set of PKI management operations to 998 be implemented. 1000 Note: It is RECOMMENDED to prefer the usage of PBMAC1 instead of 1001 PasswordBasedMac. 1003 +==============+================================+==================+ 1004 | Name | Use | Examples | 1005 +==============+================================+==================+ 1006 | MSG_SIG_ALG | protection of PKI messages | RSA, ECDSA, | 1007 | | using signature and for | EdDSA | 1008 | | SignedData, e.g., a private | | 1009 | | key transported in PKIMessages | | 1010 +--------------+--------------------------------+------------------+ 1011 | MSG_MAC_ALG | protection of PKI messages | PasswordBasedMac | 1012 | | using MACing | (see Section 9), | 1013 | | | PBMAC1, HMAC, | 1014 | | | KMAC | 1015 +--------------+--------------------------------+------------------+ 1016 | KM_KA_ALG | asymmetric key agreement | D-H, ECDH | 1017 | | algorithm used for agreement | | 1018 | | of a symmetric key for use | | 1019 | | with KM_KW_ALG | | 1020 +--------------+--------------------------------+------------------+ 1021 | KM_KT_ALG | asymmetric key encryption | RSA | 1022 | | algorithm used for transport | | 1023 | | of a symmetric key for | | 1024 | | PROT_SYM_ALG | | 1025 +--------------+--------------------------------+------------------+ 1026 | KM_KD_ALG | symmetric key derivation | PBKDF2 | 1027 | | algorithm used for derivation | | 1028 | | of a symmetric key for use | | 1029 | | with KM_KW_ALG | | 1030 +--------------+--------------------------------+------------------+ 1031 | KM_KW_ALG | algorithm to wrap a symmetric | AES-wrap | 1032 | | key for PROT_SYM_ALG | | 1033 +--------------+--------------------------------+------------------+ 1034 | PROT_SYM_ALG | symmetric content encryption | AES-CBC | 1035 | | algorithm used for encryption | | 1036 | | of EnvelopedData, e.g., a | | 1037 | | private key transported in | | 1038 | | PKIMessages | | 1039 +--------------+--------------------------------+------------------+ 1041 Table 4: Algorithms used within Lightweight CMP Profile 1042 [I-D.ietf-lamps-lightweight-cmp-profile] 1044 8. IANA Considerations 1046 This document does not request changes to the IANA registry. 1048 9. Security Considerations 1050 RFC 4210 Appendix D.2 [RFC4210] contains a set of algorithms, 1051 mandatory to be supported by conforming implementations. Theses 1052 algorithms were appropriate at the time CMP was released, but as 1053 cryptographic algorithms weaken over time, some of them should not be 1054 used anymore. In general, new attacks are emerging due to research 1055 cryptoanalysis or increase in computing power. New algorithms were 1056 introduced that are more resistant to today's attacks. 1058 This document lists many cryptographic algorithms usable with CMP to 1059 offer implementer a more up to date choice. Finally, the algorithms 1060 to be supported also heavily depend on the certificates and PKI 1061 management operations utilized in the target environment. The 1062 algorithm with the lowest security strength and the entropy of shared 1063 secret information define the security of the overall solution, see 1064 Section 7. 1066 SHAKE is an extendable-output function and FIPS Pub 202 1067 [NIST.FIPS.202] prohibits using SHAKE as general-purpose hash 1068 function. To prevent known attacks SHAKE MUST only be used as hash 1069 function within CMP [RFC4210] and CMP Updates 1070 [I-D.ietf-lamps-cmp-updates] if the output length is fixed to d=256 1071 for SHAKE128 and d=512 for SHAKE256 as described in [RFC8702] and 1072 MUST NOT be used with different output lengths. 1074 < ToDo: The above security consideration must be checked and 1075 confirmed by experts. > 1077 When using MAC-based message protection the use of PBMAC1 is 1078 preferable to that of PasswordBasedMac. First, PBMAC1 is a well- 1079 known scrutinized algorithm, which is not true for PasswordBasedMac. 1080 Second, the PasswordBasedMac algorithm as specified in RFC 4211 1081 Section 4.4 [RFC4211] is essentially PBKDF1 (as defined in RFC 8018 1082 Section 5.1 [RFC8018]) with an HMAC step at the end. Here we update 1083 to use the PBKDF2-HMAC construct defined as PBMAC1 in [RFC8018]. 1084 PBKDF2 is superior to PBKDF1 in an improved internal construct for 1085 iterated hashing, and in removing PBKDF1's limitation of only being 1086 able to derive keys up to the size of the underlying hash function. 1087 Additionally, PBKDF1 is not recommended for new applications as 1088 stated in Section 5.1 of RFC 8018 [RFC8018] and no longer an approved 1089 algorithm by most standards bodies, and therefore presents 1090 difficulties to implementer who are submitting their CMP 1091 implementations for certification, hence moving to a PBKDF2-based 1092 mechanism. This change is in alignment with [RFC9045] which updates 1093 [RFC4211] to allow the use of PBMAC1 in CRMF. 1095 AES-GMAC MUST NOT be used as the pseudo random function in PBKDF2; 1096 the use of AES-GMAC more than once with the same key and the same 1097 nonce will break the security. 1099 Currently it is assumed that the advantage of a HW implementation 1100 over a SW implementation of KMAC is greater than of HMAC-SHA2. 1101 Therefore, the advantage of an attacker is greater if KMAC is used as 1102 a prf in PasswordBasedMac and PBKDF2. For this reason, the use of 1103 KMAC as a prf in PasswordBasedMac and PBKDF2 is discouraged. 1105 < ToDo: This security consideration must be checked and confirmed by 1106 experts. > 1108 In Section 7 of this document there is also an update to the 1109 Appendix D.2 of RFC 4210 [RFC4210] and a set of algorithms that MAY 1110 be supported when implementing the Lightweight CMP Profile 1111 [I-D.ietf-lamps-lightweight-cmp-profile]. 1113 It is recognized that there may be older CMP implementations in use 1114 that conform to the algorithm use profile from Appendix D.2 of 1115 RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for 1116 PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory. 1117 Therefore, it is expected that many CMP systems may already support 1118 the recommended algorithms in this specification. In such systems 1119 the weakened algorithms should be disabled from further use. If 1120 critical systems cannot be immediately updated to conform to the 1121 recommended algorithm use profile, it is recommended a plan to 1122 migrate the infrastructure to conforming profiles be adopted as soon 1123 as possible. 1125 Symmetric key-based MAC algorithms as described in Section 6.2 MAY be 1126 used as MSG_MAC_ALG. The implementer MUST choose a suitable PRF and 1127 ensure that the key has sufficient entropy to match the overall 1128 security level of the algorithm profile. These considerations are 1129 outside the scope of the profile. 1131 10. Acknowledgements 1133 Thanks to Russ Housley for supporting this draft with submitting 1134 [RFC9044] and [RFC9045]. 1136 May thanks also to all reviewers like Serge Mister, Mark Ferreira, 1137 Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steffen 1138 Fries for their input and feedback to this document. Apologies to 1139 all not mentioned reviewers and supporters. 1141 11. Normative References 1143 [I-D.ietf-lamps-cmp-updates] 1144 Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate 1145 Management Protocol (CMP) Updates", Work in Progress, 1146 Internet-Draft, draft-ietf-lamps-cmp-updates-13, 25 1147 October 2021, . 1150 [I-D.ietf-lamps-lightweight-cmp-profile] 1151 Brockhaus, H., Fries, S., and D. V. Oheimb, "Lightweight 1152 Certificate Management Protocol (CMP) Profile", Work in 1153 Progress, Internet-Draft, draft-ietf-lamps-lightweight- 1154 cmp-profile-07, 25 October 2021, 1155 . 1158 [NIST.FIPS.180-4] 1159 Dang, Quynh H., "Secure Hash Standard", NIST NIST FIPS 1160 180-4, DOI 10.6028/NIST.FIPS.180-4, July 2015, 1161 . 1164 [NIST.FIPS.186-4] 1165 National Institute of Standards and Technology (NIST), 1166 "Digital Signature Standard (DSS)", NIST NIST FIPS 186-4, 1167 DOI 10.6028/NIST.FIPS.186-4, July 2013, 1168 . 1171 [NIST.FIPS.186-5] 1172 National Institute of Standards and Technology (NIST), 1173 "FIPS Pub 186-5 (Draft): Digital Signature Standard 1174 (DSS)", October 2019, 1175 . 1178 [NIST.FIPS.197] 1179 National Institute of Standards and Technology (NIST), 1180 "Advanced encryption standard (AES)", NIST NIST FIPS 197, 1181 DOI 10.6028/NIST.FIPS.197, November 2001, 1182 . 1185 [NIST.FIPS.198-1] 1186 National Institute of Standards and Technology (NIST), 1187 "The Keyed-Hash Message Authentication Code (HMAC)", 1188 NIST NIST FIPS 198-1, DOI 10.6028/NIST.FIPS.198-1, July 1189 2008, . 1192 [NIST.FIPS.202] 1193 Dworkin, Morris J., "SHA-3 Standard: Permutation-Based 1194 Hash and Extendable-Output Functions", NIST NIST FIPS 202, 1195 DOI 10.6028/NIST.FIPS.202, July 2015, 1196 . 1199 [NIST.SP.800-185] 1200 Kelsey, John., Change, Shu-jen., and Ray. Perlner, "SHA-3 1201 derived functions: cSHAKE, KMAC, TupleHash and 1202 ParallelHash", NIST NIST SP 800-185, 1203 DOI 10.6028/NIST.SP.800-185, December 2016, 1204 . 1207 [NIST.SP.800-38d] 1208 Dworkin, M J., "Recommendation for block cipher modes of 1209 operation :GaloisCounter Mode (GCM) and GMAC", NIST NIST 1210 SP 800-38d, DOI 10.6028/NIST.SP.800-38d, 2007, 1211 . 1214 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1215 Hashing for Message Authentication", RFC 2104, 1216 DOI 10.17487/RFC2104, February 1997, 1217 . 1219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1220 Requirement Levels", BCP 14, RFC 2119, 1221 DOI 10.17487/RFC2119, March 1997, 1222 . 1224 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1225 RFC 2631, DOI 10.17487/RFC2631, June 1999, 1226 . 1228 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1229 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 1230 . 1232 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1233 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 1234 September 2002, . 1236 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport 1237 Algorithm in Cryptographic Message Syntax (CMS)", 1238 RFC 3560, DOI 10.17487/RFC3560, July 2003, 1239 . 1241 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1242 Encryption Algorithm in Cryptographic Message Syntax 1243 (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, 1244 . 1246 [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in 1247 Cryptographic Message Syntax (CMS)", RFC 4056, 1248 DOI 10.17487/RFC4056, June 2005, 1249 . 1251 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1252 "Internet X.509 Public Key Infrastructure Certificate 1253 Management Protocol (CMP)", RFC 4210, 1254 DOI 10.17487/RFC4210, September 2005, 1255 . 1257 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1258 Certificate Request Message Format (CRMF)", RFC 4211, 1259 DOI 10.17487/RFC4211, September 2005, 1260 . 1262 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 1263 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 1264 RFC 4231, DOI 10.17487/RFC4231, December 2005, 1265 . 1267 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1268 "Elliptic Curve Cryptography Subject Public Key 1269 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 1270 . 1272 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1273 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1274 . 1276 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 1277 Cryptography (ECC) Algorithms in Cryptographic Message 1278 Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 1279 2010, . 1281 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 1282 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 1283 2010, . 1285 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1286 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1287 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1288 . 1290 [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: 1291 Password-Based Cryptography Specification Version 2.1", 1292 RFC 8018, DOI 10.17487/RFC8018, January 2017, 1293 . 1295 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1296 Signature Algorithm (EdDSA)", RFC 8032, 1297 DOI 10.17487/RFC8032, January 2017, 1298 . 1300 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1301 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1302 May 2017, . 1304 [RFC8418] Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key 1305 Agreement Algorithm with X25519 and X448 in the 1306 Cryptographic Message Syntax (CMS)", RFC 8418, 1307 DOI 10.17487/RFC8418, August 2018, 1308 . 1310 [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature 1311 Algorithm (EdDSA) Signatures in the Cryptographic Message 1312 Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 1313 2018, . 1315 [RFC8702] Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash 1316 Functions in the Cryptographic Message Syntax (CMS)", 1317 RFC 8702, DOI 10.17487/RFC8702, January 2020, 1318 . 1320 [RFC9044] Housley, R., "Using the AES-GMAC Algorithm with the 1321 Cryptographic Message Syntax (CMS)", RFC 9044, 1322 DOI 10.17487/RFC9044, June 2021, 1323 . 1325 [RFC9045] Housley, R., "Algorithm Requirements Update to the 1326 Internet X.509 Public Key Infrastructure Certificate 1327 Request Message Format (CRMF)", RFC 9045, 1328 DOI 10.17487/RFC9045, June 2021, 1329 . 1331 12. Informative References 1333 [ECRYPT.CSA.D5.4] 1334 University of Bristol, "Algorithms, Key Size and Protocols 1335 Report (2018)", March 2015, 1336 . 1339 [NIST.SP.800-57pt1r5] 1340 Barker, Elaine., "Recommendation for key management:part 1 1341 - general", NIST NIST SP 800-57pt1r5, 1342 DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, 1343 . 1346 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1347 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1348 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 1349 April 2019, . 1351 [RFC8692] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key 1352 Infrastructure: Additional Algorithm Identifiers for 1353 RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, 1354 DOI 10.17487/RFC8692, December 2019, 1355 . 1357 Appendix A. History of changes 1359 Note: This appendix will be deleted in the final version of the 1360 document. 1362 From version 07 -> 08: 1364 * Fixing issues from WG and AD review 1365 * Adding Note to Section 2.2, 3.3, and 6.2.3 regarding usage of 1366 SHAKE and KMAC and added ToDo regarding checking respective notes 1367 * Added two tables showing algorithms sorted by their strength to 1368 Section 7 and added ToDo regarding checking theses tables 1369 * Updates the algorithm use profile in Section 7.1 1370 * Updated and added security consideration on SHAKE, 1371 PasswordBasedMac, KMAC, and symmetric key-based MAC functions and 1372 added ToDo regarding checking the security consideration on SHAKE 1374 From version 06 -> 07: 1376 * Fixing minor formatting nits 1378 From version 05 -> 06: 1380 * Added text to Section 2 and Section 3.3 to clearly specify the 1381 hash algorithm to use for certConf messages for certificates 1382 signed with EdDSA (see thread "[CMP Updates] Hash algorithm to us 1383 for calculating certHash") 1384 * Updated new RFC numbers for I-D.ietf-lamps-cms-aes-gmac-alg and I- 1385 D.ietf-lamps-crmf-update-algs 1387 From version 04 -> 05: 1389 * Minor changes and corrections in wording 1391 From version 03 -> 04: 1393 * Added John Gray to the list of authors due to his extensive 1394 support and valuable feedback 1395 * Added some clarification of the use AES-GMAC to Section 6.2.1 1396 * Extended the guidance on how to select a set of algorithms in 1397 Section 7 and deleted former Section 7.1 1398 * Deleted the algorithms mandatory to support in Section 7.2 as 1399 discussed at IETF 110 1400 * Extended the Security considerations in Section 9 1401 * Minor changes in wording 1403 From version 02 -> 03: 1405 * Moved former Appendix A to new Section 7 as suggested by Rich and 1406 Russ (see thread "I-D Action: draft-ietf-lamps-cmp-algorithms- 1407 02.txt") 1408 * Added a column to Table 1 in Section 7.2 to reflect the changes to 1409 RFC 4210 1410 * Updated Table 2 in Section 7.3 1411 * Added a paragraph to Section 9 to discuss backward compatibility 1412 with RFC 4210 1413 * Minor changes in wording 1415 From version 01 -> 02: 1417 * Added Hans Aschauer, Mike Ounsworth, and Serge Mister as co-author 1418 * Changed to XML V3 1419 * Added SHAKE digest algorithm to Section 2 as discussed at IETF 109 1420 * Deleted DSA from Section 3 as discussed at IETF 109 1421 * Added RSASSA-PSS with SHAKE to Section 3 1422 * Added SECP curves the section on ECDSA with SHA2, ECDSA with 1423 SHAKE, and EdDSA to Section 3 as discussed at IETF 109 1424 * Deleted static-static D-H and ECDH from Section 4.1 based on the 1425 discussion on the mailing list (see thread "[CMP Algorithms] 1426 Section 4.1.1 and 4.1.2 drop static-static (EC)DH key agreement 1427 algorithms for use in CMP") 1428 * Added ECDH OIDs and SECP curves, as well as ECDH with curve25519 1429 and curve448 to Section 4.1 as discussed at IETF 109 1430 * Deleted RSA-OAEP from Section 4.2 first as discussed at IETF 109, 1431 but re-added it after discussion on the mailing list (see thread 1432 "Mail regarding draft-ietf-lamps-cmp-algorithms") 1434 * Added a paragraph to Section 4.3.1 to explain that the algorithms 1435 and key length for content encryption and key wrapping must be 1436 aligned as discussed on the mailing list (see thread "[CMP 1437 Algorithms] Use Key-Wrap with or without padding in Section 4.3 1438 and Section 5") 1439 * Deleted AES-CCM and AES-GMC from and added AES-CBC to Section 5 as 1440 discussed at IETF 109 1441 * Added Section 6.1.2 to offer PBMAC1 as discusses on the mailing 1442 list (see thread "Mail regarding draft-ietf-lamps-crmf-update- 1443 algs-02") and restructured text in Section 6 to be easier to 1444 differentiate between password- and shared-key-based MAC 1445 * Deleted Diffie-Hellmann based MAC from Section 6 as is only 1446 relevant when using enrolling Diffie-Hellmann certificates 1447 * Added AES-GMAC and SHAKE-based KMAC to Section 6 as discussed at 1448 IETF 109 1449 * Extended Section 9 to mention Russ supporting with two additional 1450 I-Ds and name further supporters of the draft 1451 * Added a first draft of a generic algorithm selection guideline to 1452 Appendix A 1453 * Added a first proposal for mandatory algorithms for the 1454 Lightweight CMP Profile to Appendix A 1455 * Minor changes in wording 1457 From version 00 -> 01: 1459 * Changed sections Symmetric Key-Encryption Algorithms and Content 1460 Encryption Algorithms based on the discussion on the mailing list 1461 (see thread "[CMP Algorithms] Use Key-Wrap with or without padding 1462 in Section 4.3 and Section 5") 1463 * Added Appendix A with updated algorithms profile for RDC4210 1464 Appendix D.2 and first proposal for the Lightweight CMP Profile 1465 * Minor changes in wording 1467 Authors' Addresses 1469 Hendrik Brockhaus (editor) 1470 Siemens AG 1472 Email: hendrik.brockhaus@siemens.com 1474 Hans Aschauer 1475 Siemens AG 1477 Email: hans.aschauer@siemens.com 1478 Mike Ounsworth 1479 Entrust 1481 Email: mike.ounsworth@entrust.com 1483 John Gray 1484 Entrust 1486 Email: john.gray@entrust.com