idnits 2.17.1 draft-ietf-lamps-cmp-algorithms-12.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 (6 April 2022) is 743 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-17 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-10 ** 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: 8 October 2022 J. Gray 7 Entrust 8 6 April 2022 10 Certificate Management Protocol (CMP) Algorithms 11 draft-ietf-lamps-cmp-algorithms-12 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 8 October 2022. 37 Copyright Notice 39 Copyright (c) 2022 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 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Message Digest Algorithms . . . . . . . . . . . . . . . . . . 3 56 2.1. SHA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5 59 3.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.3. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. Key Management Algorithms . . . . . . . . . . . . . . . . . . 7 63 4.1. Key Agreement Algorithms . . . . . . . . . . . . . . . . 8 64 4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 8 65 4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 10 67 4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 4.3. Symmetric Key-Encryption Algorithms . . . . . . . . . . . 11 69 4.3.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 11 70 4.4. Key Derivation Algorithms . . . . . . . . . . . . . . . . 12 71 4.4.1. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . 12 72 5. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12 73 5.1. AES-CBC . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6. Message Authentication Code Algorithms . . . . . . . . . . . 13 75 6.1. Password-Based MAC . . . . . . . . . . . . . . . . . . . 13 76 6.1.1. PasswordBasedMac . . . . . . . . . . . . . . . . . . 14 77 6.1.2. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . 14 78 6.2. Symmetric Key-Based MAC . . . . . . . . . . . . . . . . . 14 79 6.2.1. SHA2-Based HMAC . . . . . . . . . . . . . . . . . . . 15 80 6.2.2. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . 15 81 6.2.3. SHAKE-Based KMAC . . . . . . . . . . . . . . . . . . 16 82 7. Algorithm Use Profiles . . . . . . . . . . . . . . . . . . . 16 83 7.1. Algorithm Profile for RFC 4210 PKI Management Message 84 Profiles . . . . . . . . . . . . . . . . . . . . . . . . 19 85 7.2. Algorithm Profile for Lightweight CMP Profile . . . . . . 21 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 89 11. Normative References . . . . . . . . . . . . . . . . . . . . 24 90 12. Informative References . . . . . . . . . . . . . . . . . . . 28 91 Appendix A. History of Changes . . . . . . . . . . . . . . . . . 29 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 output length MUST be 256 bits for SHAKE128 and 512 bits for 164 SHAKE256. 166 The message digest algorithms SHAKE128 and SHAKE256 are identified by 167 the following OIDs: 169 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 170 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 171 hashalgs(2) 11 } 172 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 173 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 174 hashalgs(2) 12 } 176 Specific conventions to be considered are specified in RFC 8702 177 Section 3.1 [RFC8702]. 179 3. Signature Algorithms 181 This section provides references to object identifiers and 182 conventions to be employed by CMP implementations that support RSA, 183 ECDSA, or EdDSA signature algorithms. 185 The signature algorithm is referred to as MSG_SIG_ALG in Section 7.2, 186 RFC 4210 Appendix D and E [RFC4210], and in the Lightweight CMP 187 Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 189 Signature algorithm identifiers are located in: 191 * protectionAlg field of PKIHeader 192 * algorithmIdentifier field of POPOSigningKey 193 * signatureAlgorithm field of CertificationRequest, 194 SignKeyPairTypes, and SignerInfo 196 Signature values are located in: 198 * protection field of PKIMessage 199 * signature field of POPOSigningKey 200 * signature field of CertificationRequest and SignerInfo 202 3.1. RSA 204 The RSA (RSASSA-PSS and PKCS#1 version 1.5) signature algorithm is 205 defined in RFC 8017 [RFC8017]. 207 The algorithm identifier for RSASAA-PSS signatures used with SHA2 208 message digest algorithms is identified by the following OID: 210 id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2) 211 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 } 213 Specific conventions to be considered are specified in RFC 4056 214 [RFC4056]. 216 The signature algorithm RSASSA-PSS used with SHAKE message digest 217 algorithms are identified by the following OIDs: 219 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) 220 identified-organization(3) dod(6) internet(1) security(5) 221 mechanisms(5) pkix(7) algorithms(6) 30 } 222 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) 223 identified-organization(3) dod(6) internet(1) security(5) 224 mechanisms(5) pkix(7) algorithms(6) 31 } 226 Specific conventions to be considered are specified in RFC 8702 227 Section 3.2.1 [RFC8702]. 229 The signature algorithm PKCS#1 version 1.5 used with SHA2 message 230 digest algorithms is identified by the following OIDs: 232 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 233 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } 234 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 235 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } 236 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 237 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } 238 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 239 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } 241 Specific conventions to be considered are specified in RFC 5754 242 Section 3.2 [RFC5754]. 244 3.2. ECDSA 246 The ECDSA signature algorithm is defined in FIPS Pub 186-4 247 [NIST.FIPS.186-4]. 249 The signature algorithm ECDSA used with SHA2 message digest 250 algorithms is identified by the following OIDs: 252 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 253 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } 254 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 255 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 256 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 257 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 258 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 259 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 261 As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves 262 are identified by the following OIDs: 264 secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 265 us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } 266 secp224r1 OBJECT IDENTIFIER ::= { iso(1) 267 identified-organization(3) certicom(132) curve(0) 33 } 268 secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 269 us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } 270 secp384r1 OBJECT IDENTIFIER ::= { iso(1) 271 identified-organization(3) certicom(132) curve(0) 34 } 272 secp521r1 OBJECT IDENTIFIER ::= { iso(1) 273 identified-organization(3) certicom(132) curve(0) 35 } 275 Specific conventions to be considered are specified in RFC 5754 276 Section 3.3 [RFC5754]. 278 The signature algorithm ECDSA used with SHAKE message digest 279 algorithms are identified by the following OIDs: 281 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) 282 identified-organization(3) dod(6) internet(1) security(5) 283 mechanisms(5) pkix(7) algorithms(6) 32 } 284 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) 285 identified-organization(3) dod(6) internet(1) security(5) 286 mechanisms(5) pkix(7) algorithms(6) 33 } 288 Specific conventions to be considered are specified in RFC 8702 289 Section 3.2.2 [RFC8702]. 291 3.3. EdDSA 293 The EdDSA signature algorithm is defined in RFC 8032 Section 3.3 294 [RFC8032] and FIPS Pub 186-5 (Draft) [NIST.FIPS.186-5]. 296 The signature algorithm Ed25519 that MUST be used with SHA-512 297 message digest algorithms is identified by the following OIDs: 299 id-Ed25519 OBJECT IDENTIFIER ::= { iso(1) 300 identified-organization(3) thawte(101) 112 } 302 The signature algorithm Ed448 that MUST be used with SHAKE256 message 303 digest algorithms is identified by the following OIDs: 305 id-Ed448 OBJECT IDENTIFIER ::= { iso(1) 306 identified-organization(3) thawte(101) 113 } 308 Specific conventions to be considered are specified in RFC 8419 309 [RFC8419]. 311 Note: The hash algorithm used to calculate the certHash in certConf 312 messages MUST be SHA512 if the certificate to be confirmed has been 313 signed using Ed25519 and SHAKE256 with d=512 if signed using Ed448. 315 4. Key Management Algorithms 317 CMP utilizes the following general key management techniques: key 318 agreement, key transport, and passwords. 320 CRMF [RFC4211] and CMP Updates [I-D.ietf-lamps-cmp-updates] promotes 321 the use of CMS [RFC5652] EnvelopedData by deprecating the use of 322 EncryptedValue. 324 4.1. Key Agreement Algorithms 326 The key agreement algorithm is referred to as PROT_ENC_ALG in 327 RFC 4210 Appendix D and E [RFC4210] and as KM_KA_ALG in the 328 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as 329 well as in Section 7. 331 Key agreement algorithms are only used in CMP when using CMS 332 [RFC5652] EnvelopedData together with the key agreement key 333 management technique. When a key agreement algorithm is used, a key- 334 encryption algorithm (Section 4.3) is needed next to the content- 335 encryption algorithm (Section 5). 337 Key agreement algorithm identifiers are located in: 339 * keyEncryptionAlgorithm field of KeyAgreeRecipientInfo 341 Key wrap algorithm identifiers are located in: 343 * KeyWrapAlgorithm parameters within keyEncryptionAlgorithm field of 344 KeyAgreeRecipientInfo 346 Wrapped content-encryption keys are located in: 348 * encryptedKey field of RecipientEncryptedKeys 350 4.1.1. Diffie-Hellman 352 Diffie-Hellman key agreement is defined in RFC 2631 [RFC2631] and 353 SHALL be used in the ephemeral-static as specified in RFC 3370 354 [RFC3370]. Static-static variants SHALL NOT be used. 356 The Diffie-Hellman key agreement algorithm is identified by the 357 following OID: 359 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) 360 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 362 Specific conventions to be considered are specified in RFC 3370 363 Section 4.1 [RFC3370]. 365 4.1.2. ECDH 367 Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined in 368 RFC 5753 [RFC5753] and SHALL be used in the ephemeral-static variant 369 as specified in RFC 5753 [RFC5753] or the 1-Pass ECMQV variant as 370 specified in RFC 5753 [RFC5753]. Static-static variants SHALL NOT be 371 used. 373 The ECDH key agreement algorithm used together with NIST-recommended 374 SECP curves are identified by the following OIDs: 376 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 377 identified-organization(3) certicom(132) schemes(1) 11(11) 0 } 378 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 379 identified-organization(3) certicom(132) schemes(1) 11(11) 1 } 380 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 381 identified-organization(3) certicom(132) schemes(1) 11(11) 2 } 382 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 383 identified-organization(3) certicom(132) schemes(1) 11(11) 3 } 384 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 385 iso(1) identified-organization(3) certicom(132) schemes(1) 386 14(14) 0 } 387 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 388 iso(1) identified-organization(3) certicom(132) schemes(1) 389 14(14) 1 } 390 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 391 iso(1) identified-organization(3) certicom(132) schemes(1) 392 14(14) 2 } 393 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 394 iso(1) identified-organization(3) certicom(132) schemes(1) 395 14(14) 3 } 396 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 397 identified-organization(3) certicom(132) schemes(1) 15(15) 0 } 398 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 399 identified-organization(3) certicom(132) schemes(1) 15(15) 1 } 400 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 401 identified-organization(3) certicom(132) schemes(1) 15(15) 2 } 402 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 403 identified-organization(3) certicom(132) schemes(1) 15(15) 3 } 405 As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves 406 are identified by the following OIDs: 408 secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 409 us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } 410 secp224r1 OBJECT IDENTIFIER ::= { iso(1) 411 identified-organization(3) certicom(132) curve(0) 33 } 412 secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 413 us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } 414 secp384r1 OBJECT IDENTIFIER ::= { iso(1) 415 identified-organization(3) certicom(132) curve(0) 34 } 416 secp521r1 OBJECT IDENTIFIER ::= { iso(1) 417 identified-organization(3) certicom(132) curve(0) 35 } 419 Specific conventions to be considered are specified in RFC 5753 420 [RFC5753]. 422 The ECDH key agreement algorithm used together with curve25519 or 423 curve448 are identified by the following OIDs: 425 id-X25519 OBJECT IDENTIFIER ::= { iso(1) 426 identified-organization(3) thawte(101) 110 } 427 id-X448 OBJECT IDENTIFIER ::= { iso(1) 428 identified-organization(3) thawte(101) 111 } 430 Specific conventions to be considered are specified in RFC 8418 431 [RFC8418]. 433 4.2. Key Transport Algorithms 435 The key transport algorithm is also referred to as PROT_ENC_ALG in 436 RFC 4210 Appendix D and E [RFC4210] and as KM_KL_ALG in the 437 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as 438 well as in Section 7. 440 Key transport algorithms are only used in CMP when using CMS 441 [RFC5652] EnvelopedData together with the key transport key 442 management technique. 444 Key transport algorithm identifiers are located in: 446 * keyEncryptionAlgorithm field of KeyTransRecipientInfo 448 Key transport encrypted content-encryption keys are located in: 450 * encryptedKey field of KeyTransRecipientInfo 452 4.2.1. RSA 454 The RSA key transport algorithm is the RSA encryption scheme defined 455 in RFC 8017 [RFC8017]. 457 The algorithm identifier for RSA (PKCS #1 v1.5) is: 459 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 460 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 462 The algorithm identifier for RSAES-OAEP is: 464 id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) 465 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } 467 Further conventions to be considered for PKCS #1 v1.5 are specified 468 in RFC 3370 Section 4.2.1 [RFC3370] and for RSAES-OAEP in RFC 3560 469 [RFC3560]. 471 4.3. Symmetric Key-Encryption Algorithms 473 The symmetric key-encryption algorithm is also referred to as 474 KM_KW_ALG in Section 7.2 and in the Lightweight CMP Profile 475 [I-D.ietf-lamps-lightweight-cmp-profile]. 477 As symmetric key-encryption key management technique is not used by 478 CMP, the symmetric key-encryption algorithm is only needed when using 479 the key agreement or password-based key management technique with CMS 480 [RFC5652] EnvelopedData. 482 Key wrap algorithm identifiers are located in: 484 * parameters field of the KeyEncryptionAlgorithmIdentifier of 485 KeyAgreeRecipientInfo and PasswordRecipientInfo 487 Wrapped content-encryption keys are located in: 489 * encryptedKey field of RecipientEncryptedKeys (for key agreement) 490 and PasswordRecipientInfo (for password-based key management) 492 4.3.1. AES Key Wrap 494 The AES encryption algorithm is defined in FIPS Pub 197 495 [NIST.FIPS.197] and the key wrapping is defined in RFC 3394 496 [RFC3394]. 498 AES key encryption has the algorithm identifier: 500 id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 501 country(16) us(840) organization(1) gov(101) csor(3) 502 nistAlgorithm(4) aes(1) 5 } 503 id-aes192-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 504 country(16) us(840) organization(1) gov(101) csor(3) 505 nistAlgorithm(4) aes(1) 25 } 506 id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 507 country(16) us(840) organization(1) gov(101) csor(3) 508 nistAlgorithm(4) aes(1) 45 } 510 The underlying encryption functions for the key wrap and content- 511 encryption algorithms (as specified in Section 5) and the key sizes 512 for the two algorithms MUST be the same (e.g., AES-128 key wrap 513 algorithm with AES-128 content-encryption algorithm), see also 514 RFC 8551 [RFC8551]. 516 Further conventions to be considered for AES key wrap are specified 517 in RFC 3394 Section 2.2 [RFC3394] and RFC 3565 Section 2.3.2 518 [RFC3565]. 520 4.4. Key Derivation Algorithms 522 The key derivation algorithm is also referred to as KM_KD_ALG in 523 Section 7.2 and in the Lightweight CMP Profile 524 [I-D.ietf-lamps-lightweight-cmp-profile]. 526 Key derivation algorithms are only used in CMP when using CMS 527 [RFC5652] EnvelopedData together with password-based key management 528 technique. 530 Key derivation algorithm identifiers are located in: 532 * keyDerivationAlgorithm field of PasswordRecipientInfo 534 When using the password-based key management technique with 535 EnvelopedData as specified in CMP Updates together with MAC-based 536 PKIProtection, the salt for the password-based MAC and KDF must be 537 chosen independently to ensure usage of independent symmetric keys. 539 4.4.1. PBKDF2 541 The password-based key derivation function 2 (PBKDF2) is defined in 542 RFC 8018 [RFC8018]. 544 Password-based key derivation function 2 has the algorithm 545 identifier: 547 id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 548 rsadsi(113549) pkcs(1) pkcs-5(5) 12 } 550 Further conventions to be considered for PBKDF2 are specified in 551 RFC 3370 Section 4.4.1 [RFC3370] and RFC 8018 Section 5.2 [RFC8018]. 553 5. Content Encryption Algorithms 555 The content encryption algorithm is also referred to as PROT_SYM_ALG 556 in Section 7, RFC 4210 Appendix D and E [RFC4210], and the 557 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 559 Content encryption algorithms are only used in CMP when using CMS 560 [RFC5652] EnvelopedData to transport a signed private key package in 561 case of central key generation or key archiving, a certificate to 562 facilitate implicit proof-of-possession, or a revocation passphrase 563 in encrypted form. 565 Content encryption algorithm identifiers are located in: 567 * contentEncryptionAlgorithm field of EncryptedContentInfo 568 Encrypted content is located in: 570 * encryptedContent field of EncryptedContentInfo 572 5.1. AES-CBC 574 The AES encryption algorithm is defined in FIPS Pub 197 575 [NIST.FIPS.197]. 577 AES-CBC content encryption has the algorithm identifier: 579 id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 580 country(16) us(840) organization(1) gov(101) csor(3) 581 nistAlgorithm(4) aes(1) 2 } 582 id-aes192-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 583 country(16) us(840) organization(1) gov(101) csor(3) 584 nistAlgorithm(4) aes(1)22 } 585 id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 586 country(16) us(840) organization(1) gov(101) csor(3) 587 nistAlgorithm(4) aes(1)42 } 589 Specific conventions to be considered for AES-CBC content encryption 590 are specified in RFC 3565 [RFC3565]. 592 6. Message Authentication Code Algorithms 594 The message authentication code is either used for shared secret- 595 based CMP message protection or together with the password-based key 596 derivation function (PBKDF2). 598 The message authentication code algorithm is also referred to as 599 MSG_MAC_ALG in Section 7, RFC 4210 Appendix D and E [RFC4210], and 600 the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 602 6.1. Password-Based MAC 604 Password-based MAC algorithms combine the derivation of a symmetric 605 key from a password or other shared secret information and a 606 symmetric key-based MAC function as specified in Section 6.2 using 607 this derived key. 609 Message authentication code algorithm identifiers are located in: 611 * protectionAlg field of PKIHeader 613 Message authentication code values are located in: 615 * PKIProtection field of PKIMessage 617 6.1.1. PasswordBasedMac 619 The PasswordBasedMac algorithm is defined in RFC 4210 Section 5.1.3.1 620 [RFC4210], RFC 4211 Section 4.4 [RFC4211], and Algorithm Requirements 621 Update to the Internet X.509 Public Key Infrastructure Certificate 622 Request Message Format (CRMF) [RFC9045]. 624 The PasswordBasedMac algorithm is identified by the following OID: 626 id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 627 us(840) nt(113533) nsn(7) algorithms(66) 13 } 629 Further conventions to be considered for password-based MAC are 630 specified in RFC 4210 Section 5.1.3.1 [RFC4210], RFC 4211 Section 4.4 631 [RFC4211], and Algorithm Requirements Update to the Internet X.509 632 Public Key Infrastructure Certificate Request Message Format (CRMF) 633 [RFC9045]. 635 6.1.2. PBMAC1 637 The Password-Based Message Authentication Code 1 (PBMAC1) is defined 638 in RFC 8018 [RFC8018]. PBMAC1 combines a password-based key 639 derivation function like PBKDF2 (Section 4.4.1) with an underlying 640 symmetric key-based message authentication scheme. 642 PBMAC1 has the following OID: 644 id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 645 rsadsi(113549) pkcs(1) pkcs-5(5) 14 } 647 Specific conventions to be considered for PBMAC1 are specified in 648 RFC 8018 Section 7.1 and A.5 [RFC8018]. 650 6.2. Symmetric Key-Based MAC 652 Symmetric key-based MAC algorithms are used for deriving the 653 symmetric encryption key when using PBKDF2 as described in 654 Section 4.4.1 as well as with Password-based MAC as described in 655 Section 6.1. 657 Message authentication code algorithm identifiers are located in: 659 * protectionAlg field of PKIHeader 660 * messageAuthScheme field of PBMAC1 661 * mac field of PBMParameter 662 * prf field of PBKDF2-params 664 Message authentication code values are located in: 666 * PKIProtection field of PKIMessage 668 6.2.1. SHA2-Based HMAC 670 The HMAC algorithm is defined in RFC 2104 [RFC2104] and 671 FIPS Pub 198-1 [NIST.FIPS.198-1]. 673 The HMAC algorithm used with SHA2 message digest algorithms is 674 identified by the following OIDs: 676 id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 677 us(840) rsadsi(113549) digestAlgorithm(2) 8 } 678 id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 679 us(840) rsadsi(113549) digestAlgorithm(2) 9 } 680 id-hmacWithSHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 681 us(840) rsadsi(113549) digestAlgorithm(2) 10 } 682 id-hmacWithSHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 683 us(840) rsadsi(113549) digestAlgorithm(2) 11 } 685 Specific conventions to be considered for SHA2-based HMAC are 686 specified in RFC 4231 Section 3.1 [RFC4231]. 688 6.2.2. AES-GMAC 690 The AES-GMAC algorithm is defined in FIPS Pub 197 [NIST.FIPS.197] and 691 NIST SP 800-38d [NIST.SP.800-38d]. 693 Note: AES-GMAC MUST NOT be used twice with the same parameter set, 694 especially the same nonce. Therefore, it MUST NOT be used together 695 with PBKDF2. When using it with PBMAC1 it MUST be ensured that AES- 696 GMAC is only used as message authentication scheme and not for the 697 key derivation function PBKDF2. 699 The AES-GMAC algorithm is identified by the following OIDs: 701 id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 702 country(16) us(840) organization(1) gov(101) csor(3) 703 nistAlgorithm(4) aes(1) 9 } 704 id-aes192-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 705 country(16) us(840) organization(1) gov(101) csor(3) 706 nistAlgorithm(4) aes(1) 29 } 707 id-aes256-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 708 country(16) us(840) organization(1) gov(101) csor(3) 709 nistAlgorithm(4) aes(1) 49 } 711 Specific conventions to be considered for AES-GMAC are specified in 712 RFC 9044 [RFC9044]. 714 6.2.3. SHAKE-Based KMAC 716 The KMAC algorithm is defined in RFC 8702 [RFC8702] and 717 FIPS SP 800-185 [NIST.SP.800-185]. 719 The SHAKE-based KMAC algorithm is identified by the following OIDs: 721 id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 722 country(16) us(840) organization(1) gov(101) csor(3) 723 nistAlgorithm(4) 2 19 } 724 id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 725 country(16) us(840) organization(1) gov(101) csor(3) 726 nistAlgorithm(4) 2 20 } 728 Specific conventions to be considered for KMAC with SHAKE are 729 specified in RFC 8702 Section 3.4 [RFC8702]. 731 7. Algorithm Use Profiles 733 This section provides profiles of algorithms and respective 734 conventions for different application use cases. 736 Recommendations like NIST SP 800-57 Recommendation for Key Management 737 Table2 [NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and 738 Protocols Report (2018) Section 4.6 [ECRYPT.CSA.D5.4] provide general 739 information on current cryptographic algorithms. 741 The overall cryptographic strength of a CMP deployment will depend on 742 several factors, including: 744 * Capabilities of the end entity: What kind of algorithms does the 745 end entity support. The cryptographic strength of the system 746 SHOULD be at least as strong as the algorithms and keys used for 747 the certificate being managed. 749 * Algorithm profile: The overall strength of the profile will be the 750 strength of the weakest algorithm it contains. 752 * Message protection: The overall strength of the CMC message 753 protection 755 - MAC-based protection: The entropy of the shared secret 756 information or password when MAC-based message protection is 757 used (MSG_MAC_ALG). 759 - Signature-based protection: The strength of the key pair and 760 signature algorithm when signature-based protection is used 761 (MSG_SIG_ALG). 763 - Protection of centrally generated keys: The strength of the 764 algorithms used for the key management technique (Section 7.2: 765 PROT_ENC_ALG or Section 7.1: KM_KA_ALG, KM_KT_ALG, KM_KD_ALG) 766 and the encryption of the content-encryption key and private 767 key (Section 7.2: SYM_PENC_ALG, PROT_SYM_ALG or Section 7.1: 768 KM_KW_ALG, PROT_SYM_ALG). 770 The following table shows the algorithms listed in this document 771 sorted by their bits of security. If an implementation intends to 772 enroll and manage certificate for keys of a specific security, it 773 SHALL implement and use algorithms of at least that strength for the 774 respective PKI management operation. If one row does not provide a 775 suitable algorithm, the implementer MUST choose one offering more 776 bits of security. 778 +=======+==========+================+==================+============+ 779 | Bits | RSA or | Elliptic | Hash Function or | Symmetric | 780 | of | DH | Curve | XOF with | Encryption | 781 | Secu- | | | Specified Output | | 782 | rity | | | Length (d) | | 783 +=======+==========+================+==================+============+ 784 | 112 | RSA2048, | ECDSA/ECDH | SHA224 | | 785 | | DH(2048) | (secp224r1) | | | 786 +-------+----------+----------------+------------------+------------+ 787 | 128 | RSA3072, | ECDSA/ECDH | SHA256, | AES-128 | 788 | | DH(3072) | (secp256r1), | SHAKE128(d=256) | | 789 | | | Ed25519/ | | | 790 | | | X25519 | | | 791 | | | (Curve25519) | | | 792 +-------+----------+----------------+------------------+------------+ 793 | 192 | | ECDSA/ECDH | SHA384 | AES-192 | 794 | | | (secp384r1) | | | 795 +-------+----------+----------------+------------------+------------+ 796 | 224 | | Ed448/X448 | | | 797 | | | (Curve448) | | | 798 +-------+----------+----------------+------------------+------------+ 799 | 256 | | ECDSA/ECDH | SHA512, | AES-256 | 800 | | | (secp521r1) | SHAKE256(d=512) | | 801 +-------+----------+----------------+------------------+------------+ 803 Table 1: Cryptographic Algorithms Sorted by their Bits of Security 805 The following table shows the cryptographic algorithms sorted by 806 their usage in CMP and with more details. 808 +========+==========+===============+===============+===============+ 809 |Bits of |Key Types |CMP Protection |Key Management | Key-Wrap and | 810 |Security|to Be | |Technique | Symmetric | 811 | |Certified | | | Encryption | 812 +========+==========+===============+===============+===============+ 813 | | |MSG_SIG_ALG, |PROT_ENC_ALG or| PROT_SYM_ALG, | 814 | | |MSG_MAC_ALG |KM_KA_ALG, | SYM_PENC_ALG | 815 | | | |KM_KT_ALG, | or | 816 | | | |KM_KD_ALG | KM_KW_ALG | 817 +--------+----------+---------------+---------------+---------------+ 818 |112 |RSA2048, |RSASSA-PSS |DH(2048), | | 819 | |secp224r1 |(2048, SHA224 |RSAES-OAEP | | 820 | | |or SHAKE128 |(2048, SHA224),| | 821 | | |(d=256)), |RSAEncryption | | 822 | | |RSAEncryption |(2048, SHA224),| | 823 | | |(2048, SHA224),|ECDH | | 824 | | |ECDSA |(secp224r1, | | 825 | | |(secp224r1, |SHA224), | | 826 | | |SHA224 or |PBKDF2 (HMAC- | | 827 | | |SHAKE128 |SHA224) | | 828 | | |(d=256)), | | | 829 | | |PBMAC1 (HMAC- | | | 830 | | |SHA224) | | | 831 +--------+----------+---------------+---------------+---------------+ 832 |128 |RSA3072, |RSASSA-PSS |DH(3072), | AES-128 | 833 | |secp256r1,|(3072, SHA256 |RSAES-OAEP | | 834 | |Curve25519|or SHAKE128 |(3072, SHA256),| | 835 | | |(d=256)), |RSAEncryption | | 836 | | |RSAEncryption |(3072, SHA256),| | 837 | | |(3072, SHA256),|ECDH | | 838 | | |ECDSA |(secp256r1, | | 839 | | |(secp256r1, |SHA256), | | 840 | | |SHA256 or |X25519, | | 841 | | |SHAKE128 |PBKDF2 (HMAC- | | 842 | | |(d=256)), |SHA256) | | 843 | | |Ed25519 | | | 844 | | |(SHA512), | | | 845 | | |PBMAC1 (HMAC- | | | 846 | | |SHA256) | | | 847 +--------+----------+---------------+---------------+---------------+ 848 |192 |secp384r1 |ECDSA |ECDH | AES-192 | 849 | | |(secp384r1, |(secp384r1, | | 850 | | |SHA384), |SHA384), | | 851 | | |PBMAC1 (HMAC- |PBKDF2 (HMAC- | | 852 | | |SHA384) |SHA384) | | 853 +--------+----------+---------------+---------------+---------------+ 854 |224 |Curve448 |Ed448 |X448 | | 855 | | |(SHAKE256) | | | 856 +--------+----------+---------------+---------------+---------------+ 857 |256 |secp521r1 |ECDSA |ECDH | AES-256 | 858 | | |(secp521r1, |(secp521r1, | | 859 | | |SHA512 or |SHA512), | | 860 | | |SHAKE256 |PBKDF2 (HMAC- | | 861 | | |(d=512)), |SHA512) | | 862 | | |PBMAC1 (HMAC- | | | 863 | | |SHA512) | | | 864 +--------+----------+---------------+---------------+---------------+ 866 Table 2: Cryptographic Algorithms Sorted by their Bits of 867 Security and Usage by CMP 869 To avoid consuming too much computational resources it is recommended 870 to choose a set of algorithms offering roughly the same level of 871 security. Below are provided several algorithm profiles which are 872 balanced, assuming the implementer chooses MAC secrets and/or 873 certificate profiles of at least equivalent strength. 875 7.1. Algorithm Profile for RFC 4210 PKI Management Message Profiles 877 The following table updates the definitions of algorithms used within 878 PKI Management Message Profiles as defined in CMP Appendix D.2 879 [RFC4210]. 881 The columns in the table are: 883 Name: An identifier used for message profiles 885 Use: Description of where and for what the algorithm is used 887 Mandatory: Algorithms which MUST be supported by conforming 888 implementations 890 Optional: Algorithms which are OPTIONAL to support 892 Deprecated: Algorithms from RFC 4210 [RFC4210] which SHOULD NOT be 893 used anymore 895 +============+=============+=========+=================+============+ 896 |Name |Use |Mandatory|Optional |Deprecated | 897 +============+=============+=========+=================+============+ 898 |MSG_SIG_ALG |protection of|RSA |ECDSA, EdDSA |DSA, | 899 | |PKI messages | | |combinations| 900 | |using | | |with MD5 and| 901 | |signature | | |SHA-1 | 902 +------------+-------------+---------+-----------------+------------+ 903 |MSG_MAC_ALG |protection of|PBMAC1 |PasswordBasedMac,|X9.9 | 904 | |PKI messages | |HMAC, KMAC | | 905 | |using MACing | | | | 906 +------------+-------------+---------+-----------------+------------+ 907 |SYM_PENC_ALG|symmetric |AES-wrap | |3-DES(3-key-| 908 | |encryption of| | |EDE, CBC | 909 | |an end | | |Mode), RC5, | 910 | |entity's | | |CAST-128 | 911 | |private key | | | | 912 | |where | | | | 913 | |symmetric key| | | | 914 | |is | | | | 915 | |distributed | | | | 916 | |out-of-band | | | | 917 +------------+-------------+---------+-----------------+------------+ 918 |PROT_ENC_ALG|asymmetric |DH |ECDH, RSA | | 919 | |algorithm | | | | 920 | |used for | | | | 921 | |encryption of| | | | 922 | |(symmetric | | | | 923 | |keys for | | | | 924 | |encryption | | | | 925 | |of) private | | | | 926 | |keys | | | | 927 | |transported | | | | 928 | |in | | | | 929 | |PKIMessages | | | | 930 +------------+-------------+---------+-----------------+------------+ 931 |PROT_SYM_ALG|symmetric |AES-CBC | |3-DES(3-key-| 932 | |encryption | | |EDE, CBC | 933 | |algorithm | | |Mode), RC5, | 934 | |used for | | |CAST-128 | 935 | |encryption of| | | | 936 | |private key | | | | 937 | |bits (a key | | | | 938 | |of this type | | | | 939 | |is encrypted | | | | 940 | |using | | | | 941 | |PROT_ENC_ALG)| | | | 942 +------------+-------------+---------+-----------------+------------+ 944 Table 3: Algorithms Used Within RFC 4210 Appendix D.2 946 Mandatory Algorithm Identifiers and Specifications: 948 RSA: sha256WithRSAEncryption with 2048 bit, see Section 3.1 949 PasswordBasedMac: id-PasswordBasedMac, see Section 6.1 (with id- 950 sha256 as the owf parameter, see Section 2.1 and id-hmacWithSHA256 as 951 the mac parameter, see Section 6.2.1) 953 PBMAC1: id-PBMAC1, see Section 6.1.2 (with id-PBKDF2 as the key 954 derivation function, see Section 4.4.1 and id-hmacWithSHA256 as 955 message authentication scheme, see Section 6.2.1). It is RECOMMENDED 956 to prefer the usage of PBMAC1 instead of PasswordBasedMac. 958 DH: id-alg-ESDH, see Section 4.1.1 960 AES-wrap: id-aes128-wrap, see Section 4.3.1 962 AES-CBC: id-aes128-CBC, see Section 5.1 964 7.2. Algorithm Profile for Lightweight CMP Profile 966 The following table contains definitions of algorithms which MAY be 967 supported by implementations of the Lightweight CMP Profile 968 [I-D.ietf-lamps-lightweight-cmp-profile]. 970 As the set of algorithms to be used for implementations of the 971 Lightweight CMP Profile heavily depends on the PKI management 972 operations implemented, the certificates used for messages 973 protection, and the certificates to be managed, this document will 974 not specify a specific set that is mandatory to support for 975 conforming implementations. 977 The columns in the table are: 979 Name: An identifier used for message profiles 981 Use: Description of where and for what the algorithm is used 983 Examples: Lists the algorithms as described in this document. The 984 list of algorithms depends on the set of PKI management operations to 985 be implemented. 987 Note: It is RECOMMENDED to prefer the usage of PBMAC1 instead of 988 PasswordBasedMac. 990 +==============+================================+==================+ 991 | Name | Use | Examples | 992 +==============+================================+==================+ 993 | MSG_SIG_ALG | protection of PKI messages | RSA, ECDSA, | 994 | | using signature and for | EdDSA | 995 | | SignedData, e.g., a private | | 996 | | key transported in PKIMessages | | 997 +--------------+--------------------------------+------------------+ 998 | MSG_MAC_ALG | protection of PKI messages | PasswordBasedMac | 999 | | using MACing | (see Section 9), | 1000 | | | PBMAC1, HMAC, | 1001 | | | KMAC | 1002 +--------------+--------------------------------+------------------+ 1003 | KM_KA_ALG | asymmetric key agreement | DH, ECDH | 1004 | | algorithm used for agreement | | 1005 | | of a symmetric key for use | | 1006 | | with KM_KW_ALG | | 1007 +--------------+--------------------------------+------------------+ 1008 | KM_KT_ALG | asymmetric key encryption | RSA | 1009 | | algorithm used for transport | | 1010 | | of a symmetric key for | | 1011 | | PROT_SYM_ALG | | 1012 +--------------+--------------------------------+------------------+ 1013 | KM_KD_ALG | symmetric key derivation | PBKDF2 | 1014 | | algorithm used for derivation | | 1015 | | of a symmetric key for use | | 1016 | | with KM_KW_ALG | | 1017 +--------------+--------------------------------+------------------+ 1018 | KM_KW_ALG | algorithm to wrap a symmetric | AES-wrap | 1019 | | key for PROT_SYM_ALG | | 1020 +--------------+--------------------------------+------------------+ 1021 | PROT_SYM_ALG | symmetric content encryption | AES-CBC | 1022 | | algorithm used for encryption | | 1023 | | of EnvelopedData, e.g., a | | 1024 | | private key transported in | | 1025 | | PKIMessages | | 1026 +--------------+--------------------------------+------------------+ 1028 Table 4: Algorithms Used Within Lightweight CMP Profile 1030 8. IANA Considerations 1032 This document does not request changes to the IANA registry. 1034 9. Security Considerations 1036 RFC 4210 Appendix D.2 [RFC4210] contains a set of algorithms, 1037 mandatory to be supported by conforming implementations. Theses 1038 algorithms were appropriate at the time CMP was released, but as 1039 cryptographic algorithms weaken over time, some of them should not be 1040 used anymore. In general, new attacks are emerging due to research 1041 cryptoanalysis or increase in computing power. New algorithms were 1042 introduced that are more resistant to today's attacks. 1044 This document lists many cryptographic algorithms usable with CMP to 1045 offer implementer a more up to date choice. Finally, the algorithms 1046 to be supported also heavily depend on the certificates and PKI 1047 management operations utilized in the target environment. The 1048 algorithm with the lowest security strength and the entropy of shared 1049 secret information define the security of the overall solution, see 1050 Section 7. 1052 When using MAC-based message protection the use of PBMAC1 is 1053 preferable to that of PasswordBasedMac. First, PBMAC1 is a well- 1054 known scrutinized algorithm, which is not true for PasswordBasedMac. 1055 Second, the PasswordBasedMac algorithm as specified in RFC 4211 1056 Section 4.4 [RFC4211] is essentially PBKDF1 (as defined in RFC 8018 1057 Section 5.1 [RFC8018]) with an HMAC step at the end. Here we update 1058 to use the PBKDF2-HMAC construct defined as PBMAC1 in [RFC8018]. 1059 PBKDF2 is superior to PBKDF1 in an improved internal construct for 1060 iterated hashing, and in removing PBKDF1's limitation of only being 1061 able to derive keys up to the size of the underlying hash function. 1062 Additionally, PBKDF1 is not recommended for new applications as 1063 stated in Section 5.1 of RFC 8018 [RFC8018] and no longer an approved 1064 algorithm by most standards bodies, and therefore presents 1065 difficulties to implementer who are submitting their CMP 1066 implementations for certification, hence moving to a PBKDF2-based 1067 mechanism. This change is in alignment with [RFC9045] which updates 1068 [RFC4211] to allow the use of PBMAC1 in CRMF. 1070 AES-GMAC MUST NOT be used as the pseudo random function in PBKDF2; 1071 the use of AES-GMAC more than once with the same key and the same 1072 nonce will break the security. 1074 In Section 7 of this document there is also an update to the 1075 Appendix D.2 of RFC 4210 [RFC4210] and a set of algorithms that MAY 1076 be supported when implementing the Lightweight CMP Profile 1077 [I-D.ietf-lamps-lightweight-cmp-profile]. 1079 It is recognized that there may be older CMP implementations in use 1080 that conform to the algorithm use profile from Appendix D.2 of 1081 RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for 1082 PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory. 1083 Therefore, it is expected that many CMP systems may already support 1084 the recommended algorithms in this specification. In such systems 1085 the weakened algorithms should be disabled from further use. If 1086 critical systems cannot be immediately updated to conform to the 1087 recommended algorithm use profile, it is recommended a plan to 1088 migrate the infrastructure to conforming profiles be adopted as soon 1089 as possible. 1091 Symmetric key-based MAC algorithms as described in Section 6.2 MAY be 1092 used as MSG_MAC_ALG. The implementer MUST choose a suitable PRF and 1093 ensure that the key has sufficient entropy to match the overall 1094 security level of the algorithm profile. These considerations are 1095 outside the scope of the profile. 1097 10. Acknowledgements 1099 Thanks to Russ Housley for supporting this draft with submitting 1100 [RFC9044] and [RFC9045]. 1102 May thanks also to all reviewers like Serge Mister, Mark Ferreira, 1103 Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steffen 1104 Fries for their input and feedback to this document. Apologies to 1105 all not mentioned reviewers and supporters. 1107 11. Normative References 1109 [I-D.ietf-lamps-cmp-updates] 1110 Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate 1111 Management Protocol (CMP) Updates", Work in Progress, 1112 Internet-Draft, draft-ietf-lamps-cmp-updates-17, 12 1113 January 2022, . 1116 [I-D.ietf-lamps-lightweight-cmp-profile] 1117 Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight 1118 Certificate Management Protocol (CMP) Profile", Work in 1119 Progress, Internet-Draft, draft-ietf-lamps-lightweight- 1120 cmp-profile-10, 1 February 2022, 1121 . 1124 [NIST.FIPS.180-4] 1125 Dang, Quynh H., "Secure Hash Standard", NIST NIST FIPS 1126 180-4, DOI 10.6028/NIST.FIPS.180-4, July 2015, 1127 . 1130 [NIST.FIPS.186-4] 1131 National Institute of Standards and Technology (NIST), 1132 "Digital Signature Standard (DSS)", NIST NIST FIPS 186-4, 1133 DOI 10.6028/NIST.FIPS.186-4, July 2013, 1134 . 1137 [NIST.FIPS.186-5] 1138 National Institute of Standards and Technology (NIST), 1139 "FIPS Pub 186-5 (Draft): Digital Signature Standard 1140 (DSS)", October 2019, 1141 . 1144 [NIST.FIPS.197] 1145 National Institute of Standards and Technology (NIST), 1146 "Advanced encryption standard (AES)", NIST NIST FIPS 197, 1147 DOI 10.6028/NIST.FIPS.197, November 2001, 1148 . 1151 [NIST.FIPS.198-1] 1152 National Institute of Standards and Technology (NIST), 1153 "The Keyed-Hash Message Authentication Code (HMAC)", 1154 NIST NIST FIPS 198-1, DOI 10.6028/NIST.FIPS.198-1, July 1155 2008, . 1158 [NIST.FIPS.202] 1159 Dworkin, Morris J., "SHA-3 Standard: Permutation-Based 1160 Hash and Extendable-Output Functions", NIST NIST FIPS 202, 1161 DOI 10.6028/NIST.FIPS.202, July 2015, 1162 . 1165 [NIST.SP.800-185] 1166 Kelsey, John., Change, Shu-jen., and Ray. Perlner, "SHA-3 1167 derived functions: cSHAKE, KMAC, TupleHash and 1168 ParallelHash", NIST NIST SP 800-185, 1169 DOI 10.6028/NIST.SP.800-185, December 2016, 1170 . 1173 [NIST.SP.800-38d] 1174 Dworkin, M J., "Recommendation for block cipher modes of 1175 operation :GaloisCounter Mode (GCM) and GMAC", NIST NIST 1176 SP 800-38d, DOI 10.6028/NIST.SP.800-38d, 2007, 1177 . 1180 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1181 Hashing for Message Authentication", RFC 2104, 1182 DOI 10.17487/RFC2104, February 1997, 1183 . 1185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1186 Requirement Levels", BCP 14, RFC 2119, 1187 DOI 10.17487/RFC2119, March 1997, 1188 . 1190 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1191 RFC 2631, DOI 10.17487/RFC2631, June 1999, 1192 . 1194 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1195 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 1196 . 1198 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1199 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 1200 September 2002, . 1202 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport 1203 Algorithm in Cryptographic Message Syntax (CMS)", 1204 RFC 3560, DOI 10.17487/RFC3560, July 2003, 1205 . 1207 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1208 Encryption Algorithm in Cryptographic Message Syntax 1209 (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, 1210 . 1212 [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in 1213 Cryptographic Message Syntax (CMS)", RFC 4056, 1214 DOI 10.17487/RFC4056, June 2005, 1215 . 1217 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1218 "Internet X.509 Public Key Infrastructure Certificate 1219 Management Protocol (CMP)", RFC 4210, 1220 DOI 10.17487/RFC4210, September 2005, 1221 . 1223 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1224 Certificate Request Message Format (CRMF)", RFC 4211, 1225 DOI 10.17487/RFC4211, September 2005, 1226 . 1228 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 1229 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 1230 RFC 4231, DOI 10.17487/RFC4231, December 2005, 1231 . 1233 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1234 "Elliptic Curve Cryptography Subject Public Key 1235 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 1236 . 1238 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1239 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1240 . 1242 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 1243 Cryptography (ECC) Algorithms in Cryptographic Message 1244 Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 1245 2010, . 1247 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 1248 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 1249 2010, . 1251 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1252 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1253 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1254 . 1256 [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: 1257 Password-Based Cryptography Specification Version 2.1", 1258 RFC 8018, DOI 10.17487/RFC8018, January 2017, 1259 . 1261 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1262 Signature Algorithm (EdDSA)", RFC 8032, 1263 DOI 10.17487/RFC8032, January 2017, 1264 . 1266 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1267 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1268 May 2017, . 1270 [RFC8418] Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key 1271 Agreement Algorithm with X25519 and X448 in the 1272 Cryptographic Message Syntax (CMS)", RFC 8418, 1273 DOI 10.17487/RFC8418, August 2018, 1274 . 1276 [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature 1277 Algorithm (EdDSA) Signatures in the Cryptographic Message 1278 Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 1279 2018, . 1281 [RFC8702] Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash 1282 Functions in the Cryptographic Message Syntax (CMS)", 1283 RFC 8702, DOI 10.17487/RFC8702, January 2020, 1284 . 1286 [RFC9044] Housley, R., "Using the AES-GMAC Algorithm with the 1287 Cryptographic Message Syntax (CMS)", RFC 9044, 1288 DOI 10.17487/RFC9044, June 2021, 1289 . 1291 [RFC9045] Housley, R., "Algorithm Requirements Update to the 1292 Internet X.509 Public Key Infrastructure Certificate 1293 Request Message Format (CRMF)", RFC 9045, 1294 DOI 10.17487/RFC9045, June 2021, 1295 . 1297 12. Informative References 1299 [ECRYPT.CSA.D5.4] 1300 University of Bristol, "Algorithms, Key Size and Protocols 1301 Report (2018)", March 2015, 1302 . 1305 [NIST.SP.800-57pt1r5] 1306 Barker, Elaine., "Recommendation for key management:part 1 1307 - general", NIST NIST SP 800-57pt1r5, 1308 DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, 1309 . 1312 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1313 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1314 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 1315 April 2019, . 1317 [RFC8692] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key 1318 Infrastructure: Additional Algorithm Identifiers for 1319 RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, 1320 DOI 10.17487/RFC8692, December 2019, 1321 . 1323 Appendix A. History of Changes 1325 Note: This appendix will be deleted in the final version of the 1326 document. 1328 From version 11 -> 12: 1330 * Capitalized all headlines 1332 From version 10 -> 11: 1334 * Changes on the tables in Section 7 after direct exchange with 1335 Quynh 1337 From version 09 -> 10: 1339 * Removed the pre-RFC5378 work disclaimer after the RFC 4210 authors 1340 granted BCP78 rights to the IETF Trust 1341 * Implemented the changes proposed by Quynh, (see thread "Quynh 1342 Action: draft-ietf-lamps-cmp-algorithms-08.txt") and removed 1343 markers for ToDos regarding this review of SHAKE and KMAC usage as 1344 well as on the tables in Section 7 1346 From version 08 -> 09: 1348 * Updated IPR disclaimer 1350 From version 07 -> 08: 1352 * Fixing issues from WG and AD review 1353 * Adding Note to Section 2.2, 3.3, and 6.2.3 regarding usage of 1354 SHAKE and KMAC and added ToDo regarding checking respective notes 1355 * Added two tables showing algorithms sorted by their strength to 1356 Section 7 and added ToDo regarding checking theses tables 1357 * Updates the algorithm use profile in Section 7.1 1358 * Updated and added security consideration on SHAKE, 1359 PasswordBasedMac, KMAC, and symmetric key-based MAC functions and 1360 added ToDo regarding checking the security consideration on SHAKE 1362 From version 06 -> 07: 1364 * Fixing minor formatting nits 1366 From version 05 -> 06: 1368 * Added text to Section 2 and Section 3.3 to clearly specify the 1369 hash algorithm to use for certConf messages for certificates 1370 signed with EdDSA (see thread "[CMP Updates] Hash algorithm to us 1371 for calculating certHash") 1372 * Updated new RFC numbers for I-D.ietf-lamps-cms-aes-gmac-alg and I- 1373 D.ietf-lamps-crmf-update-algs 1375 From version 04 -> 05: 1377 * Minor changes and corrections in wording 1379 From version 03 -> 04: 1381 * Added John Gray to the list of authors due to his extensive 1382 support and valuable feedback 1383 * Added some clarification of the use AES-GMAC to Section 6.2.1 1384 * Extended the guidance on how to select a set of algorithms in 1385 Section 7 and deleted former Section 7.1 1386 * Deleted the algorithms mandatory to support in Section 7.2 as 1387 discussed at IETF 110 1388 * Extended the Security considerations in Section 9 1389 * Minor changes in wording 1391 From version 02 -> 03: 1393 * Moved former Appendix A to new Section 7 as suggested by Rich and 1394 Russ (see thread "I-D Action: draft-ietf-lamps-cmp-algorithms- 1395 02.txt") 1396 * Added a column to Table 1 in Section 7.2 to reflect the changes to 1397 RFC 4210 1398 * Updated Table 2 in Section 7.3 1399 * Added a paragraph to Section 9 to discuss backward compatibility 1400 with RFC 4210 1401 * Minor changes in wording 1403 From version 01 -> 02: 1405 * Added Hans Aschauer, Mike Ounsworth, and Serge Mister as co-author 1406 * Changed to XML V3 1407 * Added SHAKE digest algorithm to Section 2 as discussed at IETF 109 1408 * Deleted DSA from Section 3 as discussed at IETF 109 1409 * Added RSASSA-PSS with SHAKE to Section 3 1410 * Added SECP curves the section on ECDSA with SHA2, ECDSA with 1411 SHAKE, and EdDSA to Section 3 as discussed at IETF 109 1412 * Deleted static-static D-H and ECDH from Section 4.1 based on the 1413 discussion on the mailing list (see thread "[CMP Algorithms] 1414 Section 4.1.1 and 4.1.2 drop static-static (EC)DH key agreement 1415 algorithms for use in CMP") 1416 * Added ECDH OIDs and SECP curves, as well as ECDH with curve25519 1417 and curve448 to Section 4.1 as discussed at IETF 109 1418 * Deleted RSA-OAEP from Section 4.2 first as discussed at IETF 109, 1419 but re-added it after discussion on the mailing list (see thread 1420 "Mail regarding draft-ietf-lamps-cmp-algorithms") 1421 * Added a paragraph to Section 4.3.1 to explain that the algorithms 1422 and key length for content encryption and key wrapping must be 1423 aligned as discussed on the mailing list (see thread "[CMP 1424 Algorithms] Use Key-Wrap with or without padding in Section 4.3 1425 and Section 5") 1426 * Deleted AES-CCM and AES-GMC from and added AES-CBC to Section 5 as 1427 discussed at IETF 109 1428 * Added Section 6.1.2 to offer PBMAC1 as discusses on the mailing 1429 list (see thread "Mail regarding draft-ietf-lamps-crmf-update- 1430 algs-02") and restructured text in Section 6 to be easier to 1431 differentiate between password- and shared-key-based MAC 1432 * Deleted Diffie-Hellmann based MAC from Section 6 as is only 1433 relevant when using enrolling Diffie-Hellmann certificates 1434 * Added AES-GMAC and SHAKE-based KMAC to Section 6 as discussed at 1435 IETF 109 1436 * Extended Section 9 to mention Russ supporting with two additional 1437 I-Ds and name further supporters of the draft 1438 * Added a first draft of a generic algorithm selection guideline to 1439 Appendix A 1440 * Added a first proposal for mandatory algorithms for the 1441 Lightweight CMP Profile to Appendix A 1442 * Minor changes in wording 1444 From version 00 -> 01: 1446 * Changed sections Symmetric Key-Encryption Algorithms and Content 1447 Encryption Algorithms based on the discussion on the mailing list 1448 (see thread "[CMP Algorithms] Use Key-Wrap with or without padding 1449 in Section 4.3 and Section 5") 1450 * Added Appendix A with updated algorithms profile for RDC4210 1451 Appendix D.2 and first proposal for the Lightweight CMP Profile 1452 * Minor changes in wording 1454 Authors' Addresses 1456 Hendrik Brockhaus (editor) 1457 Siemens AG 1458 Email: hendrik.brockhaus@siemens.com 1460 Hans Aschauer 1461 Siemens AG 1462 Email: hans.aschauer@siemens.com 1464 Mike Ounsworth 1465 Entrust 1466 Email: mike.ounsworth@entrust.com 1468 John Gray 1469 Entrust 1470 Email: john.gray@entrust.com