RFC 9481

Certificate Management Protocol (CMP) Algorithms

📅 published November 2023, from ietf

RFC 9481: Certificate Management Protocol (CMP) Algorithms ✨

okay bestie, this one is a whole vibe. 🎀 It's RFC 9481, titled Certificate Management Protocol (CMP) Algorithms, and it's a Standards Track document from the IETF, dated November 2023. The authors are H. Brockhaus, H. Aschauer (Siemens), M. Ounsworth, and J. Gray (Entrust). Its ISSN is 2070-1721. 💅

The big news is that it updates RFC 4210. The algorithm list in Appendix D.2 of RFC 4210 gets refreshed here, so this is the newer, cuter version of that list. 🦋

#

This document describes how to use several cryptographic algorithms with the Certificate Management Protocol (CMP). CMP is what handles enrolling X.509 certificates and managing their whole lifecycle. 🔐 It also updates the algorithm use profile from Appendix D.2 of RFC 4210. 🌸

#

This is an Internet Standards Track document. ✨

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841. 🫶

Info about its current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9481. 💜

#

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, which you can find at https://trustee.ietf.org/license-info as of the publication date. Read those carefully, because they spell out your rights and restrictions for this document. 📜 Any Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License says. 🔥

#

Here's the map of everything in here 🗺️

1.  Introduction
  1.1.  Terminology
2.  Message Digest Algorithms
  2.1.  SHA2
  2.2.  SHAKE
3.  Signature Algorithms
  3.1.  RSA
  3.2.  ECDSA
  3.3.  EdDSA
4.  Key Management Algorithms
  4.1.  Key Agreement Algorithms
    4.1.1.  Diffie-Hellman
    4.1.2.  ECDH
  4.2.  Key Transport Algorithms
    4.2.1.  RSA
  4.3.  Symmetric Key-Encryption Algorithms
    4.3.1.  AES Key Wrap
  4.4.  Key Derivation Algorithms
    4.4.1.  PBKDF2
5.  Content-Encryption Algorithms
  5.1.  AES-CBC
6.  Message Authentication Code Algorithms
  6.1.  Password-Based MAC
    6.1.1.  PasswordBasedMac
    6.1.2.  PBMAC1
  6.2.  Symmetric Key-Based MAC
    6.2.1.  SHA2-Based HMAC
    6.2.2.  AES-GMAC
    6.2.3.  SHAKE-Based KMAC
7.  Algorithm Use Profiles
  7.1.  Algorithm Profile for PKI Management Message Profiles in
        RFC 4210
  7.2.  Algorithm Profile for Lightweight CMP Profile
8.  IANA Considerations
9.  Security Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🌷

Okay so, Appendix D.2 of [RFC4210] has a list of algorithms that every implementation conforming to [RFC4210] is required to support. 🫠 Back when CMP came out, those picks were totally fine. But crypto algorithms weaken over time, so some of them are not it anymore. New attacks keep popping up thanks to cryptanalysis research or just more computing power getting cheap. Meanwhile, newer algorithms showed up that are way more resistant to today's attacks. 💀

So this document lists the current cryptographic algorithms you can use with CMP. The goal is an easier way to keep your list of suitable algorithms fresh as time goes on. ✨

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. 🧠 Lowercase versions are just regular words, bestie.

In the sections coming up, ASN.1 values and types show where the algorithm identifiers and output values live. Those ASN.1 values and types are defined in CMP [RFC4210], Certificate Request Message Format (CRMF) [RFC4211], CMP Updates [RFC9480], and Cryptographic Message Syntax (CMS) [RFC5652]. 🧩

2. Message Digest Algorithms 🍓

This section gives you references to object identifiers and the conventions CMP implementations should follow when they support SHA2 or SHAKE message digest algorithms. 💖

Digest algorithm identifiers show up in these spots:

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

Digest values hang out in these spots:

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

On top of that, digest values are also used as input to signature algorithms. 🔥

2.1. SHA2 🌈

The SHA2 algorithm family is defined in FIPS Pub 180-4 [NIST.FIPS.180-4]. 📚

These message digest algorithms are identified by the OIDs below: SHA-224, SHA-256, SHA-384, and SHA-512. 🎀

   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 }

The specific conventions you need to follow are in Section 2 of [RFC5754]. 🫶

2.2. SHAKE 🦋

The SHA-3 family of hash functions is defined in FIPS Pub 202 [NIST.FIPS.202]. It has fixed output length variants (SHA3-224, SHA3-256, SHA3-384, and SHA3-512) and also extendable-output functions (XOFs), SHAKE128 and SHAKE256. ✨

Right now, SHAKE128 and SHAKE256 are the only SHA3-family members specified for use in X.509 certificates [RFC8692] and CMS [RFC8702] as one-way hash functions for RSASSA-PSS and ECDSA. 👑

SHAKE is an extendable-output function, and FIPS Pub 202 [NIST.FIPS.202] prohibits using SHAKE as a general-purpose hash function. 🙈 So 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. This one is non-negotiable, bestie. 🚨

The message digest algorithms SHAKE128 and SHAKE256 are identified by these 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 }

The specific conventions to consider are in Section 3.1 of [RFC8702]. 💅

3. Signature Algorithms 💜

This section gives you references to object identifiers and conventions for CMP implementations that support signature algorithms like RSA, ECDSA, or EdDSA. 🌸

The signature algorithm is referred to as MSG_SIG_ALG in Appendices D and E of [RFC4210], in the Lightweight CMP Profile [RFC9483], and in Section 7.2 of this document. 🧚

Signature algorithm identifiers show up in these spots:

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

Signature values live in these spots:

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

3.1. RSA ⚡

The RSA signature algorithm (RSASSA-PSS and PKCS #1 version 1.5) is defined in [RFC8017]. 🔐

The algorithm identifier for RSASSA-PSS signatures used with SHA2 message digest algorithms is identified by this OID:

   id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2)
      us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 }

The specific conventions to consider are in [RFC4056]. 🫶

The signature algorithm RSASSA-PSS used with SHAKE message digest algorithms is identified by these 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 }

The specific conventions to consider are in Section 3.2.1 of [RFC8702]. 🦋

The signature algorithm PKCS #1 version 1.5 used with SHA2 message digest algorithms is identified by these 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 }

The specific conventions to consider are in Section 3.2 of [RFC5754]. 🌈✨

3.2. ECDSA ✨

okay so ECDSA is the signature algorithm defined in FIPS Pub 186-5 [NIST.FIPS.186-5], and it's giving main character energy 💅

When ECDSA is used with the SHA2 message digest algorithms, it gets identified by these 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 [RFC5480], the NIST-recommended curves get their own OIDs too, like this:

   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 Section 3.3 of [RFC5754] 🎀

When ECDSA is used with SHAKE message digest algorithms, it gets these 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 Section 3.2.2 of [RFC8702] 🦋

3.3. EdDSA 🌈

The EdDSA signature algorithm is defined in Section 3.3 of [RFC8032] and FIPS Pub 186-5 [NIST.FIPS.186-5] 💜

The signature algorithm Ed25519 MUST be used with SHA-512 message digest algorithms, and it gets identified by this OID:

   id-Ed25519 OBJECT IDENTIFIER  ::=  { iso(1)
      identified-organization(3) thawte(101) 112 }

The signature algorithm Ed448 MUST be used with SHAKE256 message digest algorithms, and it gets identified by this OID:

   id-Ed448 OBJECT IDENTIFIER  ::=  { iso(1)
      identified-organization(3) thawte(101) 113 }

Specific conventions to be considered are specified in [RFC8419] ✨

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. 🙈

4. Key Management Algorithms 🔥

okay so CMP uses these general key management techniques: key agreement, key transport, and passwords 🫶

CRMF [RFC4211] and CMP Updates [RFC9480] promote the use of CMS EnvelopedData [RFC5652] by deprecating the use of EncryptedValue 💅

4.1. Key Agreement Algorithms 🦋

The key agreement algorithm is referred to as PROT_ENC_ALG in Appendices D and E of [RFC4210], and as KM_KA_ALG in the Lightweight CMP Profile [RFC9483] and Section 7 ✨

Key agreement algorithms are only used in CMP when using CMS EnvelopedData [RFC5652] 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:

  • 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.

4.1.1. Diffie-Hellman 💖

The Diffie-Hellman (DH) key agreement is defined in [RFC2631] and SHALL be used in the ephemeral-static variants, as specified in [RFC3370]. Static-static variants SHALL NOT be used 🙅‍♀️

The DH key agreement algorithm is identified by this 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 Section 4.1 of [RFC3370] 🌸

4.1.2. ECDH 🧚

The Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined in [RFC5753] and SHALL be used in the ephemeral-static variant, as specified in [RFC5753], or the 1-Pass Elliptic Curve Menezes-Qu-Vanstone (ECMQV) variant, as specified in [RFC5753]. Static-static variants SHALL NOT be used 💅

The ECDH key agreement algorithm used together with NIST-recommended SECP curves is identified by these 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 [RFC5480], the NIST-recommended SECP curves are identified by these 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 [RFC5753] 🎀

The ECDH key agreement algorithm used together with curve25519 or curve448 is identified by these 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 [RFC8418] 🦋

4.2. Key Transport Algorithms 🌈

The key transport algorithm is also referred to as PROT_ENC_ALG in Appendices D and E of [RFC4210], and as KM_KT_ALG in the Lightweight CMP Profile [RFC9483] and Section 7 💜

Key transport algorithms are only used in CMP when using CMS [RFC5652] 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.

4.2.1. RSA 🍓

The RSA key transport algorithm is the RSA encryption scheme defined in [RFC8017] 💖

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 Section 4.2.1 of [RFC3370], and for RSAES-OAEP in [RFC3560] 🫶

4.3. Symmetric Key-Encryption Algorithms 🌸

The symmetric key-encryption algorithm is also referred to as KM_KW_ALG in Section 7.2 and the Lightweight CMP Profile [RFC9483] 🧚

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 [RFC5652] 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).

4.3.1. AES Key Wrap 🎀

The AES encryption algorithm is defined in FIPS Pub 197 [NIST.FIPS.197], and the key wrapping is defined in [RFC3394] ✨

AES key encryption has this 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 [RFC8551] 💀

Further conventions to be considered for AES key wrap are specified in Section 2.2 of [RFC3394] and Section 2.3.2 of [RFC3565] 🫶

4.4. Key Derivation Algorithms 🔑

Okay so, this one is also called KM_KD_ALG in Section 7.2 and in the Lightweight CMP Profile [RFC9483], so if you see that name, it's the same thing, bestie.

Key derivation algorithms only show up in CMP when you're using CMS EnvelopedData [RFC5652] together with the password-based key management technique. That's the only time they're needed, so don't go looking for them anywhere else 💅

You'll find the key derivation algorithm identifiers in:

  • the keyDerivationAlgorithm field of PasswordRecipientInfo.

Now here's the spicy part 🌶️ When you use the password-based key management technique with EnvelopedData, as specified in CMP Updates [RFC9480], and you pair it with PKIProtection based on a message authentication code (MAC), the salt for the password-based MAC and the key derivation function (KDF) must be chosen independently. The whole point is to make sure you end up with independent symmetric keys, so don't reuse the salt across both 🙈

4.4.1. PBKDF2 🧂

Password-based key derivation function 2 (PBKDF2) is defined in [RFC8018]. It's a classic, iconic move.

PBKDF2 has the algorithm identifier:

id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
   rsadsi(113549) pkcs(1) pkcs-5(5) 12 }

If you want more PBKDF2 details, the further conventions are in Section 4.4.1 of [RFC3370] and Section 5.2 of [RFC8018]. Go read those, they're giving full detail ✨

5. Content-Encryption Algorithms 🎀

The content-encryption algorithm is also referred to as PROT_SYM_ALG in Appendices D and E of [RFC4210], in the Lightweight CMP Profile [RFC9483], and in Section 7. Same energy, different name, you know the drill 💖

Content-encryption algorithms get used in CMP when you're using CMS EnvelopedData [RFC5652] to carry one of these things: a signed private key package (for central key generation or key archiving), a certificate to support implicit proof-of-possession, or a revocation passphrase in encrypted form. Lowkey, that's a lot of important stuff riding on this 🫶

The content-encryption algorithm identifiers live in:

  • the contentEncryptionAlgorithm field of EncryptedContentInfo.

And the encrypted content lives in:

  • the encryptedContent field of EncryptedContentInfo.

5.1. AES-CBC 🌸

The AES encryption algorithm is defined in FIPS Pub 197 [NIST.FIPS.197]. AES is a main character in this whole document, honestly 👑

AES Cipher Block Chaining (AES-CBC) content encryption has the algorithm identifiers below:

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 }

The specific conventions for AES-CBC content encryption are in [RFC3565]. Bookmark it 🔖

6. Message Authentication Code Algorithms 🦋

The message authentication code (MAC) is either used for shared secret-based CMP message protection, or it's used together with the password-based key derivation function (PBKDF2). Two different vibes, both valid ✨

The MAC algorithm is also referred to as MSG_MAC_ALG in Section 7, Appendices D and E of [RFC4210], and the Lightweight CMP Profile [RFC9483]. Yep, it's got a lot of aliases, it's a whole celebrity 🌟

6.1. Password-Based MAC 🗝️

Password-based message authentication code (MAC) algorithms combine two things: deriving a symmetric key from a password or other shared secret information, and a symmetric key-based MAC function (the one in Section 6.2), which then uses that derived key. Teamwork makes the dream work 🤝

The MAC algorithm identifiers are located in the:

  • protectionAlg field of PKIHeader.

The message authentication code values are located in the:

  • PKIProtection field of PKIMessage.

6.1.1. PasswordBasedMac 💜

The PasswordBasedMac algorithm is defined in Section 5.1.3.1 of [RFC4210], Section 4.4 of [RFC4211], and "Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)" [RFC9045].

PasswordBasedMac is identified by this 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 Section 5.1.3.1 of [RFC4210], Section 4.4 of [RFC4211], and "Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)" [RFC9045]. It's the same squad, so you'll see the same references again 🫶

6.1.2. PBMAC1 🎀

Password-Based Message Authentication Code 1 (PBMAC1) is defined in [RFC8018]. PBMAC1 combines a password-based key derivation function, like PBKDF2 (Section 4.4.1), with an underlying symmetric key-based message authentication scheme. It's giving layered, and I'm obsessed 😭

PBMAC1 has the following OID:

id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
   rsadsi(113549) pkcs(1) pkcs-5(5) 14 }

The specific conventions to be considered for PBMAC1 are in Section 7.1 and Appendix A.5 of [RFC8018].

6.2. Symmetric Key-Based MAC 🔐

Symmetric key-based message authentication code (MAC) algorithms are used for two things: deriving the symmetric encryption key when you're using PBKDF2 (as in Section 4.4.1), and working with password-based MAC (as in Section 6.1). Versatile queen behavior 👑

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.

6.2.1. SHA2-Based HMAC 🍓

The HMAC algorithm is defined in [RFC2104] and FIPS Pub 198-1 [NIST.FIPS.198-1].

HMAC used with the SHA2 message digest algorithms is identified by these 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 for SHA2-based HMAC are in Section 3.1 of [RFC4231].

6.2.2. AES-GMAC 🧁

The AES-GMAC algorithm is defined in FIPS Pub 197 [NIST.FIPS.197] and NIST SP 800-38d [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.

Bestie, please read that note twice 🙈 It's the kind of rule that really matters.

The AES-GMAC algorithm is identified by these 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 for AES-GMAC are specified in [RFC9044].

6.2.3. SHAKE-Based KMAC 🌈

The KMAC algorithm is defined in [RFC8702] and FIPS SP 800-185 [NIST.SP.800-185]].

The SHAKE-based KMAC algorithm is identified by these 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 for KMAC with SHAKE are specified in Section 3.4 of [RFC8702]. And that's the vibe for this part, periodt ✨

7. Algorithm Use Profiles 🎀

Okay bestie, this section is all about algorithm profiles 💅 and picking the right crypto combo for each use case. The vibe is "match your algorithms to the job" 🫶

Stuff like Table 2 of NIST SP 800-57 "Recommendation for Key Management" [NIST.SP.800-57pt1r5] and Section 4.6 of ECRYPT "Algorithms, Key Size and Protocols Report (2018)" [ECRYPT.CSA.D5.4] gives you the general lowdown on current cryptographic algorithms 📚✨

The overall strength of a CMP implementation depends on a few things, ngl:

  • end entity capabilities: 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 is the strength of the weakest algorithm it contains. Weakest link energy 💀
  • message protection: The overall strength of the CMP message protection depends on:
    • 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 (Section 7.1: PROT_ENC_ALG or Section 7.2: KM_KA_ALG, KM_KT_ALG, KM_KD_ALG) and the encryption of the content-encryption key and private key (Section 7.1: SYM_PENC_ALG, PROT_SYM_ALG or Section 7.2: KM_KW_ALG, PROT_SYM_ALG).

Next up, the table below lists the algorithms from this document sorted by bits of security 🌸 If an implementation wants to enroll and manage certificates for keys of a specific security level, it SHALL implement and use algorithms of at least that strength for the respective PKI management operation. If one row doesn't have a suitable algorithm, the implementer MUST choose one offering more bits of security. No shortcuts, periodt 💖

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

Table 1: Cryptographic Algorithms Sorted by Their Bits of Security

Now the fancier one 🦋 This table shows the cryptographic algorithms sorted by how they're used in CMP, with more details:

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

Table 2: Cryptographic Algorithms Sorted by Their Bits of Security and Usage by CMP

Last bit, and it's a big one ✨ To avoid eating through too many computational resources, choosing a set of algorithms that offer 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. Balance is everything, bestie 💜

7.1. Algorithm Profile for PKI Management Message Profiles in RFC 4210 💖

okay so this section is where we update the algorithm rules for PKI Management Message Profiles 🎀 The original definitions live in Appendix D.2 of [RFC4210], and this table is the glow-up. 🦋

The columns are:

  • Name: an identifier used for message profiles
  • Use: where and what the algorithm is used for
  • Mandatory: algorithms that MUST be supported by conforming implementations
  • Optional: algorithms that are OPTIONAL to support
  • Deprecated: algorithms from [RFC4210] that SHOULD NOT be used any more 💀
+============+=============+=========+=================+============+
|Name        |Use          |Mandatory|Optional         |Deprecated  |
+============+=============+=========+=================+============+
|MSG_SIG_ALG |protection of|RSA      |ECDSA, EdDSA     |DSA,        |
|            |PKI messages |         |                 |combinations|
|            |using        |         |                 |with MD5 and|
|            |signatures   |         |                 |SHA-1       |
+------------+-------------+---------+-----------------+------------+
|MSG_MAC_ALG |protection of|PBMAC1   |PasswordBasedMac,|X9.9        |
|            |PKI messages |         |HMAC, KMAC       |            |
|            |using MACs   |         |                 |            |
+------------+-------------+---------+-----------------+------------+
|SYM_PENC_ALG|symmetric    |AES-wrap |                 |3-DES(3-key-|
|            |encryption of|         |                 |EDE, CBC    |
|            |an end       |         |                 |Mode), RC5, |
|            |entity's     |         |                 |CAST-128    |
|            |private key  |         |                 |            |
|            |where the    |         |                 |            |
|            |symmetric key|         |                 |            |
|            |is           |         |                 |            |
|            |distributed  |         |                 |            |
|            |out of band  |         |                 |            |
+------------+-------------+---------+-----------------+------------+
|PROT_ENC_ALG|asymmetric   |DH       |ECDH, RSA        |            |
|            |algorithm    |         |                 |            |
|            |used for     |         |                 |            |
|            |encryption of|         |                 |            |
|            |(symmetric   |         |                 |            |
|            |keys for     |         |                 |            |
|            |encryption   |         |                 |            |
|            |of) private  |         |                 |            |
|            |keys         |         |                 |            |
|            |transported  |         |                 |            |
|            |in           |         |                 |            |
|            |PKIMessages  |         |                 |            |
+------------+-------------+---------+-----------------+------------+
|PROT_SYM_ALG|symmetric    |AES-CBC  |                 |3-DES(3-key-|
|            |encryption   |         |                 |EDE, CBC    |
|            |algorithm    |         |                 |Mode), RC5, |
|            |used for     |         |                 |CAST-128    |
|            |encryption of|         |                 |            |
|            |private key  |         |                 |            |
|            |bits (a key  |         |                 |            |
|            |of this type |         |                 |            |
|            |is encrypted |         |                 |            |
|            |using        |         |                 |            |
|            |PROT_ENC_ALG)|         |                 |            |
+------------+-------------+---------+-----------------+------------+

       Table 3: Algorithms Used within Appendix D.2 of RFC 4210

Here are the mandatory algorithm identifiers and specs, bestie 🫶

  • RSA: sha256WithRSAEncryption with 2048 bit, see Section 3.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, see Section 6.1.2 (with id-PBKDF2 as the key derivation function, see Section 4.4.1 and id-hmacWithSHA256 as the message authentication scheme, see Section 6.2.1). It is RECOMMENDED to prefer the usage of PBMAC1 instead of PasswordBasedMac. 🌈
  • DH: id-alg-ESDH, see Section 4.1.1
  • AES-wrap: id-aes128-wrap, see Section 4.3.1
  • AES-CBC: id-aes128-CBC, see Section 5.1

7.2. Algorithm Profile for Lightweight CMP Profile 🧚

this one is the Lightweight CMP Profile [RFC9483] lineup 🌸 It's a list of algorithms that MAY be supported by implementations of that profile.

Which algorithms you actually need really depends on which PKI management operations you implement, which certificates protect your messages, and which certificates you're managing. So this document does NOT name a specific mandatory set for conforming implementations. Main character decision-making, but it's YOUR call 💅

The columns are:

  • Name: an identifier used for message profiles
  • Use: where and what the algorithm is used for
  • Examples: lists the algorithms, as described in this document. The list depends on the set of PKI management operations you're implementing.
Note: It is RECOMMENDED to prefer the usage of PBMAC1 instead of PasswordBasedMac. 🙈
+==============+================================+==================+
| Name         | Use                            | Examples         |
+==============+================================+==================+
| MSG_SIG_ALG  | protection of PKI messages     | RSA, ECDSA,      |
|              | using signatures and for       | EdDSA            |
|              | SignedData, e.g., a private    |                  |
|              | key transported in PKIMessages |                  |
+--------------+--------------------------------+------------------+
| MSG_MAC_ALG  | protection of PKI messages     | PasswordBasedMac |
|              | using MACing                   | (see Section 9), |
|              |                                | PBMAC1, HMAC,    |
|              |                                | KMAC             |
+--------------+--------------------------------+------------------+
| KM_KA_ALG    | asymmetric key agreement       | DH, ECDH         |
|              | algorithm used for agreement   |                  |
|              | of a symmetric key for use     |                  |
|              | with KM_KW_ALG                 |                  |
+--------------+--------------------------------+------------------+
| KM_KT_ALG    | asymmetric key-encryption      | RSA              |
|              | algorithm used for transport   |                  |
|              | of a symmetric key for         |                  |
|              | PROT_SYM_ALG                   |                  |
+--------------+--------------------------------+------------------+
| KM_KD_ALG    | symmetric key derivation       | PBKDF2           |
|              | algorithm used for derivation  |                  |
|              | of a symmetric key for use     |                  |
|              | with KM_KW_ALG                 |                  |
+--------------+--------------------------------+------------------+
| KM_KW_ALG    | algorithm to wrap a symmetric  | AES-wrap         |
|              | key for PROT_SYM_ALG           |                  |
+--------------+--------------------------------+------------------+
| PROT_SYM_ALG | symmetric content-encryption   | AES-CBC          |
|              | algorithm used for encryption  |                  |
|              | of EnvelopedData, e.g., a      |                  |
|              | private key transported in     |                  |
|              | PKIMessages                    |                  |
+--------------+--------------------------------+------------------+

       Table 4: Algorithms Used within the Lightweight CMP Profile

8. IANA Considerations 🦋

okay quick one: this document has no IANA actions. Nothing to register, nothing to update 💅

9. Security Considerations 🔥

okay bestie, this part is SERIOUS, so read it carefully 😭

This document lists many cryptographic algorithms that you can use with CMP, so implementers get a more up-to-date choice. The algorithms you support also depend heavily on the certificates and PKI management operations in your target environment. The algorithm with the lowest security strength, plus the entropy of the shared secret information, defines the security of the whole solution. See Section 7. 👑

When you use MAC-based message protection, PBMAC1 is preferable to PasswordBasedMac. Here's why it's the iconic choice ✨ First, PBMAC1 is a well-known, scrutinized algorithm, and PasswordBasedMac isn't. Second, PasswordBasedMac as specified in Section 4.4 of [RFC4211] is basically PBKDF1 (as defined in Section 5.1 of [RFC8018]) with an HMAC step at the end. So this document updates things to use the PBKDF2-HMAC construct that [RFC8018] defines as PBMAC1. PBKDF2 is superior to PBKDF1 because it has an improved internal construct for iterated hashing, and it gets rid of PBKDF1's limit of only deriving keys up to the size of the underlying hash function. Also, Section 5.1 of [RFC8018] says PBKDF1 is not recommended for new applications, and most standards bodies no longer approve it. That makes it really hard for implementers to get their CMP implementations certified, so we're moving to a PBKDF2-based mechanism. This change lines up with [RFC9045], which updates [RFC4211] to allow PBMAC1 in CRMF. 🎀

The AES-GMAC MUST NOT be used as the pseudorandom function (PRF) in PBKDF2. Reusing AES-GMAC with the same key and the same nonce more than once will break the security. 💀 Don't do it, babe.

Section 7 of this document also updates Appendix D.2 of [RFC4210], and it sets out a group of algorithms that MAY be supported when you implement the Lightweight CMP Profile [RFC9483]. There may be older CMP implementations out there that follow the algorithm use profile from Appendix D.2 of [RFC4210], and that's fine, it's acknowledged. For example, AES is now mandatory for PROT_SYM_ALG, while 3-DES was mandatory in [RFC4210]. So it's expected that lots of CMP systems already support the recommended algorithms in this spec. In those systems, the weakened algorithms should be disabled from further use. If critical systems can't be updated to the recommended algorithm use profile right away, it is recommended that you adopt a plan to migrate the infrastructure to conforming profiles as soon as possible. Migrate ASAP, no cap 🫶

Symmetric key-based MAC algorithms described in Section 6.2 MAY be used as MSG_MAC_ALG. The implementer MUST choose a suitable PRF and make sure the key has sufficient entropy to match the overall security level of the algorithm profile. These considerations are outside the scope of the profile, so it's on you to get them right 🧚

10. References 📚

10.1. Normative References ✨

okay bestie, these are the normative references 🫶 they're the docs you need to read to fully get the spec, so I'm keeping every single one with all its details.

[NIST.FIPS.180-4] Dang, Q. H. and NIST, "Secure Hash Standard", NIST Federal Information Processing Standards Publications 180-4, DOI 10.6028/NIST.FIPS.180-4, July 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>.

[NIST.FIPS.186-5] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", FIPS PUB 186-5, DOI 10.6028/NIST.FIPS.186-5, February 2023, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf>.

[NIST.FIPS.197] National Institute of Standards and Technology (NIST), "Advanced Encryption Standard (AES)", NIST FIPS 197, DOI 10.6028/NIST.FIPS.197, November 2001, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf>.

[NIST.FIPS.198-1] National Institute of Standards and Technology (NIST), "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198-1, DOI 10.6028/NIST.FIPS.198-1, July 2008, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf>.

[NIST.FIPS.202] Dworkin, M. J. and NIST, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", NIST Federal Information Processing Standards Publications 202, DOI 10.6028/NIST.FIPS.202, July 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf>.

[NIST.SP.800-185]] Kelsey, J., Change, S., Perlner, R., and NIST, "SHA-3 derived functions: cSHAKE, KMAC, TupleHash and ParallelHash", NIST Special Publications (General) 800-185, DOI 10.6028/NIST.SP.800-185, December 2016, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf>.

[NIST.SP.800-38d] Dworkin, M J. and NIST, "Recommendation for block cipher modes of operation :GaloisCounter Mode (GCM) and GMAC", NIST Special Publications (General) 800-38d, DOI 10.6028/NIST.SP.800-38d, 2007, <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf>.

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, DOI 10.17487/RFC2631, June 1999, <https://www.rfc-editor.org/info/rfc2631>.

[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, <https://www.rfc-editor.org/info/rfc3370>.

[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, <https://www.rfc-editor.org/info/rfc3394>.

[RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)", RFC 3560, DOI 10.17487/RFC3560, July 2003, <https://www.rfc-editor.org/info/rfc3560>.

[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, <https://www.rfc-editor.org/info/rfc3565>.

[RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)", RFC 4056, DOI 10.17487/RFC4056, June 2005, <https://www.rfc-editor.org/info/rfc4056>.

[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, DOI 10.17487/RFC4210, September 2005, <https://www.rfc-editor.org/info/rfc4210>.

[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, <https://www.rfc-editor.org/info/rfc4211>.

[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, <https://www.rfc-editor.org/info/rfc4231>.

[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, <https://www.rfc-editor.org/info/rfc5480>.

[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.

[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, <https://www.rfc-editor.org/info/rfc5753>.

[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, <https://www.rfc-editor.org/info/rfc5754>.

[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.

[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: Password-Based Cryptography Specification Version 2.1", RFC 8018, DOI 10.17487/RFC8018, January 2017, <https://www.rfc-editor.org/info/rfc8018>.

[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8418] Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)", RFC 8418, DOI 10.17487/RFC8418, August 2018, <https://www.rfc-editor.org/info/rfc8418>.

[RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 2018, <https://www.rfc-editor.org/info/rfc8419>.

[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/info/rfc8551>.

[RFC8692] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, DOI 10.17487/RFC8692, December 2019, <https://www.rfc-editor.org/info/rfc8692>.

[RFC8702] Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS)", RFC 8702, DOI 10.17487/RFC8702, January 2020, <https://www.rfc-editor.org/info/rfc8702>.

[RFC9044] Housley, R., "Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)", RFC 9044, DOI 10.17487/RFC9044, June 2021, <https://www.rfc-editor.org/info/rfc9044>.

[RFC9045] Housley, R., "Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 9045, DOI 10.17487/RFC9045, June 2021, <https://www.rfc-editor.org/info/rfc9045>.

[RFC9480] Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate Management Protocol (CMP) Updates", RFC 9480, DOI 10.17487/RFC9480, November 2023, <https://www.rfc-editor.org/info/rfc9480>.

[RFC9483] Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight Certificate Management Protocol (CMP) Profile", RFC 9483, DOI 10.17487/RFC9483, November 2023, <https://www.rfc-editor.org/info/rfc9483>.

10.2. Informative References 🌸

these ones are the informative vibes, bestie, extra reading that's super helpful but not required 💅

[ECRYPT.CSA.D5.4] University of Bristol, "Algorithms, Key Size and Protocols Report (2018)", March 2015, <https://www.ecrypt.eu.org/csa/documents/D5.4-FinalAlgKeySizeProt.pdf>.

[NIST.SP.800-57pt1r5] Barker, E. and NIST, "Recommendation for key management:part 1 - general", NIST Special Publications (General) 800-57pt1r5, DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf>.

Acknowledgements 🫶

huge thanks to Russ Housley for his work on [RFC9044] and [RFC9045], which this RFC leans on heavily 😭✨

also big thank yous to all the reviewers, like Serge Mister, Mark Ferreira, Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb, and Steffen Fries, for their input and feedback on this document. sorry to anyone I forgot, you're still iconic 💖

Authors' Addresses 🎀

Hendrik Brockhaus
Siemens AG
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: hendrik.brockhaus@siemens.com
URI:   https://www.siemens.com


Hans Aschauer
Siemens AG
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: hans.aschauer@siemens.com
URI:   https://www.siemens.com


Mike Ounsworth
Entrust
1187 Park Place
Minneapolis, MN 55379
United States of America
Email: mike.ounsworth@entrust.com
URI:   https://www.entrust.com


John Gray
Entrust
1187 Park Place
Minneapolis, MN 55379
United States of America
Email: john.gray@entrust.com
URI:   https://www.entrust.com

the end, bestie 🌈💜🦋

📦 where this page comes from