idnits 2.17.1 draft-ietf-lamps-cmp-algorithms-09.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 December 2021) is 856 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-15 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-09 ** 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: 25 June 2022 J. Gray 7 Entrust 8 22 December 2021 10 Certificate Management Protocol (CMP) Algorithms 11 draft-ietf-lamps-cmp-algorithms-09 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 25 June 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 Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Message Digest Algorithms . . . . . . . . . . . . . . . . . . 3 68 2.1. SHA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.2. SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5 71 3.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.2. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.3. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4. Key Management Algorithms . . . . . . . . . . . . . . . . . . 8 75 4.1. Key Agreement Algorithms . . . . . . . . . . . . . . . . 8 76 4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 8 77 4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 10 79 4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 4.3. Symmetric Key-Encryption Algorithms . . . . . . . . . . . 11 81 4.3.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 11 82 4.4. Key Derivation Algorithms . . . . . . . . . . . . . . . . 12 83 4.4.1. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . 12 84 5. Content Encryption Algorithms . . . . . . . . . . . . . . . . 13 85 5.1. AES-CBC . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 6. Message Authentication Code Algorithms . . . . . . . . . . . 14 87 6.1. Password-based MAC . . . . . . . . . . . . . . . . . . . 14 88 6.1.1. PasswordBasedMac . . . . . . . . . . . . . . . . . . 14 89 6.1.2. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . 15 91 6.2. Symmetric key-based MAC . . . . . . . . . . . . . . . . . 15 92 6.2.1. SHA2-based HMAC . . . . . . . . . . . . . . . . . . . 15 93 6.2.2. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . 16 94 6.2.3. SHAKE-based KMAC . . . . . . . . . . . . . . . . . . 16 95 7. Algorithm Use Profiles . . . . . . . . . . . . . . . . . . . 17 96 7.1. Algorithm Profile for RFC 4210 PKI Management Message 97 Profiles . . . . . . . . . . . . . . . . . . . . . . . . 20 98 7.2. Algorithm Profile for Lightweight CMP Profile . . . . . . 22 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 101 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 102 11. Normative References . . . . . . . . . . . . . . . . . . . . 25 103 12. Informative References . . . . . . . . . . . . . . . . . . . 29 104 Appendix A. History of changes . . . . . . . . . . . . . . . . . 30 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 107 1. Introduction 109 1.1. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 2. Message Digest Algorithms 119 This section provides references to object identifiers and 120 conventions to be employed by CMP implementations that support SHA2 121 or SHAKE message digest algorithms. 123 Digest algorithm identifiers are located in: 125 * hashAlg field of OOBCertHash and CertStatus 126 * owf field of Challenge, PBMParameter, and DHBMParameter 127 * digestAlgorithms field of SignedData 128 * digestAlgorithm field of SignerInfo 130 Digest values are located in: 132 * hashVal field of OOBCertHash 133 * certHash field of CertStatus 134 * witness field of Challenge 136 In addition, digest values are input to signature algorithms. 138 2.1. SHA2 140 The SHA2 algorithm family is defined in FIPS Pub 180-4 141 [NIST.FIPS.180-4]. 143 The message digest algorithms SHA-224, SHA-256, SHA-384, and SHA-512 144 are identified by the following OIDs: 146 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 147 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 148 hashalgs(2) 4 } 149 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 150 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 151 hashalgs(2) 1 } 152 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 153 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 154 hashalgs(2) 2 } 155 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 156 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 157 hashalgs(2) 3 } 159 Specific conventions to be considered are specified in RFC 5754 160 Section 2 [RFC5754]. 162 2.2. SHAKE 164 The SHA-3 family of hash functions is defined in FIPS Pub 202 165 [NIST.FIPS.202] and includes fixed output length variants SHA3-224, 166 SHA3-256, SHA3-384, and SHA3-512, as well as extendable-output 167 functions (SHAKEs) SHAKE128 and SHAKE256. Currently SHAKE128 and 168 SHAKE256 are the only members of the SHA3-family which are specified 169 for use in X.509 and PKIX [RFC8692], and CMS [RFC8702] as one-way 170 hash function for use with RSASSA-PSS and ECDSA as one-way hash 171 function for use with RSASSA-PSS and ECDSA. 173 SHAKE is an extendable-output function and FIPS Pub 202 174 [NIST.FIPS.202] prohibits using SHAKE as general-purpose hash 175 function. When SHAKE is used in CMP as a message digest algorithm, 176 the message digested by the SHAKE function MUST be appended with the 177 OCTET_STRING equivalent of "CMP_SHAKE128" for SHAKE128 and 178 "CMP_SHAKE256" for SHAKE 256 and the output length MUST be 256 bits 179 for SHAKE128 and 512 bits for SHAKE256. 181 < ToDo: This note must be checked and confirmed by experts. > 183 The message digest algorithms SHAKE128 and SHAKE256 are identified by 184 the following OIDs: 186 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 187 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 188 hashalgs(2) 11 } 189 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 190 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 191 hashalgs(2) 12 } 193 Specific conventions to be considered are specified in RFC 8702 194 Section 3.1 [RFC8702]. 196 3. Signature Algorithms 198 This section provides references to object identifiers and 199 conventions to be employed by CMP implementations that support RSA, 200 ECDSA, or EdDSA signature algorithms. 202 The signature algorithm is referred to as MSG_SIG_ALG in Section 7.2, 203 RFC 4210 Appendix D and E [RFC4210], and in the Lightweight CMP 204 Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 206 Signature algorithm identifiers are located in: 208 * protectionAlg field of PKIHeader 209 * algorithmIdentifier field of POPOSigningKey 210 * signatureAlgorithm field of CertificationRequest, 211 SignKeyPairTypes, and SignerInfo 213 Signature values are located in: 215 * protection field of PKIMessage 216 * signature field of POPOSigningKey 217 * signature field of CertificationRequest and SignerInfo 219 3.1. RSA 221 The RSA (RSASSA-PSS and PKCS#1 version 1.5) signature algorithm is 222 defined in RFC 8017 [RFC8017]. 224 The algorithm identifier for RSASAA-PSS signatures used with SHA2 225 message digest algorithms is identified by the following OID: 227 id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2) 228 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 } 230 Specific conventions to be considered are specified in RFC 4056 231 [RFC4056]. 233 The signature algorithm RSASSA-PSS used with SHAKE message digest 234 algorithms are identified by the following OIDs: 236 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) 237 identified-organization(3) dod(6) internet(1) security(5) 238 mechanisms(5) pkix(7) algorithms(6) 30 } 239 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) 240 identified-organization(3) dod(6) internet(1) security(5) 241 mechanisms(5) pkix(7) algorithms(6) 31 } 243 Specific conventions to be considered are specified in RFC 8702 244 Section 3.2.1 [RFC8702]. 246 The signature algorithm PKCS#1 version 1.5 used with SHA2 message 247 digest algorithms is identified by the following OIDs: 249 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 250 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } 251 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 252 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } 253 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 254 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } 255 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 256 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } 258 Specific conventions to be considered are specified in RFC 5754 259 Section 3.2 [RFC5754]. 261 3.2. ECDSA 263 The ECDSA signature algorithm is defined in FIPS Pub 186-4 264 [NIST.FIPS.186-4]. 266 The signature algorithm ECDSA used with SHA2 message digest 267 algorithms is identified by the following OIDs: 269 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 270 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } 271 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 272 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 273 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 274 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 275 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 276 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 278 As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves 279 are identified by the following OIDs: 281 secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 282 us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } 283 secp224r1 OBJECT IDENTIFIER ::= { iso(1) 284 identified-organization(3) certicom(132) curve(0) 33 } 285 secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 286 us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } 287 secp384r1 OBJECT IDENTIFIER ::= { iso(1) 288 identified-organization(3) certicom(132) curve(0) 34 } 289 secp521r1 OBJECT IDENTIFIER ::= { iso(1) 290 identified-organization(3) certicom(132) curve(0) 35 } 292 Specific conventions to be considered are specified in RFC 5754 293 Section 3.3 [RFC5754]. 295 The signature algorithm ECDSA used with SHAKE message digest 296 algorithms are identified by the following OIDs: 298 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) 299 identified-organization(3) dod(6) internet(1) security(5) 300 mechanisms(5) pkix(7) algorithms(6) 32 } 301 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) 302 identified-organization(3) dod(6) internet(1) security(5) 303 mechanisms(5) pkix(7) algorithms(6) 33 } 305 Specific conventions to be considered are specified in RFC 8702 306 Section 3.2.2 [RFC8702]. 308 3.3. EdDSA 310 The EdDSA signature algorithm is defined in RFC 8032 Section 3.3 311 [RFC8032] and FIPS Pub 186-5 (Draft) [NIST.FIPS.186-5]. 313 The signature algorithm Ed25519 that MUST be used with SHA-512 314 message digest algorithms is identified by the following OIDs: 316 id-Ed25519 OBJECT IDENTIFIER ::= { iso(1) 317 identified-organization(3) thawte(101) 112 } 319 The signature algorithm Ed448 that MUST be used with SHAKE256 message 320 digest algorithms is identified by the following OIDs: 322 id-Ed448 OBJECT IDENTIFIER ::= { iso(1) 323 identified-organization(3) thawte(101) 113 } 325 Specific conventions to be considered are specified in RFC 8419 326 [RFC8419]. 328 Note: The hash algorithm used to calculate the certHash in certConf 329 messages MUST be SHA512 if the certificate to be confirmed has been 330 signed using Ed25519 and SHAKE256 with d=512 if signed using Ed448. 332 < ToDo: This note must be checked and confirmed by experts. > 334 4. Key Management Algorithms 336 CMP utilizes the following general key management techniques: key 337 agreement, key transport, and passwords. 339 CRMF [RFC4211] and CMP Updates [I-D.ietf-lamps-cmp-updates] promotes 340 the use of CMS [RFC5652] EnvelopedData by deprecating the use of 341 EncryptedValue. 343 4.1. Key Agreement Algorithms 345 The key agreement algorithm is referred to as PROT_ENC_ALG in 346 RFC 4210 Appendix D and E [RFC4210] and as KM_KA_ALG in the 347 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as 348 well as in Section 7. 350 Key agreement algorithms are only used in CMP when using CMS 351 [RFC5652] EnvelopedData together with the key agreement key 352 management technique. When a key agreement algorithm is used, a key- 353 encryption algorithm (Section 4.3) is needed next to the content- 354 encryption algorithm (Section 5). 356 Key agreement algorithm identifiers are located in: 358 * keyEncryptionAlgorithm field of KeyAgreeRecipientInfo 360 Key wrap algorithm identifiers are located in: 362 * KeyWrapAlgorithm parameters within keyEncryptionAlgorithm field of 363 KeyAgreeRecipientInfo 365 Wrapped content-encryption keys are located in: 367 * encryptedKey field of RecipientEncryptedKeys 369 4.1.1. Diffie-Hellman 371 Diffie-Hellman key agreement is defined in RFC 2631 [RFC2631] and 372 SHALL be used in the ephemeral-static as specified in RFC 3370 373 [RFC3370]. Static-static variants SHALL NOT be used. 375 The Diffie-Hellman key agreement algorithm is identified by the 376 following OID: 378 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) 379 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 381 Specific conventions to be considered are specified in RFC 3370 382 Section 4.1 [RFC3370]. 384 4.1.2. ECDH 386 Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined in 387 RFC 5753 [RFC5753] and SHALL be used in the ephemeral-static variant 388 as specified in RFC 5753 [RFC5753] or the 1-Pass ECMQV variant as 389 specified in RFC 5753 [RFC5753]. Static-static variants SHALL NOT be 390 used. 392 The ECDH key agreement algorithm used together with NIST-recommended 393 SECP curves are identified by the following OIDs: 395 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 396 identified-organization(3) certicom(132) schemes(1) 11(11) 0 } 397 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 398 identified-organization(3) certicom(132) schemes(1) 11(11) 1 } 399 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 400 identified-organization(3) certicom(132) schemes(1) 11(11) 2 } 401 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 402 identified-organization(3) certicom(132) schemes(1) 11(11) 3 } 403 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 404 iso(1) identified-organization(3) certicom(132) schemes(1) 405 14(14) 0 } 406 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 407 iso(1) identified-organization(3) certicom(132) schemes(1) 408 14(14) 1 } 409 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 410 iso(1) identified-organization(3) certicom(132) schemes(1) 411 14(14) 2 } 412 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 413 iso(1) identified-organization(3) certicom(132) schemes(1) 414 14(14) 3 } 415 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 416 identified-organization(3) certicom(132) schemes(1) 15(15) 0 } 417 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 418 identified-organization(3) certicom(132) schemes(1) 15(15) 1 } 419 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 420 identified-organization(3) certicom(132) schemes(1) 15(15) 2 } 421 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 422 identified-organization(3) certicom(132) schemes(1) 15(15) 3 } 424 As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves 425 are identified by the following OIDs: 427 secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 428 us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } 429 secp224r1 OBJECT IDENTIFIER ::= { iso(1) 430 identified-organization(3) certicom(132) curve(0) 33 } 431 secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 432 us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } 433 secp384r1 OBJECT IDENTIFIER ::= { iso(1) 434 identified-organization(3) certicom(132) curve(0) 34 } 435 secp521r1 OBJECT IDENTIFIER ::= { iso(1) 436 identified-organization(3) certicom(132) curve(0) 35 } 438 Specific conventions to be considered are specified in RFC 5753 439 [RFC5753]. 441 The ECDH key agreement algorithm used together with curve25519 or 442 curve448 are identified by the following OIDs: 444 id-X25519 OBJECT IDENTIFIER ::= { iso(1) 445 identified-organization(3) thawte(101) 110 } 446 id-X448 OBJECT IDENTIFIER ::= { iso(1) 447 identified-organization(3) thawte(101) 111 } 449 Specific conventions to be considered are specified in RFC 8418 450 [RFC8418]. 452 4.2. Key Transport Algorithms 454 The key transport algorithm is also referred to as PROT_ENC_ALG in 455 RFC 4210 Appendix D and E [RFC4210] and as KM_KL_ALG in the 456 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as 457 well as in Section 7. 459 Key transport algorithms are only used in CMP when using CMS 460 [RFC5652] EnvelopedData together with the key transport key 461 management technique. 463 Key transport algorithm identifiers are located in: 465 * keyEncryptionAlgorithm field of KeyTransRecipientInfo 467 Key transport encrypted content-encryption keys are located in: 469 * encryptedKey field of KeyTransRecipientInfo 471 4.2.1. RSA 473 The RSA key transport algorithm is the RSA encryption scheme defined 474 in RFC 8017 [RFC8017]. 476 The algorithm identifier for RSA (PKCS #1 v1.5) is: 478 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 479 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 481 The algorithm identifier for RSAES-OAEP is: 483 id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) 484 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } 486 Further conventions to be considered for PKCS #1 v1.5 are specified 487 in RFC 3370 Section 4.2.1 [RFC3370] and for RSAES-OAEP in RFC 3560 488 [RFC3560]. 490 4.3. Symmetric Key-Encryption Algorithms 492 The symmetric key-encryption algorithm is also referred to as 493 KM_KW_ALG in Section 7.2 and in the Lightweight CMP Profile 494 [I-D.ietf-lamps-lightweight-cmp-profile]. 496 As symmetric key-encryption key management technique is not used by 497 CMP, the symmetric key-encryption algorithm is only needed when using 498 the key agreement or password-based key management technique with CMS 499 [RFC5652] EnvelopedData. 501 Key wrap algorithm identifiers are located in: 503 * parameters field of the KeyEncryptionAlgorithmIdentifier of 504 KeyAgreeRecipientInfo and PasswordRecipientInfo 506 Wrapped content-encryption keys are located in: 508 * encryptedKey field of RecipientEncryptedKeys (for key agreement) 509 and PasswordRecipientInfo (for password-based key management) 511 4.3.1. AES Key Wrap 513 The AES encryption algorithm is defined in FIPS Pub 197 514 [NIST.FIPS.197] and the key wrapping is defined in RFC 3394 515 [RFC3394]. 517 AES key encryption has the algorithm identifier: 519 id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 520 country(16) us(840) organization(1) gov(101) csor(3) 521 nistAlgorithm(4) aes(1) 5 } 522 id-aes192-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 523 country(16) us(840) organization(1) gov(101) csor(3) 524 nistAlgorithm(4) aes(1) 25 } 525 id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 526 country(16) us(840) organization(1) gov(101) csor(3) 527 nistAlgorithm(4) aes(1) 45 } 529 The underlying encryption functions for the key wrap and content- 530 encryption algorithms (as specified in Section 5) and the key sizes 531 for the two algorithms MUST be the same (e.g., AES-128 key wrap 532 algorithm with AES-128 content-encryption algorithm), see also 533 RFC 8551 [RFC8551]. 535 Further conventions to be considered for AES key wrap are specified 536 in RFC 3394 Section 2.2 [RFC3394] and RFC 3565 Section 2.3.2 537 [RFC3565]. 539 4.4. Key Derivation Algorithms 541 The key derivation algorithm is also referred to as KM_KD_ALG in 542 Section 7.2 and in the Lightweight CMP Profile 543 [I-D.ietf-lamps-lightweight-cmp-profile]. 545 Key derivation algorithms are only used in CMP when using CMS 546 [RFC5652] EnvelopedData together with password-based key management 547 technique. 549 Key derivation algorithm identifiers are located in: 551 * keyDerivationAlgorithm field of PasswordRecipientInfo 553 When using the password-based key management technique with 554 EnvelopedData as specified in CMP Updates together with MAC-based 555 PKIProtection, the salt for the password-based MAC and KDF must be 556 chosen independently to ensure usage of independent symmetric keys. 558 4.4.1. PBKDF2 560 The password-based key derivation function 2 (PBKDF2) is defined in 561 RFC 8018 [RFC8018]. 563 Password-based key derivation function 2 has the algorithm 564 identifier: 566 id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 567 rsadsi(113549) pkcs(1) pkcs-5(5) 12 } 569 Further conventions to be considered for PBKDF2 are specified in 570 RFC 3370 Section 4.4.1 [RFC3370] and RFC 8018 Section 5.2 [RFC8018]. 572 5. Content Encryption Algorithms 574 The content encryption algorithm is also referred to as PROT_SYM_ALG 575 in Section 7, RFC 4210 Appendix D and E [RFC4210], and the 576 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 578 Content encryption algorithms are only used in CMP when using CMS 579 [RFC5652] EnvelopedData to transport a signed private key package in 580 case of central key generation or key archiving, a certificate to 581 facilitate implicit proof-of-possession, or a revocation passphrase 582 in encrypted form. 584 Content encryption algorithm identifiers are located in: 586 * contentEncryptionAlgorithm field of EncryptedContentInfo 588 Encrypted content is located in: 590 * encryptedContent field of EncryptedContentInfo 592 5.1. AES-CBC 594 The AES encryption algorithm is defined in FIPS Pub 197 595 [NIST.FIPS.197]. 597 AES-CBC content encryption has the algorithm identifier: 599 id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 600 country(16) us(840) organization(1) gov(101) csor(3) 601 nistAlgorithm(4) aes(1) 2 } 602 id-aes192-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 603 country(16) us(840) organization(1) gov(101) csor(3) 604 nistAlgorithm(4) aes(1)22 } 605 id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 606 country(16) us(840) organization(1) gov(101) csor(3) 607 nistAlgorithm(4) aes(1)42 } 609 Specific conventions to be considered for AES-CBC content encryption 610 are specified in RFC 3565 [RFC3565]. 612 6. Message Authentication Code Algorithms 614 The message authentication code is either used for shared secret- 615 based CMP message protection or together with the password-based key 616 derivation function (PBKDF2). 618 The message authentication code algorithm is also referred to as 619 MSG_MAC_ALG in Section 7, RFC 4210 Appendix D and E [RFC4210], and 620 the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 622 6.1. Password-based MAC 624 Password-based MAC algorithms combine the derivation of a symmetric 625 key from a password or other shared secret information and a 626 symmetric key-based MAC function as specified in Section 6.2 using 627 this derived key. 629 Message authentication code algorithm identifiers are located in: 631 * protectionAlg field of PKIHeader 633 Message authentication code values are located in: 635 * PKIProtection field of PKIMessage 637 6.1.1. PasswordBasedMac 639 The PasswordBasedMac algorithm is defined in RFC 4210 Section 5.1.3.1 640 [RFC4210], RFC 4211 Section 4.4 [RFC4211], and Algorithm Requirements 641 Update to the Internet X.509 Public Key Infrastructure Certificate 642 Request Message Format (CRMF) [RFC9045]. 644 The PasswordBasedMac algorithm is identified by the following OID: 646 id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 647 us(840) nt(113533) nsn(7) algorithms(66) 13 } 649 Further conventions to be considered for password-based MAC are 650 specified in RFC 4210 Section 5.1.3.1 [RFC4210], RFC 4211 Section 4.4 651 [RFC4211], and Algorithm Requirements Update to the Internet X.509 652 Public Key Infrastructure Certificate Request Message Format (CRMF) 653 [RFC9045]. 655 6.1.2. PBMAC1 657 The Password-Based Message Authentication Code 1 (PBMAC1) is defined 658 in RFC 8018 [RFC8018]. PBMAC1 combines a password-based key 659 derivation function like PBKDF2 (Section 4.4.1) with an underlying 660 symmetric key-based message authentication scheme. 662 PBMAC1 has the following OID: 664 id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 665 rsadsi(113549) pkcs(1) pkcs-5(5) 14 } 667 Specific conventions to be considered for PBMAC1 are specified in 668 RFC 8018 Section 7.1 and A.5 [RFC8018]. 670 6.2. Symmetric key-based MAC 672 Symmetric key-based MAC algorithms are used for deriving the 673 symmetric encryption key when using PBKDF2 as described in 674 Section 4.4.1 as well as with Password-based MAC as described in 675 Section 6.1. 677 Message authentication code algorithm identifiers are located in: 679 * protectionAlg field of PKIHeader 680 * messageAuthScheme field of PBMAC1 681 * mac field of PBMParameter 682 * prf field of PBKDF2-params 684 Message authentication code values are located in: 686 * PKIProtection field of PKIMessage 688 6.2.1. SHA2-based HMAC 690 The HMAC algorithm is defined in RFC 2104 [RFC2104] and 691 FIPS Pub 198-1 [NIST.FIPS.198-1]. 693 The HMAC algorithm used with SHA2 message digest algorithms is 694 identified by the following OIDs: 696 id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 697 us(840) rsadsi(113549) digestAlgorithm(2) 8 } 698 id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 699 us(840) rsadsi(113549) digestAlgorithm(2) 9 } 700 id-hmacWithSHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 701 us(840) rsadsi(113549) digestAlgorithm(2) 10 } 702 id-hmacWithSHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 703 us(840) rsadsi(113549) digestAlgorithm(2) 11 } 705 Specific conventions to be considered for SHA2-based HMAC are 706 specified in RFC 4231 Section 3.1 [RFC4231]. 708 6.2.2. AES-GMAC 710 The AES-GMAC algorithm is defined in FIPS Pub 197 [NIST.FIPS.197] and 711 NIST SP 800-38d [NIST.SP.800-38d]. 713 Note: AES-GMAC MUST NOT be used twice with the same parameter set, 714 especially the same nonce. Therefore, it MUST NOT be used together 715 with PBKDF2. When using it with PBMAC1 it MUST be ensured that AES- 716 GMAC is only used as message authentication scheme and not for the 717 key derivation function PBKDF2. 719 The AES-GMAC algorithm is identified by the following OIDs: 721 id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 722 country(16) us(840) organization(1) gov(101) csor(3) 723 nistAlgorithm(4) aes(1) 9 } 724 id-aes192-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 725 country(16) us(840) organization(1) gov(101) csor(3) 726 nistAlgorithm(4) aes(1) 29 } 727 id-aes256-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 728 country(16) us(840) organization(1) gov(101) csor(3) 729 nistAlgorithm(4) aes(1) 49 } 731 Specific conventions to be considered for AES-GMAC are specified in 732 RFC 9044 [RFC9044]. 734 6.2.3. SHAKE-based KMAC 736 The KMAC algorithm is defined in RFC 8702 [RFC8702] and 737 FIPS SP 800-185 [NIST.SP.800-185]. 739 Note: Currently it is assumed that the advantage of a HW 740 implementation over a SW implementation of KMAC is greater than of 741 HMAC-SHA2. Therefore, the advantage of an attacker is greater if 742 KMAC is used as a prf in PasswordBasedMac and PBKDF2. For this 743 reason, the use of KMAC as a prf in PasswordBasedMac and PBKDF2 is 744 discouraged. 746 < ToDo: This note must be checked and confirmed by experts. > 748 The SHAKE-based KMAC algorithm is identified by the following OIDs: 750 id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 751 country(16) us(840) organization(1) gov(101) csor(3) 752 nistAlgorithm(4) 2 19 } 753 id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 754 country(16) us(840) organization(1) gov(101) csor(3) 755 nistAlgorithm(4) 2 20 } 757 Specific conventions to be considered for KMAC with SHAKE are 758 specified in RFC 8702 Section 3.4 [RFC8702]. 760 7. Algorithm Use Profiles 762 This section provides profiles of algorithms and respective 763 conventions for different application use cases. 765 Recommendations like NIST SP 800-57 Recommendation for Key Management 766 Table2 [NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and 767 Protocols Report (2018) Section 4.6 [ECRYPT.CSA.D5.4] provide general 768 information on current cryptographic algorithms. 770 The overall cryptographic strength of a CMP deployment will depend on 771 several factors, including: 773 * Capabilities of the end entity: What kind of algorithms does the 774 end entity support. The cryptographic strength of the system 775 SHOULD be at least as strong as the algorithms and keys used for 776 the certificate being managed. 778 * Algorithm profile: The overall strength of the profile will be the 779 strength of the weakest algorithm it contains. 781 * Message protection: The overall strength of the CMC message 782 protection 784 - MAC-based protection: The entropy of the shared secret 785 information or password when MAC-based message protection is 786 used (MSG_MAC_ALG). 788 - Signature-based protection: The strength of the key pair and 789 signature algorithm when signature-based protection is used 790 (MSG_SIG_ALG). 792 - Protection of centrally generated keys: The strength of the 793 algorithms used for the key management technique (Section 7.2: 794 PROT_ENC_ALG or Section 7.1: KM_KA_ALG, KM_KT_ALG, KM_KD_ALG) 795 and the encryption of the content-encryption key and private 796 key (Section 7.2: SYM_PENC_ALG, PROT_SYM_ALG or Section 7.1: 797 KM_KW_ALG, PROT_SYM_ALG). 799 The following table shows the algorithms listed in this document 800 sorted by their bits of security. If an implementation intends to 801 enroll and manage certificate for keys of a specific security, it 802 SHALL implement and use algorithms of at least that strength for the 803 respective PKI management operation. If one column does not provide 804 a suitable algorithm, the implementer MUST choose one offering more 805 bits of security. 807 +========+===========+=========+=========+===============+==========+ 808 |Bits of |Recommended|RSA / D-H|Elliptic |Hash function |Symmetric | 809 |security|for | |curve |or XOF with |encryption| 810 | |managing | | |specified | | 811 | |keys up to | | |output length | | 812 | | | | |(d) | | 813 +========+===========+=========+=========+===============+==========+ 814 |112 |RSA2048 |RSA2048 |secp224r1|SHA224 | | 815 | |secp224r1 |D-H(2048)| | | | 816 +--------+-----------+---------+---------+---------------+----------+ 817 |128 |RSA3072 |RSA3072 |secp256r1|SHA256 |AES-128 | 818 | |secp256r1 |D-H(3072)|Ed25519/ |SHAKE128(d=256)| | 819 | |Ed25519 | |X25519 | | | 820 +--------+-----------+---------+---------+---------------+----------+ 821 |192 |secp384r1 | |secp384r1|SHA384 |AES-192 | 822 +--------+-----------+---------+---------+---------------+----------+ 823 |224 |Ed448 | |Ed448/ | | | 824 | | | |X448 | | | 825 +--------+-----------+---------+---------+---------------+----------+ 826 |256 |secp521r1 | |secp521r1|SHA512 |AES-256 | 827 | | | | |SHAKE256(d=512)| | 828 +--------+-----------+---------+---------+---------------+----------+ 830 Table 1: Cryptographic algorithms sorted by their bits of security 832 The following table shows the cryptographic algorithms sorted by 833 their usage in CMP and with more details. 835 +=====+=============+===============+===============+===============+ 836 |Bits |Recommended |CMP protection |Key management | Key-wrap and | 837 |of |for managing | |technique | symmetric | 838 |secu-|keys up to | | | encryption | 839 |rity | | | | | 840 +=====+=============+===============+===============+===============+ 841 | | |MSG_SIG_ALG, |PROT_ENC_ALG or| PROT_SYM_ALG, | 842 | | |MSG_MAC_ALG |KM_KA_ALG, | SYM_PENC_ALG | 843 | | | |KM_KT_ALG, | or | 844 | | | |KM_KD_ALG | KM_KW_ALG | 845 +-----+-------------+---------------+---------------+---------------+ 846 |112 |RSA2048, |RSASSA-PSS |ESDH (2048), | | 847 | |secp224r1 |(2048, SHA224 |RSAES-OAEP | | 848 | | |or SHAKE128), |(2048, SHA224),| | 849 | | |RSAEncryption |RSAEncryption | | 850 | | |(2048, SHA224),|(2048), | | 851 | | |ECDSA |ECDH | | 852 | | |(secp224r1, |(secp224r1, | | 853 | | |SHA224 or |SHA224), | | 854 | | |SHAKE128), |PBKDF2 (HMAC- | | 855 | | |PBMAC1 (HMAC- |SHA224) | | 856 | | |SHA224) | | | 857 +-----+-------------+---------------+---------------+---------------+ 858 |128 |RSA3072, |RSASSA-PSS |ESDH (3072), | AES-128 | 859 | |secp256r1, |(3072, SHA256 |RSAES-OAEP | | 860 | |Ed25519 |or SHAKE128), |(3072, SHA256),| | 861 | | |RSAEncryption |RSAEncryption | | 862 | | |(3072, SHA256),|(3072), | | 863 | | |ECDSA |ECDH | | 864 | | |(secp256r1, |(secp256r1, | | 865 | | |SHA256 or |SHA256), | | 866 | | |SHAKE128), |ECDH (X25519), | | 867 | | |Ed25519 |PBKDF2 (HMAC- | | 868 | | |(SHA512), |SHA256) | | 869 | | |PBMAC1 (HMAC- | | | 870 | | |SHA256) | | | 871 +-----+-------------+---------------+---------------+---------------+ 872 |192 |secp384r1 |ECDSA |ECDH | AES-192 | 873 | | |(secp384r1, |(secp384r1, | | 874 | | |SHA384), |SHA384), | | 875 | | |PBMAC1 (HMAC- |PBKDF2 (HMAC- | | 876 | | |SHA384) |SHA384) | | 877 +-----+-------------+---------------+---------------+---------------+ 878 |224 |Ed448 |Ed448 |ECDH (X448) | | 879 | | |(SHAKE256) | | | 880 +-----+-------------+---------------+---------------+---------------+ 881 |256 |secp521r1 |ECDSA |ECDH | AES-256 | 882 | | |(secp521r1, |(secp521r1, | | 883 | | |SHA512 or |SHA512), | | 884 | | |SHAKE256), |PBKDF2 (HMAC- | | 885 | | |PBMAC1 (HMAC- |SHA512) | | 886 | | |SHA512) | | | 887 +-----+-------------+---------------+---------------+---------------+ 889 Table 2: Cryptographic algorithms sorted by their bits of 890 security and usage by CMP 892 < ToDo: Table 1 and 2 above must be checked and confirmed by experts. 893 > 895 To avoid consuming too much computational resources it is recommended 896 to choose a set of algorithms offering roughly the same level of 897 security. Below are provided several algorithm profiles which are 898 balanced, assuming the implementer chooses MAC secrets and/or 899 certificate profiles of at least equivalent strength. 901 7.1. Algorithm Profile for RFC 4210 PKI Management Message Profiles 903 The following table updates the definitions of algorithms used within 904 PKI Management Message Profiles as defined in CMP Appendix D.2 905 [RFC4210]. 907 The columns in the table are: 909 Name: An identifier used for message profiles 911 Use: Description of where and for what the algorithm is used 913 Mandatory: Algorithms which MUST be supported by conforming 914 implementations 916 Optional: Algorithms which are OPTIONAL to support 918 Deprecated: Algorithms from RFC 4210 [RFC4210] which SHOULD NOT be 919 used anymore 921 +============+=============+=========+=================+============+ 922 |Name |Use |Mandatory|Optional |Deprecated | 923 +============+=============+=========+=================+============+ 924 |MSG_SIG_ALG |protection of|RSA |ECDSA, EdDSA |DSA, | 925 | |PKI messages | | |combinations| 926 | |using | | |with MD5 and| 927 | |signature | | |SHA-1 | 928 +------------+-------------+---------+-----------------+------------+ 929 |MSG_MAC_ALG |protection of|PBMAC1 |PasswordBasedMac,|X9.9 | 930 | |PKI messages | |HMAC, KMAC | | 931 | |using MACing | | | | 932 +------------+-------------+---------+-----------------+------------+ 933 |SYM_PENC_ALG|symmetric |AES-wrap | |3-DES(3-key-| 934 | |encryption of| | |EDE, CBC | 935 | |an end | | |Mode), RC5, | 936 | |entity's | | |CAST-128 | 937 | |private key | | | | 938 | |where | | | | 939 | |symmetric key| | | | 940 | |is | | | | 941 | |distributed | | | | 942 | |out-of-band | | | | 943 +------------+-------------+---------+-----------------+------------+ 944 |PROT_ENC_ALG|asymmetric |D-H |ECDH, RSA | | 945 | |algorithm | | | | 946 | |used for | | | | 947 | |encryption of| | | | 948 | |(symmetric | | | | 949 | |keys for | | | | 950 | |encryption | | | | 951 | |of) private | | | | 952 | |keys | | | | 953 | |transported | | | | 954 | |in | | | | 955 | |PKIMessages | | | | 956 +------------+-------------+---------+-----------------+------------+ 957 |PROT_SYM_ALG|symmetric |AES-CBC | |3-DES(3-key-| 958 | |encryption | | |EDE, CBC | 959 | |algorithm | | |Mode), RC5, | 960 | |used for | | |CAST-128 | 961 | |encryption of| | | | 962 | |private key | | | | 963 | |bits (a key | | | | 964 | |of this type | | | | 965 | |is encrypted | | | | 966 | |using | | | | 967 | |PROT_ENC_ALG)| | | | 968 +------------+-------------+---------+-----------------+------------+ 970 Table 3: Algorithms used within RFC 4210 Appendix D.2 [RFC4210] 972 Mandatory Algorithm Identifiers and Specifications: 974 RSA: sha256WithRSAEncryption with 2048 bit, see Section 3.1 976 PasswordBasedMac: id-PasswordBasedMac, see Section 6.1 (with id- 977 sha256 as the owf parameter, see Section 2.1 and id-hmacWithSHA256 as 978 the mac parameter, see Section 6.2.1) 979 PBMAC1: id-PBMAC1, see Section 6.1.2 (with id-PBKDF2 as the key 980 derivation function, see Section 4.4.1 and id-hmacWithSHA256 as 981 message authentication scheme, see Section 6.2.1). It is RECOMMENDED 982 to prefer the usage of PBMAC1 instead of PasswordBasedMac. 984 D-H: id-alg-ESDH, see Section 4.1.1 986 AES-wrap: id-aes128-wrap, see Section 4.3.1 988 AES-CBC: id-aes128-CBC, see Section 5.1 990 7.2. Algorithm Profile for Lightweight CMP Profile 992 The following table contains definitions of algorithms which MAY be 993 supported by implementations of the Lightweight CMP Profile 994 [I-D.ietf-lamps-lightweight-cmp-profile]. 996 As the set of algorithms to be used for implementations of the 997 Lightweight CMP Profile heavily depends on the PKI management 998 operations implemented, the certificates used for messages 999 protection, and the certificates to be managed, this document will 1000 not specify a specific set that is mandatory to support for 1001 conforming implementations. 1003 The columns in the table are: 1005 Name: An identifier used for message profiles 1007 Use: Description of where and for what the algorithm is used 1009 Examples: Lists the algorithms as described in this document. The 1010 list of algorithms depends on the set of PKI management operations to 1011 be implemented. 1013 Note: It is RECOMMENDED to prefer the usage of PBMAC1 instead of 1014 PasswordBasedMac. 1016 +==============+================================+==================+ 1017 | Name | Use | Examples | 1018 +==============+================================+==================+ 1019 | MSG_SIG_ALG | protection of PKI messages | RSA, ECDSA, | 1020 | | using signature and for | EdDSA | 1021 | | SignedData, e.g., a private | | 1022 | | key transported in PKIMessages | | 1023 +--------------+--------------------------------+------------------+ 1024 | MSG_MAC_ALG | protection of PKI messages | PasswordBasedMac | 1025 | | using MACing | (see Section 9), | 1026 | | | PBMAC1, HMAC, | 1027 | | | KMAC | 1028 +--------------+--------------------------------+------------------+ 1029 | KM_KA_ALG | asymmetric key agreement | D-H, ECDH | 1030 | | algorithm used for agreement | | 1031 | | of a symmetric key for use | | 1032 | | with KM_KW_ALG | | 1033 +--------------+--------------------------------+------------------+ 1034 | KM_KT_ALG | asymmetric key encryption | RSA | 1035 | | algorithm used for transport | | 1036 | | of a symmetric key for | | 1037 | | PROT_SYM_ALG | | 1038 +--------------+--------------------------------+------------------+ 1039 | KM_KD_ALG | symmetric key derivation | PBKDF2 | 1040 | | algorithm used for derivation | | 1041 | | of a symmetric key for use | | 1042 | | with KM_KW_ALG | | 1043 +--------------+--------------------------------+------------------+ 1044 | KM_KW_ALG | algorithm to wrap a symmetric | AES-wrap | 1045 | | key for PROT_SYM_ALG | | 1046 +--------------+--------------------------------+------------------+ 1047 | PROT_SYM_ALG | symmetric content encryption | AES-CBC | 1048 | | algorithm used for encryption | | 1049 | | of EnvelopedData, e.g., a | | 1050 | | private key transported in | | 1051 | | PKIMessages | | 1052 +--------------+--------------------------------+------------------+ 1054 Table 4: Algorithms used within Lightweight CMP Profile 1055 [I-D.ietf-lamps-lightweight-cmp-profile] 1057 8. IANA Considerations 1059 This document does not request changes to the IANA registry. 1061 9. Security Considerations 1063 RFC 4210 Appendix D.2 [RFC4210] contains a set of algorithms, 1064 mandatory to be supported by conforming implementations. Theses 1065 algorithms were appropriate at the time CMP was released, but as 1066 cryptographic algorithms weaken over time, some of them should not be 1067 used anymore. In general, new attacks are emerging due to research 1068 cryptoanalysis or increase in computing power. New algorithms were 1069 introduced that are more resistant to today's attacks. 1071 This document lists many cryptographic algorithms usable with CMP to 1072 offer implementer a more up to date choice. Finally, the algorithms 1073 to be supported also heavily depend on the certificates and PKI 1074 management operations utilized in the target environment. The 1075 algorithm with the lowest security strength and the entropy of shared 1076 secret information define the security of the overall solution, see 1077 Section 7. 1079 SHAKE is an extendable-output function and FIPS Pub 202 1080 [NIST.FIPS.202] prohibits using SHAKE as general-purpose hash 1081 function. To prevent known attacks SHAKE MUST only be used as hash 1082 function within CMP [RFC4210] and CMP Updates 1083 [I-D.ietf-lamps-cmp-updates] if the output length is fixed to d=256 1084 for SHAKE128 and d=512 for SHAKE256 as described in [RFC8702] and 1085 MUST NOT be used with different output lengths. 1087 < ToDo: The above security consideration must be checked and 1088 confirmed by experts. > 1090 When using MAC-based message protection the use of PBMAC1 is 1091 preferable to that of PasswordBasedMac. First, PBMAC1 is a well- 1092 known scrutinized algorithm, which is not true for PasswordBasedMac. 1093 Second, the PasswordBasedMac algorithm as specified in RFC 4211 1094 Section 4.4 [RFC4211] is essentially PBKDF1 (as defined in RFC 8018 1095 Section 5.1 [RFC8018]) with an HMAC step at the end. Here we update 1096 to use the PBKDF2-HMAC construct defined as PBMAC1 in [RFC8018]. 1097 PBKDF2 is superior to PBKDF1 in an improved internal construct for 1098 iterated hashing, and in removing PBKDF1's limitation of only being 1099 able to derive keys up to the size of the underlying hash function. 1100 Additionally, PBKDF1 is not recommended for new applications as 1101 stated in Section 5.1 of RFC 8018 [RFC8018] and no longer an approved 1102 algorithm by most standards bodies, and therefore presents 1103 difficulties to implementer who are submitting their CMP 1104 implementations for certification, hence moving to a PBKDF2-based 1105 mechanism. This change is in alignment with [RFC9045] which updates 1106 [RFC4211] to allow the use of PBMAC1 in CRMF. 1108 AES-GMAC MUST NOT be used as the pseudo random function in PBKDF2; 1109 the use of AES-GMAC more than once with the same key and the same 1110 nonce will break the security. 1112 Currently it is assumed that the advantage of a HW implementation 1113 over a SW implementation of KMAC is greater than of HMAC-SHA2. 1114 Therefore, the advantage of an attacker is greater if KMAC is used as 1115 a prf in PasswordBasedMac and PBKDF2. For this reason, the use of 1116 KMAC as a prf in PasswordBasedMac and PBKDF2 is discouraged. 1118 < ToDo: This security consideration must be checked and confirmed by 1119 experts. > 1121 In Section 7 of this document there is also an update to the 1122 Appendix D.2 of RFC 4210 [RFC4210] and a set of algorithms that MAY 1123 be supported when implementing the Lightweight CMP Profile 1124 [I-D.ietf-lamps-lightweight-cmp-profile]. 1126 It is recognized that there may be older CMP implementations in use 1127 that conform to the algorithm use profile from Appendix D.2 of 1128 RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for 1129 PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory. 1130 Therefore, it is expected that many CMP systems may already support 1131 the recommended algorithms in this specification. In such systems 1132 the weakened algorithms should be disabled from further use. If 1133 critical systems cannot be immediately updated to conform to the 1134 recommended algorithm use profile, it is recommended a plan to 1135 migrate the infrastructure to conforming profiles be adopted as soon 1136 as possible. 1138 Symmetric key-based MAC algorithms as described in Section 6.2 MAY be 1139 used as MSG_MAC_ALG. The implementer MUST choose a suitable PRF and 1140 ensure that the key has sufficient entropy to match the overall 1141 security level of the algorithm profile. These considerations are 1142 outside the scope of the profile. 1144 10. Acknowledgements 1146 Thanks to Russ Housley for supporting this draft with submitting 1147 [RFC9044] and [RFC9045]. 1149 May thanks also to all reviewers like Serge Mister, Mark Ferreira, 1150 Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steffen 1151 Fries for their input and feedback to this document. Apologies to 1152 all not mentioned reviewers and supporters. 1154 11. Normative References 1156 [I-D.ietf-lamps-cmp-updates] 1157 Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate 1158 Management Protocol (CMP) Updates", Work in Progress, 1159 Internet-Draft, draft-ietf-lamps-cmp-updates-15, 17 1160 December 2021, . 1163 [I-D.ietf-lamps-lightweight-cmp-profile] 1164 Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight 1165 Certificate Management Protocol (CMP) Profile", Work in 1166 Progress, Internet-Draft, draft-ietf-lamps-lightweight- 1167 cmp-profile-09, 17 December 2021, 1168 . 1171 [NIST.FIPS.180-4] 1172 Dang, Quynh H., "Secure Hash Standard", NIST NIST FIPS 1173 180-4, DOI 10.6028/NIST.FIPS.180-4, July 2015, 1174 . 1177 [NIST.FIPS.186-4] 1178 National Institute of Standards and Technology (NIST), 1179 "Digital Signature Standard (DSS)", NIST NIST FIPS 186-4, 1180 DOI 10.6028/NIST.FIPS.186-4, July 2013, 1181 . 1184 [NIST.FIPS.186-5] 1185 National Institute of Standards and Technology (NIST), 1186 "FIPS Pub 186-5 (Draft): Digital Signature Standard 1187 (DSS)", October 2019, 1188 . 1191 [NIST.FIPS.197] 1192 National Institute of Standards and Technology (NIST), 1193 "Advanced encryption standard (AES)", NIST NIST FIPS 197, 1194 DOI 10.6028/NIST.FIPS.197, November 2001, 1195 . 1198 [NIST.FIPS.198-1] 1199 National Institute of Standards and Technology (NIST), 1200 "The Keyed-Hash Message Authentication Code (HMAC)", 1201 NIST NIST FIPS 198-1, DOI 10.6028/NIST.FIPS.198-1, July 1202 2008, . 1205 [NIST.FIPS.202] 1206 Dworkin, Morris J., "SHA-3 Standard: Permutation-Based 1207 Hash and Extendable-Output Functions", NIST NIST FIPS 202, 1208 DOI 10.6028/NIST.FIPS.202, July 2015, 1209 . 1212 [NIST.SP.800-185] 1213 Kelsey, John., Change, Shu-jen., and Ray. Perlner, "SHA-3 1214 derived functions: cSHAKE, KMAC, TupleHash and 1215 ParallelHash", NIST NIST SP 800-185, 1216 DOI 10.6028/NIST.SP.800-185, December 2016, 1217 . 1220 [NIST.SP.800-38d] 1221 Dworkin, M J., "Recommendation for block cipher modes of 1222 operation :GaloisCounter Mode (GCM) and GMAC", NIST NIST 1223 SP 800-38d, DOI 10.6028/NIST.SP.800-38d, 2007, 1224 . 1227 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1228 Hashing for Message Authentication", RFC 2104, 1229 DOI 10.17487/RFC2104, February 1997, 1230 . 1232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1233 Requirement Levels", BCP 14, RFC 2119, 1234 DOI 10.17487/RFC2119, March 1997, 1235 . 1237 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1238 RFC 2631, DOI 10.17487/RFC2631, June 1999, 1239 . 1241 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1242 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 1243 . 1245 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1246 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 1247 September 2002, . 1249 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport 1250 Algorithm in Cryptographic Message Syntax (CMS)", 1251 RFC 3560, DOI 10.17487/RFC3560, July 2003, 1252 . 1254 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1255 Encryption Algorithm in Cryptographic Message Syntax 1256 (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, 1257 . 1259 [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in 1260 Cryptographic Message Syntax (CMS)", RFC 4056, 1261 DOI 10.17487/RFC4056, June 2005, 1262 . 1264 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1265 "Internet X.509 Public Key Infrastructure Certificate 1266 Management Protocol (CMP)", RFC 4210, 1267 DOI 10.17487/RFC4210, September 2005, 1268 . 1270 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1271 Certificate Request Message Format (CRMF)", RFC 4211, 1272 DOI 10.17487/RFC4211, September 2005, 1273 . 1275 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 1276 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 1277 RFC 4231, DOI 10.17487/RFC4231, December 2005, 1278 . 1280 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1281 "Elliptic Curve Cryptography Subject Public Key 1282 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 1283 . 1285 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1286 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1287 . 1289 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 1290 Cryptography (ECC) Algorithms in Cryptographic Message 1291 Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 1292 2010, . 1294 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 1295 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 1296 2010, . 1298 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1299 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1300 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1301 . 1303 [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: 1304 Password-Based Cryptography Specification Version 2.1", 1305 RFC 8018, DOI 10.17487/RFC8018, January 2017, 1306 . 1308 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1309 Signature Algorithm (EdDSA)", RFC 8032, 1310 DOI 10.17487/RFC8032, January 2017, 1311 . 1313 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1314 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1315 May 2017, . 1317 [RFC8418] Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key 1318 Agreement Algorithm with X25519 and X448 in the 1319 Cryptographic Message Syntax (CMS)", RFC 8418, 1320 DOI 10.17487/RFC8418, August 2018, 1321 . 1323 [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature 1324 Algorithm (EdDSA) Signatures in the Cryptographic Message 1325 Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 1326 2018, . 1328 [RFC8702] Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash 1329 Functions in the Cryptographic Message Syntax (CMS)", 1330 RFC 8702, DOI 10.17487/RFC8702, January 2020, 1331 . 1333 [RFC9044] Housley, R., "Using the AES-GMAC Algorithm with the 1334 Cryptographic Message Syntax (CMS)", RFC 9044, 1335 DOI 10.17487/RFC9044, June 2021, 1336 . 1338 [RFC9045] Housley, R., "Algorithm Requirements Update to the 1339 Internet X.509 Public Key Infrastructure Certificate 1340 Request Message Format (CRMF)", RFC 9045, 1341 DOI 10.17487/RFC9045, June 2021, 1342 . 1344 12. Informative References 1346 [ECRYPT.CSA.D5.4] 1347 University of Bristol, "Algorithms, Key Size and Protocols 1348 Report (2018)", March 2015, 1349 . 1352 [NIST.SP.800-57pt1r5] 1353 Barker, Elaine., "Recommendation for key management:part 1 1354 - general", NIST NIST SP 800-57pt1r5, 1355 DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, 1356 . 1359 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1360 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1361 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 1362 April 2019, . 1364 [RFC8692] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key 1365 Infrastructure: Additional Algorithm Identifiers for 1366 RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, 1367 DOI 10.17487/RFC8692, December 2019, 1368 . 1370 Appendix A. History of changes 1372 Note: This appendix will be deleted in the final version of the 1373 document. 1375 From version 08 -> 09: 1377 * Updated IPR disclaimer 1379 From version 07 -> 08: 1381 * Fixing issues from WG and AD review 1382 * Adding Note to Section 2.2, 3.3, and 6.2.3 regarding usage of 1383 SHAKE and KMAC and added ToDo regarding checking respective notes 1384 * Added two tables showing algorithms sorted by their strength to 1385 Section 7 and added ToDo regarding checking theses tables 1386 * Updates the algorithm use profile in Section 7.1 1387 * Updated and added security consideration on SHAKE, 1388 PasswordBasedMac, KMAC, and symmetric key-based MAC functions and 1389 added ToDo regarding checking the security consideration on SHAKE 1391 From version 06 -> 07: 1393 * Fixing minor formatting nits 1395 From version 05 -> 06: 1397 * Added text to Section 2 and Section 3.3 to clearly specify the 1398 hash algorithm to use for certConf messages for certificates 1399 signed with EdDSA (see thread "[CMP Updates] Hash algorithm to us 1400 for calculating certHash") 1401 * Updated new RFC numbers for I-D.ietf-lamps-cms-aes-gmac-alg and I- 1402 D.ietf-lamps-crmf-update-algs 1404 From version 04 -> 05: 1406 * Minor changes and corrections in wording 1408 From version 03 -> 04: 1410 * Added John Gray to the list of authors due to his extensive 1411 support and valuable feedback 1412 * Added some clarification of the use AES-GMAC to Section 6.2.1 1413 * Extended the guidance on how to select a set of algorithms in 1414 Section 7 and deleted former Section 7.1 1415 * Deleted the algorithms mandatory to support in Section 7.2 as 1416 discussed at IETF 110 1417 * Extended the Security considerations in Section 9 1418 * Minor changes in wording 1420 From version 02 -> 03: 1422 * Moved former Appendix A to new Section 7 as suggested by Rich and 1423 Russ (see thread "I-D Action: draft-ietf-lamps-cmp-algorithms- 1424 02.txt") 1425 * Added a column to Table 1 in Section 7.2 to reflect the changes to 1426 RFC 4210 1427 * Updated Table 2 in Section 7.3 1428 * Added a paragraph to Section 9 to discuss backward compatibility 1429 with RFC 4210 1430 * Minor changes in wording 1432 From version 01 -> 02: 1434 * Added Hans Aschauer, Mike Ounsworth, and Serge Mister as co-author 1435 * Changed to XML V3 1436 * Added SHAKE digest algorithm to Section 2 as discussed at IETF 109 1437 * Deleted DSA from Section 3 as discussed at IETF 109 1438 * Added RSASSA-PSS with SHAKE to Section 3 1439 * Added SECP curves the section on ECDSA with SHA2, ECDSA with 1440 SHAKE, and EdDSA to Section 3 as discussed at IETF 109 1441 * Deleted static-static D-H and ECDH from Section 4.1 based on the 1442 discussion on the mailing list (see thread "[CMP Algorithms] 1443 Section 4.1.1 and 4.1.2 drop static-static (EC)DH key agreement 1444 algorithms for use in CMP") 1446 * Added ECDH OIDs and SECP curves, as well as ECDH with curve25519 1447 and curve448 to Section 4.1 as discussed at IETF 109 1448 * Deleted RSA-OAEP from Section 4.2 first as discussed at IETF 109, 1449 but re-added it after discussion on the mailing list (see thread 1450 "Mail regarding draft-ietf-lamps-cmp-algorithms") 1451 * Added a paragraph to Section 4.3.1 to explain that the algorithms 1452 and key length for content encryption and key wrapping must be 1453 aligned as discussed on the mailing list (see thread "[CMP 1454 Algorithms] Use Key-Wrap with or without padding in Section 4.3 1455 and Section 5") 1456 * Deleted AES-CCM and AES-GMC from and added AES-CBC to Section 5 as 1457 discussed at IETF 109 1458 * Added Section 6.1.2 to offer PBMAC1 as discusses on the mailing 1459 list (see thread "Mail regarding draft-ietf-lamps-crmf-update- 1460 algs-02") and restructured text in Section 6 to be easier to 1461 differentiate between password- and shared-key-based MAC 1462 * Deleted Diffie-Hellmann based MAC from Section 6 as is only 1463 relevant when using enrolling Diffie-Hellmann certificates 1464 * Added AES-GMAC and SHAKE-based KMAC to Section 6 as discussed at 1465 IETF 109 1466 * Extended Section 9 to mention Russ supporting with two additional 1467 I-Ds and name further supporters of the draft 1468 * Added a first draft of a generic algorithm selection guideline to 1469 Appendix A 1470 * Added a first proposal for mandatory algorithms for the 1471 Lightweight CMP Profile to Appendix A 1472 * Minor changes in wording 1474 From version 00 -> 01: 1476 * Changed sections Symmetric Key-Encryption Algorithms and Content 1477 Encryption Algorithms based on the discussion on the mailing list 1478 (see thread "[CMP Algorithms] Use Key-Wrap with or without padding 1479 in Section 4.3 and Section 5") 1480 * Added Appendix A with updated algorithms profile for RDC4210 1481 Appendix D.2 and first proposal for the Lightweight CMP Profile 1482 * Minor changes in wording 1484 Authors' Addresses 1486 Hendrik Brockhaus (editor) 1487 Siemens AG 1489 Email: hendrik.brockhaus@siemens.com 1490 Hans Aschauer 1491 Siemens AG 1493 Email: hans.aschauer@siemens.com 1495 Mike Ounsworth 1496 Entrust 1498 Email: mike.ounsworth@entrust.com 1500 John Gray 1501 Entrust 1503 Email: john.gray@entrust.com