--- 1/draft-ietf-lamps-cmp-algorithms-06.txt 2021-08-22 09:13:17.110058898 -0700 +++ 2/draft-ietf-lamps-cmp-algorithms-07.txt 2021-08-22 09:13:17.166060302 -0700 @@ -1,21 +1,21 @@ LAMPS Working Group H. Brockhaus, Ed. Internet-Draft H. Aschauer Updates: 4210 (if approved) Siemens Intended status: Standards Track M. Ounsworth -Expires: 1 January 2022 J. Gray +Expires: 23 February 2022 J. Gray Entrust - 30 June 2021 + 22 August 2021 Certificate Management Protocol (CMP) Algorithms - draft-ietf-lamps-cmp-algorithms-06 + draft-ietf-lamps-cmp-algorithms-07 Abstract This document describes the conventions for using concrete cryptographic algorithms with the Certificate Management Protocol (CMP). CMP is used to enroll and further manage the lifecycle of X.509 certificates. Status of This Memo @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 1 January 2022. + This Internet-Draft will expire on 23 February 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -81,22 +81,22 @@ 6.2.3. SHAKE-based KMAC . . . . . . . . . . . . . . . . . . 16 7. Algorithm Use Profiles . . . . . . . . . . . . . . . . . . . 16 7.1. Algorithm Profile for RFC 4210 PKI Management Message Profiles . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2. Algorithm Profile for Lightweight CMP Profile . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 11. Normative References . . . . . . . . . . . . . . . . . . . . 22 12. Informative References . . . . . . . . . . . . . . . . . . . 26 - Appendix A. History of changes . . . . . . . . . . . . . . . . . 26 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 + Appendix A. History of changes . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119] [RFC8174]when, and only when, they appear in all capitals, as shown here. @@ -113,22 +113,22 @@ the digestAlgorithm field of SignerInfo. Digest values are located in the hashVal field of OOBCertHash, the witness field of Challenge, and the certHash field of CertStatus. In addition, digest values are input to signature algorithms. Note: Specific conventions are needed for CertStatus content in certConf messages when confirming certificates where the AlgorithmIdentifier of the certificate signature does not clearly imply a specific hash algorithm. In such cases the hash algorithm to - use to build certHash should be specified, e.g., as done - inSection 2.1andSection 2.2for certificates signed using EdDSA. + use to build certHash should be specified, e.g., as done in + Section 2.1 and Section 2.2 for certificates signed using EdDSA. 2.1. SHA2 The SHA2 algorithm family is defined inFIPS Pub 180-4 [NIST.FIPS.180-4]. The message digest algorithms SHA-224, SHA-256, SHA-384, and SHA-512 are identified by the following OIDs: id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) @@ -151,23 +151,23 @@ messages MUST be SHA512 if the certificate to be confirmed has been signed using EdDSA with Ed25519. 2.2. SHAKE The SHA-3 family of hash functions is defined inFIPS Pub 202 [NIST.FIPS.202]and includes fixed output length variants SHA3-224, SHA3-256, SHA3-384, and SHA3-512, as well as extendable-output functions (SHAKEs) SHAKE128 and SHAKE256. Currently SHAKE128 and SHAKE256 are the only members of the SHA3-family which are specified - for use in X.509 and PKIX[RFC8692], and CMS[RFC8702]. Therefore, CMP - specifies them as defined inRFC 8702 [RFC8702], which are identified - by the following OIDs: + for use in X.509 and PKIX [RFC8692], and CMS [RFC8702]. Therefore, + CMP specifies them as defined in RFC 8702 [RFC8702], which are + identified by the following OIDs: id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashalgs(2) 11 } id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashalgs(2) 12 } Specific conventions to be considered are specified inRFC 8702 Section 3.1 [RFC8702]. @@ -175,23 +175,23 @@ The hash algorithm used to calculate the certHash in certConf messages MUST be SHAKE256 if the certificate to be confirmed has been signed using EdDSA with Ed448. 3. Signature Algorithms This section provides references to object identifiers and conventions to be employed by CMP implementations that support RSA, ECDSA, or EdDSA signature algorithms. - The signature algorithm is referred to as MSG_SIG_ALG - inSection 7.2,RFC 4210 Appendix D and E [RFC4210], and in - theLightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. + The signature algorithm is referred to as MSG_SIG_ALG in + Section 7.2,RFC 4210 Appendix D and E [RFC4210], and in the + Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. Signature algorithm identifiers are located in the protectionAlg field of PKIHeader, the algorithmIdentifier field of POPOSigningKey, signatureAlgorithm field of CertificationRequest, SignKeyPairTypes, and the SignerInfo signatureAlgorithm field of SignedData. Signature values are located in the protection field of PKIMessage, signature field of POPOSigningKey, signature field of CertificationRequest, and SignerInfo signature field of SignedData. @@ -307,66 +307,66 @@ Note: The hash algorithm used to calculate the certHash in certConf messages MUST be SHA512 if the certificate to be confirmed has been signed using Ed25519, seeSection 2.1, and SHAKE256 if signed using Ed448, seeSection 2.2. 4. Key Management Algorithms CMP utilizes the following general key management techniques: key agreement, key transport, and passwords. - CRMF [RFC4211]andCMP Updates [I-D.ietf-lamps-cmp-updates]promotes the - use ofCMS [RFC5652]EnvelopedData by deprecating the use of + CRMF [RFC4211] and CMP Updates [I-D.ietf-lamps-cmp-updates] promotes + the use of CMS [RFC5652] EnvelopedData by deprecating the use of EncryptedValue. 4.1. Key Agreement Algorithms - The key agreement algorithm is referred to as PROT_ENC_ALG inRFC 4210 - Appendix D and E [RFC4210]and as KM_KA_ALG in theLightweight CMP - Profile [I-D.ietf-lamps-lightweight-cmp-profile], as well as - inSection 7. + The key agreement algorithm is referred to as PROT_ENC_ALG in + RFC 4210 Appendix D and E [RFC4210] and as KM_KA_ALG in the + Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as + well as in Section 7. Key agreement algorithms are only used in CMP when usingCMS - [RFC5652]EnvelopedData together with the key agreement key management - technique. When a key agreement algorithm is used, a key-encryption - algorithm (Section 4.3) is needed next to the content-encryption - algorithm (Section 5). + [RFC5652] EnvelopedData together with the key agreement key + management technique. When a key agreement algorithm is used, a key- + encryption algorithm (Section 4.3) is needed next to the content- + encryption algorithm (Section 5). Key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. Key encryption algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field. Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field. 4.1.1. Diffie-Hellman - Diffie-Hellman key agreement is defined inRFC 2631 [RFC2631]and SHALL - be used in the ephemeral-static as specified inRFC 3370 [RFC3370]. - Static-static variants SHALL NOT be used. + Diffie-Hellman key agreement is defined in RFC 2631 [RFC2631] and + SHALL be used in the ephemeral-static as specified in RFC 3370 + [RFC3370]. Static-static variants SHALL NOT be used. The Diffie-Hellman key agreement algorithm is identified by the following OID: id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } Specific conventions to be considered are specified inRFC 3370 Section 4.1 [RFC3370]. 4.1.2. ECDH - Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined - inRFC 5753 [RFC5753]and SHALL be used in the ephemeral-static variant + Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined in + RFC 5753 [RFC5753] and SHALL be used in the ephemeral-static variant as specified inRFC 5753 [RFC5753]or the 1-Pass ECMQV variant as specified inRFC 5753 [RFC5753]. Static-static variants SHALL NOT be used. The ECDH key agreement algorithm used together with NIST-recommended SECP curves are identified by the following OIDs: dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 11(11) 0 } dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) @@ -419,28 +419,28 @@ id-X25519 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 110 } id-X448 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 111 } Specific conventions to be considered are specified inRFC 8418 [RFC8418]. 4.2. Key Transport Algorithms - The key transport algorithm is also referred to as PROT_ENC_ALG - inRFC 4210 Appendix D and E [RFC4210]and as KM_KL_ALG in - theLightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], - as well as inSection 7. + The key transport algorithm is also referred to as PROT_ENC_ALG in + RFC 4210 Appendix D and E [RFC4210] and as KM_KL_ALG in the + Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as + well as in Section 7. Key transport algorithms are only used in CMP when usingCMS - [RFC5652]EnvelopedData together with the key transport key management - technique. + [RFC5652] EnvelopedData together with the key transport key + management technique. Key transport algorithm identifiers are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field. Key transport encrypted content-encryption keys are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey field. 4.2.1. RSA @@ -478,74 +478,76 @@ keyEncryptionAlgorithm fields. Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey and EnvelopedData RecipientInfos PasswordRecipientInfo encryptedKey fields. 4.3.1. AES Key Wrap The AES encryption algorithm is defined inFIPS Pub 197 - [NIST.FIPS.197]and the key wrapping is defined inRFC 3394 [RFC3394]. + [NIST.FIPS.197] and the key wrapping is defined in RFC 3394 + [RFC3394]. AES key encryption has the algorithm identifier: id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 5 } id-aes192-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 25 } id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 45 } The underlying encryption functions for the key wrap and content- encryption algorithms (as specified in Section 5) and the key sizes for the two algorithms MUST be the same (e.g., AES-128 key wrap - algorithm with AES-128 content-encryption algorithm), see - alsoRFC 8551 [RFC8551]. + algorithm with AES-128 content-encryption algorithm), see also + RFC 8551 [RFC8551]. Further conventions to be considered for AES key wrap are specified - inRFC 3394 Section 2.2 [RFC3394]andRFC 3565 Section 2.3.2 [RFC3565]. + in RFC 3394 Section 2.2 [RFC3394] and RFC 3565 Section 2.3.2 + [RFC3565]. 4.4. Key Derivation Algorithms - The key derivation algorithm is also referred to as KM_KD_ALG - inSection 7.2and in theLightweight CMP Profile + The key derivation algorithm is also referred to as KM_KD_ALG in + Section 7.2 and in the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. Key derivation algorithms are only used in CMP when usingCMS [RFC5652]EnvelopedData together with password-based key management technique. Key derivation algorithm identifiers are located in the EnvelopedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm field. When using the password-based key management technique with EnvelopedData as specified in CMP Updates together with MAC-based PKIProtection, the salt for the password-based MAC and KDF must be chosen independently to ensure usage of independent symmetric keys. 4.4.1. PBKDF2 - The password-based key derivation function 2 (PBKDF2) is defined - inRFC 8018 [RFC8018]. + The password-based key derivation function 2 (PBKDF2) is defined in + RFC 8018 [RFC8018]. Password-based key derivation function 2 has the algorithm identifier: id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) 12 } - Further conventions to be considered for PBKDF2 are specified - inRFC 3370 Section 4.4.1 [RFC3370]andRFC 8018 Section 5.2 [RFC8018]. + Further conventions to be considered for PBKDF2 are specified in + RFC 3370 Section 4.4.1 [RFC3370] and RFC 8018 Section 5.2 [RFC8018]. 5. Content Encryption Algorithms The content encryption algorithm is also referred to as PROT_SYM_ALG inSection 7,RFC 4210 Appendix D and E [RFC4210], and theLightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. Content encryption algorithms are only used in CMP when using CMS [RFC5652] EnvelopedData to transport a signed private key package in case of central key generation or key archiving, a certificate to @@ -578,22 +580,22 @@ Specific conventions to be considered for AES-CBC content encryption are specified inRFC 3565 [RFC3565]. 6. Message Authentication Code Algorithms The message authentication code is either used for shared secret- based CMP message protection or together with the password-based key derivation function (PBKDF2). The message authentication code algorithm is also referred to as - MSG_MAC_ALG inSection 7,RFC 4210 Appendix D and E [RFC4210], and - theLightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. + MSG_MAC_ALG in Section 7,RFC 4210 Appendix D and E [RFC4210], and the + Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 6.1. Password-based MAC Password-based MAC algorithms combine the derivation of a symmetric key from a password or other shared secret information and a symmetric key-based MAC function as specified in Section 6.2 using this derived key. Message authentication code algorithm identifiers are located in the protectionAlg field of PKIHeader. @@ -624,110 +626,110 @@ The Password-Based Message Authentication Code 1 (PBMAC1) is defined inRFC 8018 [RFC8018]. PBMAC1 combines a password-based key derivation function like PBKDF2 (Section 4.4.1) with an underlying symmetric key-based message authentication scheme. PBMAC1 has the following OID: id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) 14 } - Specific conventions to be considered for PBMAC1 are specified - inRFC 8018 Section 7.1 and A.5 [RFC8018]. + Specific conventions to be considered for PBMAC1 are specified in + RFC 8018 Section 7.1 and A.5 [RFC8018]. 6.2. Symmetric key-based MAC Symmetric key-based MAC algorithms are used for deriving the - symmetric encryption key when using PBKDF2 as described - inSection 4.4.1as well as with Password-based MAC as described - inSection 6.1. + symmetric encryption key when using PBKDF2 as described in + Section 4.4.1 as well as with Password-based MAC as described in + Section 6.1. Message authentication code algorithm identifiers are located in the protectionAlg field of PKIHeader, the mac field of PBMParameter, the messageAuthScheme field of PBMAC1, and the prf field of PBKDF2-params. Message authentication code values are located in the PKIProtection field. 6.2.1. SHA2-based HMAC - The HMAC algorithm is defined inRFC 2104 [RFC2104]andFIPS Pub 198-1 - [NIST.FIPS.198-1]. + The HMAC algorithm is defined in RFC 2104 [RFC2104] and + FIPS Pub 198-1 [NIST.FIPS.198-1]. The HMAC algorithm used with SHA2 message digest algorithms is identified by the following OIDs: id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 8 } id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 9 } id-hmacWithSHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 10 } id-hmacWithSHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 11 } Specific conventions to be considered for SHA2-based HMAC are specified inRFC 4231 Section 3.1 [RFC4231]. 6.2.2. AES-GMAC - The AES-GMAC algorithm is defined inFIPS Pub 197 - [NIST.FIPS.197]andNIST SP 800-38d [NIST.SP.800-38d]. + The AES-GMAC algorithm is defined in FIPS Pub 197 [NIST.FIPS.197] and + NIST SP 800-38d [NIST.SP.800-38d]. NOTE: AES-GMAC MUST NOT be used twice with the same parameter set, especially the same nonce. Therefore, it MUST NOT be used together with PBKDF2. When using it with PBMAC1 it MUST be ensured that AES- GMAC is only used as message authentication scheme and not for the key derivation function PBKDF2. The AES-GMAC algorithm is identified by the following OIDs: id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 9 } id-aes192-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 29 } id-aes256-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 49 } - Specific conventions to be considered for AES-GMAC are specified - inRFC 9044 [RFC9044]. + Specific conventions to be considered for AES-GMAC are specified in + RFC 9044 [RFC9044]. 6.2.3. SHAKE-based KMAC - The KMAC algorithm is defined inRFC 8702 [RFC8702]andFIPS SP 800-185 - [NIST.SP.800-185]. + The KMAC algorithm is defined in RFC 8702 [RFC8702] and + FIPS SP 800-185 [NIST.SP.800-185]. The SHAKE-based KMAC algorithm is identified by the following OIDs: id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 19 } id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 20 } Specific conventions to be considered for KMAC with SHAKE are specified inRFC 8702 Section 3.4 [RFC8702]. 7. Algorithm Use Profiles This section provides profiles of algorithms and respective conventions for different application use cases. Recommendations likeNIST SP 800-57 Recommendation for Key Management [NIST.SP.800-57pt1r5]andECRYPT Algorithms, Key Size and Protocols - Report (2018) [ECRYPT.CSA.D5.4]provide general information on current - cryptographic algorithms. + Report (2018) [ECRYPT.CSA.D5.4] provide general information on + current cryptographic algorithms. The following criteria will help implementers choose appropriate algorithms for managing certificates: * The cryptographic strength of the algorithm with the lowest security. Note: To avoid consuming too much computational resources it is recommended to choose a set of algorithms offering roughly the same level of security. @@ -797,28 +799,28 @@ | |this type is | | | | |encrypted using| | | | |PROT_ENC_ALG) | | | +------------+---------------+------------------+-------------------+ Table 1 Mandatory Algorithm Identifiers and Specifications: RSA: sha256WithRSAEncryption with 2048 bit, seeSection 3.1 - PasswordBasedMac: id-PasswordBasedMac, seeSection 6.1(with id-sha256 - as the owf parameter, seeSection 2.1and id-hmacWithSHA256 as the mac - parameter, seeSection 6.2.1) + PasswordBasedMac: id-PasswordBasedMac, see Section 6.1 (with id- + sha256 as the owf parameter, see Section 2.1 and id-hmacWithSHA256 as + the mac parameter, see Section 6.2.1) PBMAC1: id-PBMAC1, seeSection 6.1.2(with id-PBKDF2 as the key - derivation function, seeSection 4.4.1and id-hmacWithSHA256 as message - authentication scheme, seeSection 6.2.1). It is RECOMMENDED to - prefer the usage of PBMAC1 instead of PasswordBasedMac. + derivation function, see Section 4.4.1 and id-hmacWithSHA256 as + message authentication scheme, see Section 6.2.1). It is RECOMMENDED + to prefer the usage of PBMAC1 instead of PasswordBasedMac. D-H: id-alg-ESDH, seeSection 4.1.1 AES-wrap: id-aes256-wrap, seeSection 4.3.1 AES-CBC: id-aes256-CBC, seeSection 5.1 7.2. Algorithm Profile for Lightweight CMP Profile The following table contains definitions of algorithms which MAY be @@ -896,75 +898,75 @@ cryptographic algorithms weaken over time, some of them should not be used anymore. In general, new attacks are emerging due to research cryptoanalysis or increase in computing power. New algorithms were introduced that are more resistant to today's attacks. This document lists many cryptographic algorithms usable with CMP to offer implementers a more up to date choice. Finally, the algorithms to be supported also heavily depend on the certificates and PKI management operations utilized in the target environment. The algorithm with the lowest security strength and the entropy of shared - secret information define the security of the overall solution, - seeSection 7. + secret information define the security of the overall solution, see + Section 7. When using MAC-based message protection the use of PBMAC1 is preferable to that of PasswordBasedMac: first, PBMAC1 is a well-known scrutinized algorithm, which is not true for PasswordBasedMac and second, there exists a theoretical weakness in PasswordBasedMac, where the generated MAC key can be easily distinguished from a random key. AES-GMAC MUST NOT be used as the pseudo random function in PBKDF2; the use of AES-GMAC more than once with the same key and the same nonce will break the security. - InSection 7of this document there is also an update to - theAppendix D.2 of RFC 4210 [RFC4210]and a set of algorithms that MAY + In Section 7 of this document there is also an update to the + Appendix D.2 of RFC 4210 [RFC4210] and a set of algorithms that MAY be supported when implementing theLightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. To keep the list of algorithms to be used with CMP up to date and to enlist secure algorithms resisting known attack scenarios, future algorithms should be added and weakened algorithms should be deprecated. It is recognized that there may be older CMP implementations in use that conform to the algorithm use profile fromAppendix D.2 of RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for PROT_SYM_ALG but inRFC 4210 [RFC4210]3-DES was mandatory. In most cases the newer mandatory algorithms were listed as "other" - algorithms inRFC 4210 [RFC4210]. Therefore, it is expected that many - CMP systems may already support the recommended algorithms in this - specification. In such systems the weakened algorithms should be - disabled from further use. If critical systems cannot be immediately - updated to conform to the recommended algorithm use profile, it is - recommended a plan to migrate the infrastructure to conforming - profiles be adopted as soon as possible. + algorithms in RFC 4210 [RFC4210]. Therefore, it is expected that + many CMP systems may already support the recommended algorithms in + this specification. In such systems the weakened algorithms should + be disabled from further use. If critical systems cannot be + immediately updated to conform to the recommended algorithm use + profile, it is recommended a plan to migrate the infrastructure to + conforming profiles be adopted as soon as possible. 10. Acknowledgements - Thanks to Russ Housley for supporting this draft with - submitting[RFC9044]and[RFC9045]. + Thanks to Russ Housley for supporting this draft with submitting + [RFC9044] and [RFC9045]. May thanks also to all reviewers like Serge Mister, Mark Ferreira, Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steffen Fries for their input and feedback to this document. Apologies to all not mentioned reviewers and supporters. 11. Normative References [I-D.ietf-lamps-cmp-updates] Brockhaus, H. and D. V. Oheimb, "Certificate Management Protocol (CMP) Updates", Work in Progress, Internet-Draft, - draft-ietf-lamps-cmp-updates-10, 4 May 2021, + draft-ietf-lamps-cmp-updates-12, 9 July 2021, . + cmp-updates-12>. [NIST.FIPS.180-4] Dang, Quynh H., "Secure Hash Standard", NIST NIST FIPS 180-4, DOI 10.6028/NIST.FIPS.180-4, July 2015, . [NIST.FIPS.186-4] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", NIST NIST FIPS 186-4, @@ -1061,20 +1063,25 @@ [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, . [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, DOI 10.17487/RFC4231, December 2005, . + [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, + "Elliptic Curve Cryptography Subject Public Key + Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, + . + [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 2010, . [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic @@ -1132,23 +1139,23 @@ [ECRYPT.CSA.D5.4] University of Bristol, "Algorithms, Key Size and Protocols Report (2018)", March 2015, . [I-D.ietf-lamps-lightweight-cmp-profile] Brockhaus, H., Fries, S., and D. V. Oheimb, "Lightweight Certificate Management Protocol (CMP) Profile", Work in Progress, Internet-Draft, draft-ietf-lamps-lightweight- - cmp-profile-05, 22 February 2021, + cmp-profile-06, 9 July 2021, . + lightweight-cmp-profile-06>. [NIST.SP.800-57pt1r5] Barker, Elaine., "Recommendation for key management:part 1 - general", NIST NIST SP 800-57pt1r5, DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, . [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 @@ -1159,20 +1166,24 @@ Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, DOI 10.17487/RFC8692, December 2019, . Appendix A. History of changes Note: This appendix will be deleted in the final version of the document. + From version 06 -> 07: + + * Fixing minor formatting nits + From version 05 -> 06: * Added text to Section 2 and Section 3.3 to clearly specify the hash algorithm to use for certConf messages for certificates signed with EdDSA (see thread "[CMP Updates] Hash algorithm to us for calculating certHash") * Updated new RFC numbers for I-D.ietf-lamps-cms-aes-gmac-alg and I- D.ietf-lamps-crmf-update-algs From version 04 -> 05: