Siemens AG

Werner-von-Siemens-Strasse 1 80333 Munich Germany hendrik.brockhaus@siemens.com https://www.siemens.com

Siemens AG

Werner-von-Siemens-Strasse 1 80333 Munich Germany hans.aschauer@siemens.com https://www.siemens.com

Entrust

1187 Park Place MN 55379 Minneapolis United States of America mike.ounsworth@entrust.com https://www.entrust.com

Entrust

1187 Park Place MN 55379 Minneapolis United States of America john.gray@entrust.com https://www.entrust.com

sec lamps CMP This document describes the conventions for using several cryptographic algorithms with the Certificate Management Protocol (CMP). CMP is used to enroll and further manage the lifecycle of X.509 certificates. This document also updates the algorithm use profile from Appendix D.2 of RFC 4210.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2023 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 () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
  • .  Terminology
• .  Message Digest Algorithms
  • .  SHA2
  • .  SHAKE
• .  Signature Algorithms
  • .  RSA
  • .  ECDSA
  • .  EdDSA
• .  Key Management Algorithms
  • .  Key Agreement Algorithms
    • .  Diffie-Hellman
    • .  ECDH
  • .  Key Transport Algorithms
    • .  RSA
  • .  Symmetric Key-Encryption Algorithms
    • .  AES Key Wrap
  • .  Key Derivation Algorithms
    • .  PBKDF2
• .  Content-Encryption Algorithms
  • .  AES-CBC
• .  Message Authentication Code Algorithms
  • .  Password-Based MAC
    • .  PasswordBasedMac
    • .  PBMAC1
  • .  Symmetric Key-Based MAC
    • .  SHA2-Based HMAC
    • .  AES-GMAC
    • .  SHAKE-Based KMAC
• .  Algorithm Use Profiles
  • .  Algorithm Profile for PKI Management Message Profiles in RFC 4210
  • .  Algorithm Profile for Lightweight CMP Profile
• .  IANA Considerations
• .  Security Considerations
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

Introduction contains a set of algorithms that is mandatory to be supported by implementations conforming to . These algorithms were appropriate at the time CMP was released, but as cryptographic algorithms weaken over time, some of them should no longer be used. In general, new attacks are emerging due to research in cryptanalysis or an increase in computing power. New algorithms were introduced that are more resistant to today's attacks. This document lists current cryptographic algorithms that can be used with CMP to offer an easier way to maintain the list of suitable algorithms over time.

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 when, and only when, they appear in all capitals, as shown here. In the following sections, ASN.1 values and types are used to indicate where algorithm identifier and output values are provided. These ASN.1 values and types are defined in CMP, Certificate Request Message Format (CRMF), CMP Updates, and Cryptographic Message Syntax (CMS).

Message Digest Algorithms This section provides references to object identifiers and conventions to be employed by CMP implementations that support SHA2 or SHAKE message digest algorithms. Digest algorithm identifiers are located in the:

• hashAlg field of OOBCertHash and CertStatus,
• owf field of Challenge, PBMParameter, and DHBMParameter,
• digestAlgorithms field of SignedData, and
• digestAlgorithm field of SignerInfo.

Digest values are located in the:

• hashVal field of OOBCertHash,
• certHash field of CertStatus, and
• witness field of Challenge.

In addition, digest values are input to signature algorithms.

SHA2 The SHA2 algorithm family is defined in FIPS Pub 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) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 } id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 } id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 } id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3 } Specific conventions to be considered are specified in .

SHAKE The SHA-3 family of hash functions is defined in FIPS Pub 202 and consists of the fixed output length variants SHA3-224, SHA3-256, SHA3-384, and SHA3-512, as well as the extendable-output functions (XOFs) SHAKE128 and SHAKE256. Currently, SHAKE128 and SHAKE256 are the only members of the SHA3-family that are specified for use in X.509 certificates and CMS as one-way hash functions for use with RSASSA-PSS and ECDSA. SHAKE is an extendable-output function, and FIPS Pub 202 prohibits using SHAKE as a general-purpose hash function. When SHAKE is used in CMP as a message digest algorithm, the output length MUST be 256 bits for SHAKE128 and 512 bits for SHAKE256. The message digest algorithms SHAKE128 and SHAKE256 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 in .

Signature Algorithms This section provides references to object identifiers and conventions to be employed by CMP implementations that support signature algorithms like RSA, ECDSA, or EdDSA. The signature algorithm is referred to as MSG_SIG_ALG in Appendices and of , in the Lightweight CMP Profile, and in . Signature algorithm identifiers are located in the:

• protectionAlg field of PKIHeader,
• algorithmIdentifier field of POPOSigningKey, and
• signatureAlgorithm field of CertificationRequest, SignKeyPairTypes, and SignerInfo

Signature values are located in the:

• protection field of PKIMessage,
• signature field of POPOSigningKey, and
• signature field of CertificationRequest and SignerInfo.

RSA The RSA (RSASSA-PSS and PKCS #1 version 1.5) signature algorithm is defined in . The algorithm identifier for RSASAA-PSS signatures used with SHA2 message digest algorithms is identified by the following OID: id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 } Specific conventions to be considered are specified in . The signature algorithm RSASSA-PSS used with SHAKE message digest algorithms is identified by the following OIDs: id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 30 } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 31 } Specific conventions to be considered are specified in . The signature algorithm PKCS #1 version 1.5 used with SHA2 message digest algorithms is identified by the following OIDs: sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } Specific conventions to be considered are specified in .

ECDSA The ECDSA signature algorithm is defined in FIPS Pub 186-5. The signature algorithm ECDSA used with SHA2 message digest algorithms is identified by the following OIDs: ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } As specified in , the NIST-recommended curves are identified by the following OIDs: secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } secp224r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 33 } secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } secp384r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 34 } secp521r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 35 } Specific conventions to be considered are specified in . The signature algorithm ECDSA used with SHAKE message digest algorithms is identified by the following OIDs: id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 32 } id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 33 } Specific conventions to be considered are specified in .

EdDSA The EdDSA signature algorithm is defined in and FIPS Pub 186-5. The signature algorithm Ed25519 that MUST be used with SHA-512 message digest algorithms is identified by the following OIDs: id-Ed25519 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 112 } The signature algorithm Ed448 that MUST be used with SHAKE256 message digest algorithms is identified by the following OIDs: id-Ed448 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 113 } Specific conventions to be considered are specified in . 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 or SHAKE256 with d=512 if the certificate to be confirmed has been signed using Ed448.

Key Management Algorithms CMP utilizes the following general key management techniques: key agreement, key transport, and passwords. CRMF and CMP Updates promote the use of CMS EnvelopedData by deprecating the use of EncryptedValue.

Key Agreement Algorithms The key agreement algorithm is referred to as PROT_ENC_ALG in Appendices and of and as KM_KA_ALG in the Lightweight CMP Profile and . Key agreement algorithms are only used in CMP when using CMS EnvelopedData together with the key agreement key management technique. When a key agreement algorithm is used, a key-encryption algorithm () is needed next to the content-encryption algorithm (). Key agreement algorithm identifiers are located in the:

• keyEncryptionAlgorithm field of KeyAgreeRecipientInfo.

Key wrap algorithm identifiers are located in the:

• KeyWrapAlgorithm parameters within keyEncryptionAlgorithm field of KeyAgreeRecipientInfo.

Wrapped content-encryption keys are located in the:

• encryptedKey field of RecipientEncryptedKeys.

Diffie-Hellman The Diffie-Hellman (DH) key agreement is defined in and SHALL be used in the ephemeral-static variants, as specified in . Static-static variants SHALL NOT be used. The DH 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 in .

ECDH The Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined in and SHALL be used in the ephemeral-static variant, as specified in , or the 1-Pass Elliptic Curve Menezes-Qu-Vanstone (ECMQV) variant, as specified in . 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) identified-organization(3) certicom(132) schemes(1) 11(11) 1 } dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 11(11) 2 } dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 11(11) 3 } dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 14(14) 0 } dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 14(14) 1 } dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 14(14) 2 } dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 14(14) 3 } mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 15(15) 0 } mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 15(15) 1 } mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 15(15) 2 } mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 15(15) 3 } As specified in , the NIST-recommended SECP curves are identified by the following OIDs: secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } secp224r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 33 } secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } secp384r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 34 } secp521r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 35 } Specific conventions to be considered are specified in . The ECDH key agreement algorithm used together with curve25519 or curve448 is identified by the following OIDs: 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 in .

Key Transport Algorithms The key transport algorithm is also referred to as PROT_ENC_ALG in Appendices and of and as KM_KT_ALG in the Lightweight CMP Profile and . Key transport algorithms are only used in CMP when using CMS EnvelopedData together with the key transport key management technique. Key transport algorithm identifiers are located in the:

• keyEncryptionAlgorithm field of KeyTransRecipientInfo.

Key transport encrypted content-encryption keys are located in the:

• encryptedKey field of KeyTransRecipientInfo.

RSA The RSA key transport algorithm is the RSA encryption scheme defined in . The algorithm identifier for RSA (PKCS #1 v1.5) is: rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } The algorithm identifier for RSAES-OAEP is: id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } Further conventions to be considered for PKCS #1 v1.5 are specified in and for RSAES-OAEP in .

Symmetric Key-Encryption Algorithms The symmetric key-encryption algorithm is also referred to as KM_KW_ALG in and the Lightweight CMP Profile. As the symmetric key-encryption key management technique is not used by CMP, the symmetric key-encryption algorithm is only needed when using the key agreement or password-based key management technique with CMS EnvelopedData. Key wrap algorithm identifiers are located in the:

• parameters field of the KeyEncryptionAlgorithmIdentifier of KeyAgreeRecipientInfo and PasswordRecipientInfo.

Wrapped content-encryption keys are located in the:

• encryptedKey field of RecipientEncryptedKeys (for key agreement) and PasswordRecipientInfo (for password-based key management).

AES Key Wrap The AES encryption algorithm is defined in FIPS Pub 197, and the key wrapping is defined in . 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 ) 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 . Further conventions to be considered for AES key wrap are specified in and .

Key Derivation Algorithms The key derivation algorithm is also referred to as KM_KD_ALG in and the Lightweight CMP Profile. Key derivation algorithms are only used in CMP when using CMS EnvelopedData together with the password-based key management technique. Key derivation algorithm identifiers are located in the:

• keyDerivationAlgorithm field of PasswordRecipientInfo.

When using the password-based key management technique with EnvelopedData as specified in CMP Updates together with PKIProtection based on the message authentication code (MAC), the salt for the password-based MAC and key derivation function (KDF) must be chosen independently to ensure usage of independent symmetric keys.

PBKDF2 Password-based key derivation function 2 (PBKDF2) is defined in . PBKDF2 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 in and .

Content-Encryption Algorithms The content-encryption algorithm is also referred to as PROT_SYM_ALG in Appendices and of , in the Lightweight CMP Profile, and in . Content-encryption algorithms are used in CMP when using CMS EnvelopedData to transport a signed private key package in case of central key generation or key archiving, a certificate to facilitate implicit proof-of-possession, or a revocation passphrase in encrypted form. Content-encryption algorithm identifiers are located in the:

• contentEncryptionAlgorithm field of EncryptedContentInfo.

Encrypted content is located in the:

• encryptedContent field of EncryptedContentInfo.

AES-CBC The AES encryption algorithm is defined in FIPS Pub 197. AES Cipher Block Chaining (AES-CBC) content encryption has the algorithm identifier: id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 2 } id-aes192-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1)22 } id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1)42 } Specific conventions to be considered for AES-CBC content encryption are specified in .

Message Authentication Code Algorithms The message authentication code (MAC) is either used for shared secret-based CMP message protection or together with the password-based key derivation function (PBKDF2). The MAC algorithm is also referred to as MSG_MAC_ALG in , Appendices and of , and the Lightweight CMP Profile.

Password-Based MAC Password-based message authentication code (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 , using this derived key. MAC algorithm identifiers are located in the:

• protectionAlg field of PKIHeader.

Message authentication code values are located in the:

• PKIProtection field of PKIMessage.

PasswordBasedMac The PasswordBasedMac algorithm is defined in , , and "Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)". The PasswordBasedMac algorithm is identified by the following OID: id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) nt(113533) nsn(7) algorithms(66) 13 } Further conventions to be considered for PasswordBasedMac are specified in , , and "Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)".

PBMAC1 Password-Based Message Authentication Code 1 (PBMAC1) is defined in . PBMAC1 combines a password-based key derivation function, like PBKDF2 (), 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 in Section and Appendix of .

Symmetric Key-Based MAC Symmetric key-based message authentication code (MAC) algorithms are used for deriving the symmetric encryption key when using PBKDF2, as described in , as well as with password-based MAC, as described in . MAC algorithm identifiers are located in the:

• protectionAlg field of PKIHeader,
• messageAuthScheme field of PBMAC1,
• mac field of PBMParameter, and
• prf field of PBKDF2-params.

MAC values are located in the:

• PKIProtection field of PKIMessage.

SHA2-Based HMAC The HMAC algorithm is defined in and FIPS Pub 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 in .

AES-GMAC The AES-GMAC algorithm is defined in FIPS Pub 197 and NIST SP 800-38d. Note: The 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 the AES-GMAC is only used as a 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 the AES-GMAC are specified in .

SHAKE-Based KMAC The KMAC algorithm is defined in and FIPS 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) hashAlgs(2) 19 } id-KMACWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2) 20 } Specific conventions to be considered for KMAC with SHAKE are specified in .

Algorithm Use Profiles This section provides profiles of algorithms and respective conventions for different application use cases. Recommendations like those described in Table 2 of NIST SP 800-57 "Recommendation for Key Management" and Section 4.6 of ECRYPT "Algorithms, Key Size and Protocols Report (2018)" provide general information on current cryptographic algorithms. The overall cryptographic strength of CMP implementations will depend on several factors, including:

• capabilities of the end entity: What kind of algorithms does the end entity support? The cryptographic strength of the system SHOULD be at least as strong as the algorithms and keys used for the certificate being managed.
• algorithm profile: The overall strength of the profile will be the strength of the weakest algorithm it contains.
• message protection: The overall strength of the CMP message protection.
  • MAC-based protection: The entropy of the shared secret information or password when MAC-based message protection is used (MSG_MAC_ALG).
  • signature-based protection: The strength of the key pair and signature algorithm when signature-based protection is used (MSG_SIG_ALG).
  • protection of centrally generated keys: The strength of the algorithms used for the key management technique (: PROT_ENC_ALG or : KM_KA_ALG, KM_KT_ALG, KM_KD_ALG) and the encryption of the content-encryption key and private key (: SYM_PENC_ALG, PROT_SYM_ALG or : KM_KW_ALG, PROT_SYM_ALG).

The following table shows the algorithms listed in this document sorted by their bits of security. If an implementation intends to enroll and manage certificates for keys of a specific security, it SHALL implement and use algorithms of at least that strength for the respective PKI management operation. If one row does not provide a suitable algorithm, the implementer MUST choose one offering more bits of security. Cryptographic Algorithms Sorted by Their Bits of Security

Bits of Security	RSA or DH	Elliptic Curve Cryptography	Hash Function or XOF with Specified Output Length (d)	Symmetric Encryption
112	RSA2048, DH(2048)	ECDSA/ECDH (secp224r1)	SHA-224
128	RSA3072, DH(3072)	ECDSA/ECDH (secp256r1), Ed25519/X25519 (curve25519)	SHA-256, SHAKE128(d=256)	AES-128
192		ECDSA/ECDH (secp384r1)	SHA-384	AES-192
224		Ed448/X448 (curve448)
256		ECDSA/ECDH (secp521r1)	SHA-512, SHAKE256(d=512)	AES-256

The following table shows the cryptographic algorithms sorted by their usage in CMP and with more details. Cryptographic Algorithms Sorted by Their Bits of Security and Usage by CMP

Bits of Security	Key Types to Be Certified	CMP Protection MSG_SIG_ALG, MSG_MAC_ALG	Key Management Technique PROT_ENC_ALG or KM_KA_ALG, KM_KT_ALG, KM_KD_ALG	Key-Wrap and Symmetric Encryption PROT_SYM_ALG, SYM_PENC_ALG or KM_KW_ALG
112	RSA2048, secp224r1	RSASSA-PSS (2048, SHA-224 or SHAKE128 (d=256)), RSAEncryption (2048, SHA-224), ECDSA (secp224r1, SHA-224 or SHAKE128 (d=256)), PBMAC1 (HMAC-SHA-224)	DH(2048), RSAES-OAEP (2048, SHA-224), RSAEncryption (2048, SHA-224), ECDH (secp224r1, SHA-224), PBKDF2 (HMAC-SHA-224)
128	RSA3072, secp256r1, curve25519	RSASSA-PSS (3072, SHA-256 or SHAKE128 (d=256)), RSAEncryption (3072, SHA-256), ECDSA (secp256r1, SHA-256 or SHAKE128 (d=256)), Ed25519 (SHA-512), PBMAC1 (HMAC-SHA-256)	DH(3072), RSAES-OAEP (3072, SHA-256), RSAEncryption (3072, SHA-256), ECDH (secp256r1, SHA-256), X25519, PBKDF2 (HMAC-SHA-256)	AES-128
192	secp384r1	ECDSA (secp384r1, SHA-384), PBMAC1 (HMAC-SHA-384)	ECDH (secp384r1, SHA-384), PBKDF2 (HMAC-SHA-384)	AES-192
224	curve448	Ed448 (SHAKE256)	X448
256	secp521r1	ECDSA (secp521r1, SHA-512 or SHAKE256 (d=512)), PBMAC1 (HMAC-SHA-512)	ECDH (secp521r1, SHA-512), PBKDF2 (HMAC-SHA-512)	AES-256

To avoid consuming too many computational resources, choosing a set of algorithms offering roughly the same level of security is recommended. Below are several algorithm profiles that are balanced, assuming the implementer chooses MAC secrets and/or certificate profiles of at least equivalent strength.

Algorithm Profile for PKI Management Message Profiles in RFC 4210 The following table updates the definitions of algorithms used within PKI Management Message Profiles, as defined in . The columns in the table are:

Name:

An identifier used for message profiles

Use:

Description of where and for what the algorithm is used

Mandatory:

Algorithms that MUST be supported by conforming implementations

Optional:

Algorithms that are OPTIONAL to support

Deprecated:

Algorithms from that SHOULD NOT be used any more

Algorithms Used within Appendix D.2 of RFC 4210

Name	Use	Mandatory	Optional	Deprecated
MSG_SIG_ALG	protection of PKI messages using signatures	RSA	ECDSA, EdDSA	DSA, combinations with MD5 and SHA-1
MSG_MAC_ALG	protection of PKI messages using MACs	PBMAC1	PasswordBasedMac, HMAC, KMAC	X9.9
SYM_PENC_ALG	symmetric encryption of an end entity's private key where the symmetric key is distributed out of band	AES-wrap		3-DES(3-key-EDE, CBC Mode), RC5, CAST-128
PROT_ENC_ALG	asymmetric algorithm used for encryption of (symmetric keys for encryption of) private keys transported in PKIMessages	DH	ECDH, RSA
PROT_SYM_ALG	symmetric encryption algorithm used for encryption of private key bits (a key of this type is encrypted using PROT_ENC_ALG)	AES-CBC		3-DES(3-key-EDE, CBC Mode), RC5, CAST-128

The following are the mandatory algorithm identifiers and specifications:

RSA:

sha256WithRSAEncryption with 2048 bit, see

PasswordBasedMac:

id-PasswordBasedMac, see (with id-sha256 as the owf parameter, see and id-hmacWithSHA256 as the mac parameter, see )

PBMAC1:

id-PBMAC1, see (with id-PBKDF2 as the key derivation function, see and id-hmacWithSHA256 as the message authentication scheme, see ). It is RECOMMENDED to prefer the usage of PBMAC1 instead of PasswordBasedMac.

DH:

id-alg-ESDH, see

AES-wrap:

id-aes128-wrap, see

AES-CBC:

id-aes128-CBC, see

Algorithm Profile for Lightweight CMP Profile The following table contains definitions of algorithms that MAY be supported by implementations of the Lightweight CMP Profile. As the set of algorithms to be used for implementations of the Lightweight CMP Profile heavily depends on the PKI management operations implemented, the certificates used for message protection, and the certificates to be managed, this document will not specify a specific set that is mandatory to support for conforming implementations. The columns in the table are:

Name:

An identifier used for message profiles

Use:

Description of where and for what the algorithm is used

Examples:

Lists the algorithms, as described in this document. The list of algorithms depends on the set of PKI management operations to be implemented.

Note: It is RECOMMENDED to prefer the usage of PBMAC1 instead of PasswordBasedMac. Algorithms Used within the Lightweight CMP Profile

Name	Use	Examples
MSG_SIG_ALG	protection of PKI messages using signatures and for SignedData, e.g., a private key transported in PKIMessages	RSA, ECDSA, EdDSA
MSG_MAC_ALG	protection of PKI messages using MACing	PasswordBasedMac (see ), PBMAC1, HMAC, KMAC
KM_KA_ALG	asymmetric key agreement algorithm used for agreement of a symmetric key for use with KM_KW_ALG	DH, ECDH
KM_KT_ALG	asymmetric key-encryption algorithm used for transport of a symmetric key for PROT_SYM_ALG	RSA
KM_KD_ALG	symmetric key derivation algorithm used for derivation of a symmetric key for use with KM_KW_ALG	PBKDF2
KM_KW_ALG	algorithm to wrap a symmetric key for PROT_SYM_ALG	AES-wrap
PROT_SYM_ALG	symmetric content-encryption algorithm used for encryption of EnvelopedData, e.g., a private key transported in PKIMessages	AES-CBC

IANA Considerations This document has no IANA actions.

Security Considerations 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 defines the security of the overall solution; see . 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. Second, the PasswordBasedMac algorithm as specified in is essentially PBKDF1 (as defined in ) with an HMAC step at the end. Here, we update to use the PBKDF2-HMAC construct defined as PBMAC1 in . PBKDF2 is superior to PBKDF1 in an improved internal construct for iterated hashing and in removing PBKDF1's limitation of only being able to derive keys up to the size of the underlying hash function. Additionally, PBKDF1 is not recommended for new applications as stated in and is no longer an approved algorithm by most standards bodies. Therefore, it presents difficulties to implementers who are submitting their CMP implementations for certification, hence moving to a PBKDF2-based mechanism. This change is in alignment with , which updates to allow the use of PBMAC1 in CRMF. The AES-GMAC MUST NOT be used as the pseudorandom function (PRF) in PBKDF2; the use of the AES-GMAC more than once with the same key and the same nonce will break the security. In of this document, there is also an update to and a set of algorithms that MAY be supported when implementing the Lightweight CMP Profile. It is recognized that there may be older CMP implementations in use that conform to the algorithm use profile from . For example, the use of AES is now mandatory for PROT_SYM_ALG, while 3-DES was mandatory in . 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 that a plan to migrate the infrastructure to conforming profiles be adopted as soon as possible. Symmetric key-based MAC algorithms as described in MAY be used as MSG_MAC_ALG. The implementer MUST choose a suitable PRF and ensure that the key has sufficient entropy to match the overall security level of the algorithm profile. These considerations are outside the scope of the profile.

References Normative References Information Technology Laboratory National Institute of Standards and Technology

US Gaithersburg

National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) Information Technology Laboratory National Institute of Standards and Technology

US Gaithersburg

Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory National Institute of Standards and Technology

US Gaithersburg

National Institute of Standards and Technology

US Gaithersburg

This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. [STANDARDS-TRACK] This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS). The CMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients. [STANDARDS-TRACK] This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK] This document specifies the conventions for using the RSASSA-PSS (RSA Probabilistic Signature Scheme) digital signature algorithm with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK] This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK] This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK] This document provides test vectors for the HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 message authentication schemes. It also provides ASN.1 object identifiers and Uniform Resource Identifiers (URIs) to identify use of these schemes in protocols. The test vectors provided in this document may be used for conformance testing. [STANDARDS-TRACK] This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document describes how to use Elliptic Curve Cryptography (ECC) public key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180-3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC 4231 for message authentication code standards. This document obsoletes RFC 3278. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK] This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques. This document represents a republication of PKCS #5 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 2898. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the conventions for using the Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS). This document specifies the conventions for using the Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS. This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. Digital signatures are used to sign messages, X.509 certificates, and Certificate Revocation Lists (CRLs). This document updates the "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" (RFC 3279) and describes the conventions for using the SHAKE function family in Internet X.509 certificates and revocation lists as one-way hash functions with the RSA Probabilistic signature and Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithms. The conventions for the associated subject public keys are also described. This document updates the "Cryptographic Message Syntax (CMS) Algorithms" (RFC 3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic Signature Scheme (RSASSA-PSS) and Elliptic Curve Digital Signature Algorithm (ECDSA). The conventions for the associated signer public keys in CMS are also described. This document specifies the conventions for using the AES-GMAC Message Authentication Code algorithm with the Cryptographic Message Syntax (CMS) as specified in RFC 5652. This document updates the cryptographic algorithm requirements for the Password-Based Message Authentication Code in the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) specified in RFC 4211. Informative References University of Bristol Information Technology Laboratory National Institute of Standards and Technology

US Gaithersburg

Acknowledgements Thanks to for his work on and upon which this RFC relies heavily. May thanks also to all reviewers like , , , , , , and for their input and feedback to this document. Apologies to all not mentioned reviewers and supporters.

Authors' Addresses Siemens AG

Werner-von-Siemens-Strasse 1 80333 Munich Germany hendrik.brockhaus@siemens.com https://www.siemens.com

Siemens AG

Werner-von-Siemens-Strasse 1 80333 Munich Germany hans.aschauer@siemens.com https://www.siemens.com

Entrust

1187 Park Place MN 55379 Minneapolis United States of America mike.ounsworth@entrust.com https://www.entrust.com

Entrust

1187 Park Place MN 55379 Minneapolis United States of America john.gray@entrust.com https://www.entrust.com