idnits 2.17.1 draft-ietf-lamps-cmp-algorithms-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4210, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 (5 May 2021) is 1079 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) == Missing Reference: 'RFC5480' is mentioned on line 379, but not defined == Outdated reference: A later version (-23) exists of draft-ietf-lamps-cmp-updates-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 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-05 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS Working Group H. Brockhaus, Ed. 3 Internet-Draft H. Aschauer 4 Updates: 4210 (if approved) Siemens 5 Intended status: Standards Track M. Ounsworth 6 Expires: 6 November 2021 J. Gray 7 Entrust 8 5 May 2021 10 Certificate Management Protocol (CMP) Algorithms 11 draft-ietf-lamps-cmp-algorithms-04 13 Abstract 15 This document describes the conventions for using concrete 16 cryptographic algorithms with the Certificate Management Protocol 17 (CMP). CMP is used to enroll and further manage the lifecycle of 18 X.509 certificates. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 6 November 2021. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Message Digest Algorithms . . . . . . . . . . . . . . . . . . 3 56 2.1. SHA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . 7 64 4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 8 65 4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 10 67 4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 4.3. Symmetric Key-Encryption Algorithms . . . . . . . . . . . 11 69 4.3.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 11 70 4.4. Key Derivation Algorithms . . . . . . . . . . . . . . . . 12 71 4.4.1. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . 12 72 5. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12 73 5.1. AES-CBC . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6. Message Authentication Code Algorithms . . . . . . . . . . . 13 75 6.1. Password-based MAC . . . . . . . . . . . . . . . . . . . 13 76 6.1.1. PasswordBasedMac . . . . . . . . . . . . . . . . . . 14 77 6.1.2. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . 14 78 6.2. Symmetric key-based MAC . . . . . . . . . . . . . . . . . 14 79 6.2.1. SHA2-based HMAC . . . . . . . . . . . . . . . . . . . 15 80 6.2.2. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . 15 81 6.2.3. SHAKE-based KMAC . . . . . . . . . . . . . . . . . . 16 82 7. Algorithm Use Profiles . . . . . . . . . . . . . . . . . . . 16 83 7.1. Algorithm Profile for RFC 4210 PKI Management Message 84 Profiles . . . . . . . . . . . . . . . . . . . . . . . . 17 85 7.2. Algorithm Profile for Lightweight CMP Profile . . . . . . 19 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 89 11. Normative References . . . . . . . . . . . . . . . . . . . . 22 90 12. Informative References . . . . . . . . . . . . . . . . . . . 26 91 Appendix A. History of changes . . . . . . . . . . . . . . . . . 26 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 94 1. Introduction 96 1.1. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in BCP 14 [RFC2119] 101 [RFC8174] when, and only when, they appear in all capitals, as shown 102 here. 104 2. Message Digest Algorithms 106 This section provides references to object identifiers and 107 conventions to be employed by CMP implementations that support SHA2 108 or SHAKE message digest algorithms. 110 Digest algorithm identifiers are located in the hashAlg field of 111 OOBCertHash, the owf field of Challenge, PBMParameter, and 112 DHBMParameter, and the digestAlgorithms field of SignedData and the 113 digestAlgorithm field of SignerInfo. 115 Digest values are located in the hashVal field of OOBCertHash, the 116 witness field of Challenge, and the certHash field of CertStatus. In 117 addition, digest values are input to signature algorithms. 119 2.1. SHA2 121 The SHA2 algorithm family is defined in FIPS Pub 180-4 122 [NIST.FIPS.180-4]. 124 The message digest algorithms SHA-224, SHA-256, SHA-384, and SHA-512 125 are identified by the following OIDs: 127 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 128 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 129 hashalgs(2) 4 } 130 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 131 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 132 hashalgs(2) 1 } 133 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 134 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 135 hashalgs(2) 2 } 136 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 137 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 138 hashalgs(2) 3 } 140 Specific conventions to be considered are specified in RFC 5754 141 Section 2 [RFC5754]. 143 2.2. SHAKE 145 The SHA-3 family of hash functions is defined in FIPS Pub 202 146 [NIST.FIPS.202] and includes fixed output length variants SHA3-224, 147 SHA3-256, SHA3-384, and SHA3-512, as well as extendable-output 148 functions (SHAKEs) SHAKE128 and SHAKE256. Currently SHAKE128 and 149 SHAKE256 are the only members of the SHA3-family which are specified 150 for use in X.509 and PKIX [RFC8692], and CMS [RFC8702]. Therefore, 151 CMP specifies them as defined in RFC 8702 [RFC8702], which are 152 identified by the following OIDs: 154 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 155 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 156 hashalgs(2) 11 } 157 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 158 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 159 hashalgs(2) 12 } 161 Specific conventions to be considered are specified in RFC 8702 162 Section 3.1 [RFC8702]. 164 3. Signature Algorithms 166 This section provides references to object identifiers and 167 conventions to be employed by CMP implementations that support RSA, 168 ECDSA, or EdDSA signature algorithms. 170 The signature algorithm is referred to as MSG_SIG_ALG in Section 7.2, 171 RFC 4210 Appendix D and E [RFC4210], and in the Lightweight CMP 172 Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 174 Signature algorithm identifiers are located in the protectionAlg 175 field of PKIHeader, the algorithmIdentifier field of POPOSigningKey, 176 signatureAlgorithm field of CertificationRequest, SignKeyPairTypes, 177 and the SignerInfo signatureAlgorithm field of SignedData. 179 Signature values are located in the protection field of PKIMessage, 180 signature field of POPOSigningKey, signature field of 181 CertificationRequest, and SignerInfo signature field of SignedData. 183 3.1. RSA 185 The RSA (RSASSA-PSS and PKCS#1 version 1.5) signature algorithm is 186 defined in RFC 8017 [RFC8017]. 188 The algorithm identifiers for RSASAA-PSS signatures used with SHA2 189 message digest algorithms is identified by the following OID: 191 id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2) 192 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 } 194 Specific conventions to be considered are specified in RFC 4056 195 [RFC4056]. 197 The signature algorithm RSASSA-PSS used with SHAKE message digest 198 algorithms are identified by the following OIDs: 200 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) 201 identified-organization(3) dod(6) internet(1) security(5) 202 mechanisms(5) pkix(7) algorithms(6) 30 } 203 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) 204 identified-organization(3) dod(6) internet(1) security(5) 205 mechanisms(5) pkix(7) algorithms(6) 31 } 207 Specific conventions to be considered are specified in RFC 8702 208 Section 3.2.1 [RFC8702]. 210 The signature algorithm PKCS#1 version 1.5 used with SHA2 message 211 digest algorithms is identified by the following OIDs: 213 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 214 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } 215 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 216 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } 217 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 218 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } 219 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 220 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } 222 Specific conventions to be considered are specified in RFC 5754 223 Section 3.2 [RFC5754]. 225 3.2. ECDSA 227 The ECDSA signature algorithm is defined in FIPS Pub 186-4 228 [NIST.FIPS.186-4]. 230 The signature algorithm ECDSA used with SHA2 message digest 231 algorithms is identified by the following OIDs: 233 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 234 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } 235 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 236 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 237 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 238 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 239 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 240 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 242 As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves 243 are identified by the following OIDs: 245 secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 246 us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } 247 secp224r1 OBJECT IDENTIFIER ::= { iso(1) 248 identified-organization(3) certicom(132) curve(0) 33 } 249 secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 250 us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } 251 secp384r1 OBJECT IDENTIFIER ::= { iso(1) 252 identified-organization(3) certicom(132) curve(0) 34 } 253 secp521r1 OBJECT IDENTIFIER ::= { iso(1) 254 identified-organization(3) certicom(132) curve(0) 35 } 256 Specific conventions to be considered are specified in RFC 5754 257 Section 3.3 [RFC5754]. 259 The signature algorithm ECDSA used with SHAKE message digest 260 algorithms are identified by the following OIDs: 262 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) 263 identified-organization(3) dod(6) internet(1) security(5) 264 mechanisms(5) pkix(7) algorithms(6) 32 } 265 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) 266 identified-organization(3) dod(6) internet(1) security(5) 267 mechanisms(5) pkix(7) algorithms(6) 33 } 269 Specific conventions to be considered are specified in RFC 8702 270 Section 3.2.2 [RFC8702]. 272 3.3. EdDSA 274 The EdDSA signature algorithm is defined in RFC 8032 Section 3.3 275 [RFC8032] and FIPS Pub 186-5 (Draft) [NIST.FIPS.186-5]. 277 The signature algorithm Ed25519 MUST be used with SHA-512 message 278 digest algorithms is identified by the following OIDs: 280 id-Ed25519 OBJECT IDENTIFIER ::= { iso(1) 281 identified-organization(3) thawte(101) 112 } 283 The signature algorithm Ed448 MUST be used with SHAKE256 message 284 digest algorithms is identified by the following OIDs: 286 id-Ed448 OBJECT IDENTIFIER ::= { iso(1) 287 identified-organization(3) thawte(101) 113 } 289 Specific conventions to be considered are specified in RFC 8419 290 [RFC8419]. 292 4. Key Management Algorithms 294 CMP utilizes the following general key management techniques: key 295 agreement, key transport, and passwords. 297 CRMF [RFC4211] and CMP Updates [I-D.ietf-lamps-cmp-updates] promotes 298 the use of CMS [RFC5652] EnvelopedData by deprecating the use of 299 EncryptedValue. 301 4.1. Key Agreement Algorithms 303 The key agreement algorithm is referred to as PROT_ENC_ALG in 304 RFC 4210 Appendix D and E [RFC4210] and as KM_KA_ALG in the 305 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as 306 well as in Section 7. 308 Key agreement algorithms are only used in CMP when using CMS 309 [RFC5652] EnvelopedData together with the key agreement key 310 management technique. When a key agreement algorithm is used, a key- 311 encryption algorithm (Section 4.3) is needed next to the content- 312 encryption algorithm (Section 5). 314 Key agreement algorithm identifiers are located in the EnvelopedData 315 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. 317 Key encryption algorithm identifiers are located in the EnvelopedData 318 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field. 320 Wrapped content-encryption keys are located in the EnvelopedData 321 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 322 encryptedKey field. 324 4.1.1. Diffie-Hellman 326 Diffie-Hellman key agreement is defined in RFC 2631 [RFC2631] and 327 SHALL be used in the ephemeral-static as specified in RFC 3370 328 [RFC3370]. Static-static variants SHALL NOT be used. 330 The Diffie-Hellman key agreement algorithm is identified by the 331 following OID: 333 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) 334 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 336 Specific conventions to be considered are specified in RFC 3370 337 Section 4.1 [RFC3370]. 339 4.1.2. ECDH 341 Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined in 342 RFC 5753 [RFC5753] and SHALL be used in the ephemeral-static variant 343 as specified in RFC 5753 [RFC5753] or the 1-Pass ECMQV variant as 344 specified in RFC 5753 [RFC5753]. Static-static variants SHALL NOT be 345 used. 347 The ECDH key agreement algorithm used together with NIST-recommended 348 SECP curves are identified by the following OIDs: 350 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 351 identified-organization(3) certicom(132) schemes(1) 11(11) 0 } 352 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 353 identified-organization(3) certicom(132) schemes(1) 11(11) 1 } 354 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 355 identified-organization(3) certicom(132) schemes(1) 11(11) 2 } 356 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 357 identified-organization(3) certicom(132) schemes(1) 11(11) 3 } 358 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 359 iso(1) identified-organization(3) certicom(132) schemes(1) 360 14(14) 0 } 361 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 362 iso(1) identified-organization(3) certicom(132) schemes(1) 363 14(14) 1 } 364 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 365 iso(1) identified-organization(3) certicom(132) schemes(1) 366 14(14) 2 } 367 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 368 iso(1) identified-organization(3) certicom(132) schemes(1) 369 14(14) 3 } 370 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 371 identified-organization(3) certicom(132) schemes(1) 15(15) 0 } 372 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 373 identified-organization(3) certicom(132) schemes(1) 15(15) 1 } 374 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 375 identified-organization(3) certicom(132) schemes(1) 15(15) 2 } 376 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 377 identified-organization(3) certicom(132) schemes(1) 15(15) 3 } 379 As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves 380 are identified by the following OIDs: 382 secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 383 us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } 384 secp224r1 OBJECT IDENTIFIER ::= { iso(1) 385 identified-organization(3) certicom(132) curve(0) 33 } 386 secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 387 us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } 388 secp384r1 OBJECT IDENTIFIER ::= { iso(1) 389 identified-organization(3) certicom(132) curve(0) 34 } 390 secp521r1 OBJECT IDENTIFIER ::= { iso(1) 391 identified-organization(3) certicom(132) curve(0) 35 } 393 Specific conventions to be considered are specified in RFC 5753 394 [RFC5753]. 396 The ECDH key agreement algorithm used together with curve25519 or 397 curve448 are identified by the following OIDs: 399 id-X25519 OBJECT IDENTIFIER ::= { iso(1) 400 identified-organization(3) thawte(101) 110 } 401 id-X448 OBJECT IDENTIFIER ::= { iso(1) 402 identified-organization(3) thawte(101) 111 } 404 Specific conventions to be considered are specified in RFC 8418 405 [RFC8418]. 407 4.2. Key Transport Algorithms 409 The key transport algorithm is also referred to as PROT_ENC_ALG in 410 RFC 4210 Appendix D and E [RFC4210] and as KM_KL_ALG in the 411 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as 412 well as in Section 7. 414 Key transport algorithms are only used in CMP when using CMS 415 [RFC5652] EnvelopedData together with the key transport key 416 management technique. 418 Key transport algorithm identifiers are located in the EnvelopedData 419 RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field. 421 Key transport encrypted content-encryption keys are located in the 422 EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey 423 field. 425 4.2.1. RSA 427 The RSA key transport algorithm is the RSA encryption scheme defined 428 in RFC 8017 [RFC8017]. 430 The algorithm identifier for RSA (PKCS #1 v1.5) is: 432 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 433 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 435 The algorithm identifier for RSAES-OAEP is: 437 id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) 438 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } 440 Further conventions to be considered for PKCS #1 v1.5 are specified 441 in RFC 3370 Section 4.2.1 [RFC3370] and for RSAES-OAEP in RFC 3560 442 [RFC3560]. 444 4.3. Symmetric Key-Encryption Algorithms 446 The symmetric key-encryption algorithm is also referred to as 447 KM_KW_ALG in Section 7.2 and in the Lightweight CMP Profile 448 [I-D.ietf-lamps-lightweight-cmp-profile]. 450 As symmetric key-encryption key management technique is not used by 451 CMP, the symmetric key-encryption algorithm is only needed when using 452 the key agreement or password-based key management technique with CMS 453 [RFC5652] EnvelopedData. 455 Key-encryption algorithm identifiers are located in the EnvelopedData 456 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 457 EnvelopedData RecipientInfos PasswordRecipientInfo 458 keyEncryptionAlgorithm fields. 460 Wrapped content-encryption keys are located in the EnvelopedData 461 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 462 encryptedKey and EnvelopedData RecipientInfos PasswordRecipientInfo 463 encryptedKey fields. 465 4.3.1. AES Key Wrap 467 The AES encryption algorithm is defined in FIPS Pub 197 468 [NIST.FIPS.197] and the key wrapping is defined in RFC 3394 469 [RFC3394]. 471 AES key encryption has the algorithm identifier: 473 id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 474 country(16) us(840) organization(1) gov(101) csor(3) 475 nistAlgorithm(4) aes(1) 5 } 476 id-aes192-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 477 country(16) us(840) organization(1) gov(101) csor(3) 478 nistAlgorithm(4) aes(1) 25 } 479 id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 480 country(16) us(840) organization(1) gov(101) csor(3) 481 nistAlgorithm(4) aes(1) 45 } 483 The underlying encryption functions for the key wrap and content- 484 encryption algorithms (as specified in Section 5) and the key sizes 485 for the two algorithms MUST be the same (e.g., AES-128 key wrap 486 algorithm with AES-128 content-encryption algorithm), see also 487 RFC 8551 [RFC8551]. 489 Further conventions to be considered for AES key wrap are specified 490 in RFC 3394 Section 2.2 [RFC3394] and RFC 3565 Section 2.3.2 491 [RFC3565]. 493 4.4. Key Derivation Algorithms 495 The key derivation algorithm is also referred to as KM_KD_ALG in 496 Section 7.2 and in the Lightweight CMP Profile 497 [I-D.ietf-lamps-lightweight-cmp-profile]. 499 Key derivation algorithms are only used in CMP when using CMS 500 [RFC5652] EnvelopedData together with password-based key management 501 technique. 503 Key derivation algorithm identifiers are located in the EnvelopedData 504 RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm field. 506 When using the password-based key management technique with 507 EnvelopedData as specified in CMP Updates together with MAC-based 508 PKIProtection, the salt for the password-based MAC and KDF must be 509 chosen independently to ensure usage of independent symmetric keys. 511 4.4.1. PBKDF2 513 The password-based key derivation function 2 (PBKDF2) is defined in 514 RFC 8018 [RFC8018]. 516 Password-based key derivation function 2 has the algorithm 517 identifier: 519 id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 520 rsadsi(113549) pkcs(1) pkcs-5(5) 12 } 522 Further conventions to be considered for PBKDF2 are specified in 523 RFC 3370 Section 4.4.1 [RFC3370] and RFC 8018 Section 5.2 [RFC8018]. 525 5. Content Encryption Algorithms 527 The content encryption algorithm is also referred to as PROT_SYM_ALG 528 in Section 7, RFC 4210 Appendix D and E [RFC4210], and the 529 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 531 Content encryption algorithms are only used in CMP when using CMS 532 [RFC5652] EnvelopedData to transport a signed private key package in 533 case of central key generation or key archiving, a certificate to 534 facilitate implicit proofe-of-possession, or a revocation passphrase 535 in encrypted form. 537 Content encryption algorithm identifiers are located in the 538 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field. 540 Encrypted content is located in the EnvelopedData 541 EncryptedContentInfo encryptedContent field. 543 5.1. AES-CBC 545 The AES encryption algorithm is defined in FIPS Pub 197 546 [NIST.FIPS.197]. 548 AES-CBC content encryption has the algorithm identifier: 550 id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 551 country(16) us(840) organization(1) gov(101) csor(3) 552 nistAlgorithm(4) aes(1) 2 } 553 id-aes192-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 554 country(16) us(840) organization(1) gov(101) csor(3) 555 nistAlgorithm(4) aes(1)22 } 556 id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 557 country(16) us(840) organization(1) gov(101) csor(3) 558 nistAlgorithm(4) aes(1)42 } 560 Specific conventions to be considered for AES-CBC content encryption 561 are specified in RFC 3565 [RFC3565]. 563 6. Message Authentication Code Algorithms 565 The message authentication code is either used for shared secret- 566 based CMP message protection or together with the password-based key 567 derivation function (PBKDF2). 569 The message authentication code algorithm is also referred to as 570 MSG_MAC_ALG in Section 7, RFC 4210 Appendix D and E [RFC4210], and 571 the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 573 6.1. Password-based MAC 575 Password-based MAC algorithms combine the derivation of a symmetric 576 key from a password or other shared secret information and a 577 symmetric key-based MAC function as specified in Section 6.2 using 578 this derived key. 580 Message authentication code algorithm identifiers are located in the 581 protectionAlg field of PKIHeader. 583 Message authentication code values are located in the PKIProtection 584 field. 586 6.1.1. PasswordBasedMac 588 The PasswordBasedMac algorithm is defined in RFC 4210 Section 5.1.3.1 589 [RFC4210], RFC 4211 Section 4.4 [RFC4211], and Algorithm Requirements 590 Update to the Internet X.509 Public Key Infrastructure Certificate 591 Request Message Format (CRMF) [I-D.ietf-lamps-crmf-update-algs]. 593 The PasswordBasedMac algorithm is identified by the following OID: 595 id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 596 us(840) nt(113533) nsn(7) algorithms(66) 13 } 598 Further conventions to be considered for password-based MAC are 599 specified in RFC 4210 Section 5.1.3.1 [RFC4210], RFC 4211 Section 4.4 600 [RFC4211], and Algorithm Requirements Update to the Internet X.509 601 Public Key Infrastructure Certificate Request Message Format (CRMF) 602 [I-D.ietf-lamps-crmf-update-algs]. 604 6.1.2. PBMAC1 606 The Password-Based Message Authentication Code 1 (PBMAC1) is defined 607 in RFC 8018 [RFC8018]. PBMAC1 combines a password-based key 608 derivation function like PBKDF2 (Section 4.4.1) with an underlying 609 symmetric key-based message authentication scheme. 611 PBMAC1 has the following OID: 613 id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 614 rsadsi(113549) pkcs(1) pkcs-5(5) 14 } 616 Specific conventions to be considered for PBMAC1 are specified in 617 RFC 8018 Section 7.1 and A.5 [RFC8018]. 619 6.2. Symmetric key-based MAC 621 Symmetric key-based MAC algorithms are used for deriving the 622 symmetric encryption key when using PBKDF2 as described in 623 Section 4.4.1 as well as with Password-based MAC as described in 624 Section 6.1. 626 Message authentication code algorithm identifiers are located in the 627 protectionAlg field of PKIHeader, the mac field of PBMParameter, the 628 messageAuthScheme field of PBMAC1, and the prf field of 629 PBKDF2-params. 631 Message authentication code values are located in the PKIProtection 632 field. 634 6.2.1. SHA2-based HMAC 636 The HMAC algorithm is defined in RFC 2104 [RFC2104] and 637 FIPS Pub 198-1 [NIST.FIPS.198-1]. 639 The HMAC algorithm used with SHA2 message digest algorithms is 640 identified by the following OIDs: 642 id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 643 us(840) rsadsi(113549) digestAlgorithm(2) 8 } 644 id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 645 us(840) rsadsi(113549) digestAlgorithm(2) 9 } 646 id-hmacWithSHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 647 us(840) rsadsi(113549) digestAlgorithm(2) 10 } 648 id-hmacWithSHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 649 us(840) rsadsi(113549) digestAlgorithm(2) 11 } 651 Specific conventions to be considered for SHA2-based HMAC are 652 specified in RFC 4231 Section 3.1 [RFC4231]. 654 6.2.2. AES-GMAC 656 The AES-GMAC algorithm is defined in FIPS Pub 197 [NIST.FIPS.197] and 657 NIST SP 800-38d [NIST.SP.800-38d]. 659 NOTE: AES-GMAC MUST NOT be used twice with the same parameter set, 660 especially the same nonce. Therefore, it MUST NOT be used together 661 with PBKDF2. When using it with PBMAC1 it MUST be ensured that AES- 662 GMAC is only used as message authentication scheme and not for the 663 key derivation function PBKDF2. 665 The AES-GMAC algorithm is identified by the following OIDs: 667 id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 668 country(16) us(840) organization(1) gov(101) csor(3) 669 nistAlgorithm(4) aes(1) 9 } 670 id-aes192-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 671 country(16) us(840) organization(1) gov(101) csor(3) 672 nistAlgorithm(4) aes(1) 29 } 673 id-aes256-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 674 country(16) us(840) organization(1) gov(101) csor(3) 675 nistAlgorithm(4) aes(1) 49 } 677 Specific conventions to be considered for AES-GMAC are specified in 678 draft-ietf-lamps-cms-aes-gmac-alg [I-D.ietf-lamps-cms-aes-gmac-alg]. 680 6.2.3. SHAKE-based KMAC 682 The KMAC algorithm is defined in RFC 8702 [RFC8702] and 683 FIPS SP 800-185 [NIST.SP.800-185]. 685 The SHAKE-based KMAC algorithm is identified by the following OIDs: 687 id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 688 country(16) us(840) organization(1) gov(101) csor(3) 689 nistAlgorithm(4) 2 19 } 690 id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 691 country(16) us(840) organization(1) gov(101) csor(3) 692 nistAlgorithm(4) 2 20 } 694 Specific conventions to be considered for KMAC with SHAKE are 695 specified in RFC 8702 Section 3.4 [RFC8702]. 697 7. Algorithm Use Profiles 699 This section provides profiles of algorithms and respective 700 conventions for different application use cases. 702 To promote interoperability, based on the recommendations of NIST 703 SP 800-57 Recommendation for Key Management [NIST.SP.800-57pt1r5] and 704 ECRYPT Algorithms, Key Size and Protocols Report (2018) 705 [ECRYPT.CSA.D5.4], the following guidelines should be followed. 707 The strength of the overall certificate management system is 708 determined by two criteria: 710 * The cryptographic strength of the algorithm with the lowest 711 security. 713 Note: To avoid consuming too much computational resources it is 714 recommended to choose a set of algorithms offering roughly the 715 same level of security. 717 * The entropy of the shared secret information or password when MAC- 718 based message protection is used, e.g., MSG_MAC_ALG. 720 Finally, the cryptographic strength of the system SHOULD be at least 721 as strong as the algorithms and keys used for the certificate being 722 managed. 724 7.1. Algorithm Profile for RFC 4210 PKI Management Message Profiles 726 The following table contains definitions of algorithms used within 727 PKI Management Message Profiles as defined in CMP Appendix D.2 728 [RFC4210]. 730 The columns in the table are: 732 Name: An identifier used for message profiles 734 Use: Description of where and for what the algorithm is used 736 Mandatory: Algorithms which MUST be supported by conforming 737 implementations 739 Change from 4210: Shows the changes in the Mandatory and Other 740 algorithms from RFC 4210 [RFC4210]. These are included for backwards 741 compatibility considerations. 743 +============+===============+==================+===================+ 744 |Name |Use | Mandatory |Change from 4210 | 745 +============+===============+==================+===================+ 746 |MSG_SIG_ALG |protection of | RSA |DSA/SHA1 | 747 | |PKI messages | |Others: RSA/MD5, | 748 | |using signature| |ECDSA | 749 +------------+---------------+------------------+-------------------+ 750 |MSG_MAC_ALG |protection of | PasswordBasedMac |PasswordBasedMac | 751 | |PKI messages | (RECOMMENDED: |Others: HMAC, X9.9 | 752 | |using MACing | PBMAC1) | | 753 +------------+---------------+------------------+-------------------+ 754 |SYM_PENC_ALG|symmetric | AES-wrap |3-DES(3-key-EDE), | 755 | |encryption of | |CBC Mode | 756 | |an end entity's| |Others: AES, RC5, | 757 | |private key | |CAST-128 | 758 | |where symmetric| | | 759 | |key is | | | 760 | |distributed | | | 761 | |out-of-band | | | 762 +------------+---------------+------------------+-------------------+ 763 |PROT_ENC_ALG|asymmetric | D-H |D-H | 764 | |algorithm used | |Others: RSA, ECDH | 765 | |for encryption | | | 766 | |of (symmetric | | | 767 | |keys for | | | 768 | |encryption of) | | | 769 | |private keys | | | 770 | |transported in | | | 771 | |PKIMessages | | | 772 +------------+---------------+------------------+-------------------+ 773 |PROT_SYM_ALG|symmetric | AES |3-DES(3-key-EDE), | 774 | |encryption | |CBC Mode | 775 | |algorithm used | |Others: AES, RC5, | 776 | |for encryption | |CAST-128 | 777 | |of private key | | | 778 | |bits (a key of | | | 779 | |this type is | | | 780 | |encrypted using| | | 781 | |PROT_ENC_ALG) | | | 782 +------------+---------------+------------------+-------------------+ 784 Table 1 786 Mandatory Algorithm Identifiers and Specifications: 788 RSA: sha256WithRSAEncryption with 2048 bit, see Section 3.1 789 PasswordBasedMac: id-PasswordBasedMac, see Section 6.1 (with id- 790 sha256 as the owf parameter, see Section 2.1 and id-hmacWithSHA256 as 791 the mac parameter, see Section 6.2.1) 793 PBMAC1: id-PBMAC1, see Section 6.1.2 (with id-PBKDF2 as the key 794 derivation function, see Section 4.4.1 and id-hmacWithSHA256 as 795 message authentication scheme, see Section 6.2.1). It is RECOMMENDED 796 to prefer the usage of PBMAC1 instead of PasswordBasedMac. 798 D-H: id-alg-ESDH, see Section 4.1.1 800 AES-wrap: id-aes256-wrap, see Section 4.3.1 802 AES: id-aes256-CBC, see Section 5.1 804 7.2. Algorithm Profile for Lightweight CMP Profile 806 The following table contains definitions of algorithms which MAY be 807 supported by implementations of the Lightweight CMP Profile 808 [I-D.ietf-lamps-lightweight-cmp-profile]. 810 As the set of algorithms to be used for implementations of the 811 Lightweight CMP Profile heavily depends on the PKI management 812 operations implemented, the certificates used for messages 813 protection, and the certificates to be managed, this document will 814 not specify a specific set that is mandatory to support for 815 conforming implementations. 817 The columns in the table are: 819 Name: An identifier used for message profiles 821 Use: Description of where and for what the algorithm is used 823 Examples: Lists the algorithms as described in this document. The 824 list of algorithms depends on the set of PKI management operations to 825 be implemented. 827 Note: It is RECOMMENDED to prefer the usage of PBMAC1 instead of 828 PasswordBasedMac. 830 +==============+================================+==================+ 831 | Name | Use | Examples | 832 +==============+================================+==================+ 833 | MSG_SIG_ALG | protection of PKI messages | RSA, ECDSA, | 834 | | using signature and for | EdDSA | 835 | | SignedData, e.g., a private | | 836 | | key transported in PKIMessages | | 837 +--------------+--------------------------------+------------------+ 838 | MSG_MAC_ALG | protection of PKI messages | PasswordBasedMac | 839 | | using MACing | (see Section 9), | 840 | | | PBMAC1 | 841 +--------------+--------------------------------+------------------+ 842 | KM_KA_ALG | asymmetric key agreement | D-H, ECDH | 843 | | algorithm used for agreement | | 844 | | of a symmetric key for use | | 845 | | with KM_KW_ALG | | 846 +--------------+--------------------------------+------------------+ 847 | KM_KT_ALG | asymmetric key encryption | RSA | 848 | | algorithm used for transport | | 849 | | of a symmetric key for | | 850 | | PROT_SYM_ALG | | 851 +--------------+--------------------------------+------------------+ 852 | KM_KD_ALG | symmetric key derivation | PBKDF2 | 853 | | algorithm used for derivation | | 854 | | of a symmetric key for use | | 855 | | with KM_KW_ALG | | 856 +--------------+--------------------------------+------------------+ 857 | KM_KW_ALG | algorithm to wrap a symmetric | AES-wrap | 858 | | key for PROT_SYM_ALG | | 859 +--------------+--------------------------------+------------------+ 860 | PROT_SYM_ALG | symmetric content encryption | AES | 861 | | algorithm used for encryption | | 862 | | of EnvelopedData, e.g., a | | 863 | | private key transported in | | 864 | | PKIMessages | | 865 +--------------+--------------------------------+------------------+ 867 Table 2 869 8. IANA Considerations 871 This document does not request changes to the IANA registry. 873 9. Security Considerations 875 RFC 4210 Appendix D.2 [RFC4210] contains a set of algorithms, 876 mandatory to be supported by conforming implementations. Theses 877 algorithms were appropriate at the time CMP was released, but as 878 cryptographic algorithms weaken over time, some of them should not be 879 used anymore. In general, new attacks are emerging due to research 880 cryptoanalysis or increase in computing power. New algorithms were 881 introduced that are more resistant to today's attacks. 883 This document lists many cryptographic algorithms usable with CMP to 884 offer implementers a more up to date choice. Finally, the algorithms 885 to be supported also heavily depend on the certificates and PKI 886 management operations utilized in the target environment. The 887 algorithm with the lowest security strength and the entropy of shared 888 secret information define the security of the overall solution, see 889 Section 7. 891 When using MAC-based message protection the use of PBMAC1 is 892 preferable to that of PasswordBasedMac: first, PBMAC1 is a well-known 893 scrutinized algorithm, which is not true for PasswordBasedMac and 894 second, there exists a theoretical weaknesses in PasswordBasedMac, 895 where the generated MAC key can be easily distinguished from a random 896 key. 898 As the pseudo random function is used several times in PBKDF2, AES- 899 GMAC MUST NOT be used here, because the security of AES-GMAC is 900 broken when using it twice with the same nonce. 902 In Section 7 of this document there is also an update to the 903 Appendix D.2 of RFC 4210 [RFC4210] and a set of algorithms that MAY 904 be supported when implementing the Lightweight CMP Profile 905 [I-D.ietf-lamps-lightweight-cmp-profile]. 907 To keep the list of algorithms to be used with CMP up to date and to 908 enlist secure algorithms resisting known attack scenarios, future 909 algorithms should be added and weakened algorithms should be 910 deprecated. 912 It is recognized that there may be older CMP implementations in use 913 that conform to the algorithm use profile from Appendix D.2 of 914 RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for 915 PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory. In most 916 cases the newer mandatory algorithms were listed as "other" 917 algorithms in RFC 4210 [RFC4210]. Therefore, it is expected that 918 many CMP systems may already support the recommended algorithms in 919 this specification. In such systems the weakened algorithms should 920 be disabled from further use. If critical systems cannot be 921 immediately updated to conform to the recommended algorithm use 922 profile, it is recommended a plan to migrate the infrastructure to 923 conforming profiles be adopted as soon as possible. 925 10. Acknowledgements 927 Thanks to Russ Housley for supporting this draft with submitting 928 [I-D.ietf-lamps-cms-aes-gmac-alg] and 929 [I-D.ietf-lamps-crmf-update-algs]. 931 May thanks also to all reviewers like Serge Mister, Mark Ferreira, 932 Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steffen 933 Fries for their input and feedback to this document. Apologies to 934 all not mentioned reviewers and supporters. 936 11. Normative References 938 [I-D.ietf-lamps-cmp-updates] 939 Brockhaus, H. and D. V. Oheimb, "Certificate Management 940 Protocol (CMP) Updates", Work in Progress, Internet-Draft, 941 draft-ietf-lamps-cmp-updates-10, 4 May 2021, 942 . 945 [I-D.ietf-lamps-cms-aes-gmac-alg] 946 Housley, R., "Using the AES-GMAC Algorithm with the 947 Cryptographic Message Syntax (CMS)", Work in Progress, 948 Internet-Draft, draft-ietf-lamps-cms-aes-gmac-alg-05, 2 949 April 2021, . 952 [I-D.ietf-lamps-crmf-update-algs] 953 Housley, R., "Algorithm Requirements Update to the 954 Internet X.509 Public Key Infrastructure Certificate 955 Request Message Format (CRMF)", Work in Progress, 956 Internet-Draft, draft-ietf-lamps-crmf-update-algs-07, 8 957 April 2021, . 960 [NIST.FIPS.180-4] 961 Dang, Quynh H., "Secure Hash Standard", NIST NIST FIPS 962 180-4, DOI 10.6028/NIST.FIPS.180-4, July 2015, 963 . 966 [NIST.FIPS.186-4] 967 National Institute of Standards and Technology (NIST), 968 "Digital Signature Standard (DSS)", NIST NIST FIPS 186-4, 969 DOI 10.6028/NIST.FIPS.186-4, July 2013, 970 . 973 [NIST.FIPS.186-5] 974 National Institute of Standards and Technology (NIST), 975 "FIPS Pub 186-5 (Draft): Digital Signature Standard 976 (DSS)", October 2019, 977 . 980 [NIST.FIPS.197] 981 National Institute of Standards and Technology (NIST), 982 "Advanced encryption standard (AES)", NIST NIST FIPS 197, 983 DOI 10.6028/NIST.FIPS.197, November 2001, 984 . 987 [NIST.FIPS.198-1] 988 National Institute of Standards and Technology (NIST), 989 "The Keyed-Hash Message Authentication Code (HMAC)", 990 NIST NIST FIPS 198-1, DOI 10.6028/NIST.FIPS.198-1, July 991 2008, . 994 [NIST.FIPS.202] 995 Dworkin, Morris J., "SHA-3 Standard: Permutation-Based 996 Hash and Extendable-Output Functions", NIST NIST FIPS 202, 997 DOI 10.6028/NIST.FIPS.202, July 2015, 998 . 1001 [NIST.SP.800-185] 1002 Kelsey, John., Change, Shu-jen., and Ray. Perlner, "SHA-3 1003 derived functions: cSHAKE, KMAC, TupleHash and 1004 ParallelHash", NIST NIST SP 800-185, 1005 DOI 10.6028/NIST.SP.800-185, December 2016, 1006 . 1009 [NIST.SP.800-38d] 1010 Dworkin, M J., "Recommendation for block cipher modes of 1011 operation :GaloisCounter Mode (GCM) and GMAC", NIST NIST 1012 SP 800-38d, DOI 10.6028/NIST.SP.800-38d, 2007, 1013 . 1016 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1017 Hashing for Message Authentication", RFC 2104, 1018 DOI 10.17487/RFC2104, February 1997, 1019 . 1021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1022 Requirement Levels", BCP 14, RFC 2119, 1023 DOI 10.17487/RFC2119, March 1997, 1024 . 1026 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1027 RFC 2631, DOI 10.17487/RFC2631, June 1999, 1028 . 1030 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1031 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 1032 . 1034 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1035 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 1036 September 2002, . 1038 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport 1039 Algorithm in Cryptographic Message Syntax (CMS)", 1040 RFC 3560, DOI 10.17487/RFC3560, July 2003, 1041 . 1043 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1044 Encryption Algorithm in Cryptographic Message Syntax 1045 (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, 1046 . 1048 [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in 1049 Cryptographic Message Syntax (CMS)", RFC 4056, 1050 DOI 10.17487/RFC4056, June 2005, 1051 . 1053 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1054 "Internet X.509 Public Key Infrastructure Certificate 1055 Management Protocol (CMP)", RFC 4210, 1056 DOI 10.17487/RFC4210, September 2005, 1057 . 1059 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1060 Certificate Request Message Format (CRMF)", RFC 4211, 1061 DOI 10.17487/RFC4211, September 2005, 1062 . 1064 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 1065 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 1066 RFC 4231, DOI 10.17487/RFC4231, December 2005, 1067 . 1069 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1070 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1071 . 1073 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 1074 Cryptography (ECC) Algorithms in Cryptographic Message 1075 Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 1076 2010, . 1078 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 1079 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 1080 2010, . 1082 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1083 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1084 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1085 . 1087 [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: 1088 Password-Based Cryptography Specification Version 2.1", 1089 RFC 8018, DOI 10.17487/RFC8018, January 2017, 1090 . 1092 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1093 Signature Algorithm (EdDSA)", RFC 8032, 1094 DOI 10.17487/RFC8032, January 2017, 1095 . 1097 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1098 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1099 May 2017, . 1101 [RFC8418] Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key 1102 Agreement Algorithm with X25519 and X448 in the 1103 Cryptographic Message Syntax (CMS)", RFC 8418, 1104 DOI 10.17487/RFC8418, August 2018, 1105 . 1107 [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature 1108 Algorithm (EdDSA) Signatures in the Cryptographic Message 1109 Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 1110 2018, . 1112 [RFC8702] Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash 1113 Functions in the Cryptographic Message Syntax (CMS)", 1114 RFC 8702, DOI 10.17487/RFC8702, January 2020, 1115 . 1117 12. Informative References 1119 [ECRYPT.CSA.D5.4] 1120 University of Bristol, "Algorithms, Key Size and Protocols 1121 Report (2018)", March 2015, 1122 . 1125 [I-D.ietf-lamps-lightweight-cmp-profile] 1126 Brockhaus, H., Fries, S., and D. V. Oheimb, "Lightweight 1127 Certificate Management Protocol (CMP) Profile", Work in 1128 Progress, Internet-Draft, draft-ietf-lamps-lightweight- 1129 cmp-profile-05, 22 February 2021, 1130 . 1133 [NIST.SP.800-57pt1r5] 1134 Barker, Elaine., "Recommendation for key management:part 1 1135 - general", NIST NIST SP 800-57pt1r5, 1136 DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, 1137 . 1140 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1141 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1142 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 1143 April 2019, . 1145 [RFC8692] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key 1146 Infrastructure: Additional Algorithm Identifiers for 1147 RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, 1148 DOI 10.17487/RFC8692, December 2019, 1149 . 1151 Appendix A. History of changes 1153 Note: This appendix will be deleted in the final version of the 1154 document. 1156 From version 03 -> 04: 1158 * Added John Gray to the list of authors due to his extensive 1159 support and valuable feedback 1161 * Added some clarification of the use AES-GMAC to Section 6.2.1 1162 * Extended the guidance on how to select a set of algorithms in 1163 Section 7 and deleted former Section 7.1 1164 * Deleted the algorithms mandatory to support in Section 7.2 as 1165 discussed at IETF 110 1166 * Extended the Security considerations in Section 9 1167 * Minor changes in wording 1169 From version 02 -> 03: 1171 * Moved former Appendix A to new Section 7 as suggested by Rich and 1172 Russ (see thread "I-D Action: draft-ietf-lamps-cmp-algorithms- 1173 02.txt") 1174 * Added a column to Table 1 in Section 7.2 to reflect the changes to 1175 RFC 4210 1176 * Updated Table 2 in Section 7.3 1177 * Added a paragraph to Section 9 to discuss backward compatibility 1178 with RFC 4210 1179 * Minor changes in wording 1181 From version 01 -> 02: 1183 * Added Hans Aschauer, Mike Ounsworth, and Serge Mister as co-author 1184 * Changed to XML V3 1185 * Added SHAKE digest algorithm to Section 2 as discussed at IETF 109 1186 * Deleted DSA from Section 3 as discussed at IETF 109 1187 * Added RSASSA-PSS with SHAKE to Section 3 1188 * Added SECP curves the section on ECDSA with SHA2, ECDSA with 1189 SHAKE, and EdDSA to Section 3 as discussed at IETF 109 1190 * Deleted static-static D-H and ECDH from Section 4.1 based on the 1191 discussion on the mailing list (see thread "[CMP Algorithms] 1192 Section 4.1.1 and 4.1.2 drop static-static (EC)DH key agreement 1193 algorithms for use in CMP") 1194 * Added ECDH OIDs and SECP curves, as well as ECDH with curve25519 1195 and curve448 to Section 4.1 as discussed at IETF 109 1196 * Deleted RSA-OAEP from Section 4.2 first as discussed at IETF 109, 1197 but re-added it after discussion on the mailing list (see thread 1198 "Mail regarding draft-ietf-lamps-cmp-algorithms") 1199 * Added a paragraph to Section 4.3.1 to explain that the algorithms 1200 and key length for content encryption and key wrapping must be 1201 aligned as discussed on the mailing list (see thread "[CMP 1202 Algorithms] Use Key-Wrap with or without padding in Section 4.3 1203 and Section 5") 1204 * Deleted AES-CCM and AES-GMC from and added AES-CBC to Section 5 as 1205 discussed at IETF 109 1207 * Added Section 6.1.2 to offer PBMAC1 as discusses on the mailing 1208 list (see thread "Mail regarding draft-ietf-lamps-crmf-update- 1209 algs-02") and restructured text in Section 6 to be easier to 1210 differentiate between password- and shared-key-based MAC 1211 * Deleted Diffie-Hellmann based MAC from Section 6 as is only 1212 relevant when using enrolling Diffie-Hellmann certificates 1213 * Added AES-GMAC and SHAKE-based KMAC to Section 6 as discussed at 1214 IETF 109 1215 * Extended Section 9 to mention Russ supporting with two additional 1216 I-Ds and name further supporters of the draft 1217 * Added a first draft of a generic algorithm selection guideline to 1218 Appendix A 1219 * Added a first proposal for mandatory algorithms for the 1220 Lightweight CMP Profile to Appendix A 1221 * Minor changes in wording 1223 From version 00 -> 01: 1225 * Changed sections Symmetric Key-Encryption Algorithms and Content 1226 Encryption Algorithms based on the discussion on the mailing list 1227 (see thread "[CMP Algorithms] Use Key-Wrap with or without padding 1228 in Section 4.3 and Section 5") 1229 * Added Appendix A with updated algorithms profile for RDC4210 1230 Appendix D.2 and first proposal for the Lightweight CMP Profile 1231 * Minor changes in wording 1233 Authors' Addresses 1235 Hendrik Brockhaus (editor) 1236 Siemens AG 1238 Email: hendrik.brockhaus@siemens.com 1240 Hans Aschauer 1241 Siemens AG 1243 Email: hans.aschauer@siemens.com 1245 Mike Ounsworth 1246 Entrust 1248 Email: mike.ounsworth@entrust.com 1249 John Gray 1250 Entrust 1252 Email: john.gray@entrust.com