RFC 3370

Cryptographic Message Syntax (CMS) Algorithms

📅 published September 2002, from ietf

RFC 3370: Cryptographic Message Syntax (CMS) Algorithms ✨

Okay bestie, this one is RFC 3370 🎀, a Standards Track doc from the Network Working Group. R. Housley wrote it while at RSA Laboratories, and it was published in August 2002 💅. It obsoletes RFC 2630 and RFC 3211 🫶, so if you see those older ones floating around, this is the update you want.

Status of This Memo 🌸

This document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💖.

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract ✨

Okay so this doc is all about the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) 🔐. CMS is the thing people use to digitally sign, digest, authenticate, or encrypt arbitrary message contents. It's giving main character energy.

Table of Contents 📋

1     Introduction ...............................................  2
1.1   Changes Since RFC 2630 .....................................  2
1.2   Terminology ................................................  2
2     Message Digest Algorithms ..................................  3
2.1   SHA-1 ......................................................  3
2.2   MD5 ........................................................  3
3     Signature Algorithms .......................................  4
3.1   DSA ........................................................  4
3.2   RSA ........................................................  5
4     Key Management Algorithms ..................................  6
4.1   Key Agreement Algorithms ...................................  6
4.1.1 X9.42 Ephemeral-Static Diffie-Hellman ......................  7
4.1.2 X9.42 Static-Static Diffie-Hellman .........................  8
4.2   Key Transport Algorithms ...................................  9
4.2.1 RSA (PKCS #1 v1.5) ......................................... 10
4.3   Symmetric Key-Encryption Key Algorithms .................... 10
4.3.1 Triple-DES Key Wrap ........................................ 11
4.3.2 RC2 Key Wrap ............................................... 12
4.4   Key Derivation Algorithms .................................. 12
4.4.1 PBKDF2 ..................................................... 13
5     Content Encryption Algorithms .............................. 13
5.1   Triple-DES CBC ............................................. 14
5.2   RC2 CBC .................................................... 14
6     Message Authentication Code (MAC) Algorithms ............... 15
6.1   HMAC with SHA-1 ............................................ 15
7     ASN.1 Module ............................................... 16
8     References ................................................. 18
9     Security Considerations .................................... 20
10    Acknowledgments ............................................ 22
11    Author's Address ........................................... 23
12    Full Copyright Statement ................................... 24

1. Introduction ✨

Okay so CMS [CMS] is the Cryptographic Message Syntax, and it's used to digitally sign, digest, authenticate, or encrypt arbitrary message contents 🔐. This companion spec explains how to use common cryptographic algorithms with CMS. CMS implementations may support these algorithms, and they may also support other algorithms too 🌈. BUT, if an implementation chooses to support one of the algorithms discussed in this document, then it MUST do so as described in this document 💅. No going rogue, bestie.

The CMS values are generated using ASN.1 [X.208-88], using BER-encoding [X.209-88] 🧚. Algorithm identifiers, which include ASN.1 object identifiers, identify cryptographic algorithms, and some algorithms need extra parameters. When that's the case, the parameters are specified with an ASN.1 structure. Each algorithm's identifier gets specified, and when needed, its parameter structure does too. The fields in CMS that each algorithm uses are also identified 💖.

1.1. Changes Since RFC 2630

So this document obsoletes section 12 of RFC 2630 [OLDCMS] 🙈. RFC 3369 [CMS] obsoletes the rest of RFC 2630. Splitting the protocol and algorithm specs apart means each one can get updated without messing up the other 🦋. The conventions for using additional algorithms with CMS will probably be specified in separate documents.

1.2. Terminology

In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described in [STDWORDS] 📋.

2. Message Digest Algorithms 💖

This section lays out the conventions CMS implementations follow when they support SHA-1 or MD5 🌸.

Digest algorithm identifiers live in the SignedData digestAlgorithms field, the SignerInfo digestAlgorithm field, the DigestedData digestAlgorithm field, and the AuthenticatedData digestAlgorithm field 🔍.

Digest values live in the DigestedData digest field and the Message Digest authenticated attribute. Digest values also get fed into signature algorithms 🫶.

2.1. SHA-1

The SHA-1 message digest algorithm is defined in FIPS Pub 180-1 [SHA1]. Its algorithm identifier is:

sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
    oiw(14) secsig(3) algorithm(2) 26 }

Here's the tea ☕. There are two possible encodings for the SHA-1 AlgorithmIdentifier parameters field 😭. This happened because when the 1988 syntax for AlgorithmIdentifier got translated into the 1997 syntax, the OPTIONAL associated with the AlgorithmIdentifier parameters got lost. The OPTIONAL was recovered later through a defect report, but by then a lot of people thought algorithm parameters were mandatory. Because of that history, some implementations encode the parameters as a NULL element and others leave them out entirely. The correct encoding is to omit the parameters field; however, implementations MUST also handle a SHA-1 AlgorithmIdentifier parameters field that contains a NULL 💀.

The AlgorithmIdentifier parameters field is OPTIONAL. If it's present, the parameters field MUST contain a NULL. Implementations MUST accept SHA-1 AlgorithmIdentifiers with absent parameters. Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL parameters. Implementations SHOULD generate SHA-1 AlgorithmIdentifiers with absent parameters 🎀.

2.2. MD5

The MD5 digest algorithm is defined in RFC 1321 [MD5] 🍓. Its algorithm identifier is:

md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
    rsadsi(113549) digestAlgorithm(2) 5 }

The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain NULL. Implementations MAY accept MD5 AlgorithmIdentifiers with absent parameters as well as NULL parameters 🌈.

3. Signature Algorithms 🔥

This section lays out the conventions CMS implementations follow when they support DSA or RSA (PKCS #1 v1.5) 👑.

Signature algorithm identifiers live in the SignerInfo signatureAlgorithm field of SignedData. They also live in the SignerInfo signatureAlgorithm field of countersignature attributes 🧚.

Signature values live in the SignerInfo signature field of SignedData, and they also live in the SignerInfo signature field of countersignature attributes ✨.

3.1. DSA

The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA MUST be used with the SHA-1 message digest algorithm 💅.

The algorithm identifier for DSA subject public keys in certificates is:

id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) x9-57 (10040) x9cm(4) 1 }

DSA signature validation needs three parameters, commonly called p, q, and g 🔢. When the id-dsa algorithm identifier is used, the AlgorithmIdentifier parameters field is optional. If it's present, the AlgorithmIdentifier parameters field MUST contain the three DSA parameter values, encoded using the Dss-Parms type. If it's absent, the subject DSA public key uses the same DSA parameters as the certificate issuer 🫶.

Dss-Parms ::= SEQUENCE {
  p INTEGER,
  q INTEGER,
  g INTEGER  }

When the id-dsa algorithm identifier is used, the DSA public key, commonly called Y, MUST be encoded as an INTEGER. The output of this encoding is carried in the certificate subject public key 🦋.

Dss-Pub-Key ::= INTEGER  -- Y

The algorithm identifier for DSA with SHA-1 signature values is:

id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) x9-57 (10040) x9cm(4) 3 }

When the id-dsa-with-sha1 algorithm identifier is used, the AlgorithmIdentifier parameters field MUST be absent 🙅.

When signing, the DSA algorithm generates two values, commonly called r and s. To send those two values as one signature, they MUST be encoded using the Dss-Sig-Value type 🌸:

Dss-Sig-Value ::= SEQUENCE {
  r INTEGER,
  s INTEGER }

3.2. RSA

The RSA (PKCS #1 v1.5) signature algorithm is defined in RFC 2437 [NEWPKCS#1]. RFC 2437 specifies how to use the RSA signature algorithm with the SHA-1 and MD5 message digest algorithms 💖.

The algorithm identifier for RSA subject public keys in certificates is:

rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

When the rsaEncryption algorithm identifier is used, the AlgorithmIdentifier parameters field MUST contain NULL 🍓.

When the rsaEncryption algorithm identifier is used, the RSA public key, which is made up of a modulus and a public exponent, MUST be encoded using the RSAPublicKey type. The output of this encoding is carried in the certificate subject public key 🔐.

RSAPublicKey ::= SEQUENCE {
   modulus INTEGER, -- n
   publicExponent INTEGER } -- e

CMS implementations that include the RSA (PKCS #1 v1.5) signature algorithm MUST also implement the SHA-1 message digest algorithm. Such implementations SHOULD also support the MD5 message digest algorithm 🎀.

The rsaEncryption algorithm identifier is used to identify RSA (PKCS #1 v1.5) signature values no matter which message digest algorithm is in play 🌈. CMS implementations that include the RSA (PKCS #1 v1.5) signature algorithm MUST support the rsaEncryption signature value algorithm identifier. CMS implementations MAY also support RSA (PKCS #1 v1.5) signature value algorithm identifiers that specify both the RSA (PKCS #1 v1.5) signature algorithm and the message digest algorithm ✨.

The algorithm identifier for RSA (PKCS #1 v1.5) with SHA-1 signature values is:

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

The algorithm identifier for RSA (PKCS #1 v1.5) with MD5 signature values is:

md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }

When the rsaEncryption, sha1WithRSAEncryption, or md5WithRSAEncryption signature value algorithm identifiers are used, the AlgorithmIdentifier parameters field MUST be NULL 🫶.

When signing, the RSA algorithm generates a single value, and that value gets used directly as the signature value 💜.

4. Key Management Algorithms 🔑✨

Okay so section 4 is where CMS gets into the actual key management stuff 🫶 The general techniques are key agreement, key transport, previously distributed symmetric key-encryption keys, and passwords. Let's get into it 💅

4.1. Key Agreement Algorithms

This section is the rulebook for CMS implementations that do key agreement using X9.42 Ephemeral-Static Diffie-Hellman (X9.42 E-S D-H) and X9.42 Static-Static Diffie-Hellman (X9.42 S-S D-H) 🦋

Quick thing: when you use a key agreement algorithm, you also need a key-encryption algorithm 🔐 So when key agreement is supported, a key-encryption algorithm MUST be provided for each content-encryption algorithm. The key wrap algorithms for Triple-DES and RC2 are described in RFC 3217 [WRAP]. Lowkey important 👑

For key agreement of RC2 key-encryption keys, 128 bits MUST be generated as input to the key expansion process used to compute the RC2 effective key [RC2].

Here's where everything lives 🗺️

  • Key agreement algorithm identifiers live in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
  • Key wrap algorithm identifiers live in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
  • Wrapped content-encryption keys live in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field. Wrapped message-authentication keys live in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field.

4.1.1. X9.42 Ephemeral-Static Diffie-Hellman

Ephemeral-Static Diffie-Hellman key agreement is defined in RFC 2631 [DH-X9.42]. When you use it, the EnvelopedData RecipientInfos KeyAgreeRecipientInfo field gets used like this ✨

  • version MUST be 3.
  • originator MUST be the originatorKey alternative. The originatorKey algorithm field MUST contain the dh-public-number object identifier with absent parameters. The originatorKey publicKey field MUST contain the sender's ephemeral public key. The dh-public-number object identifier is:
         dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) ansi-x942(10046) number-type(2) 1 }
  • ukm may be present or absent. CMS implementations MUST support ukm being absent, and CMS implementations SHOULD support ukm being present. When present, the ukm is used to ensure that a different key-encryption key is generated when the ephemeral private key might be used more than once.
  • keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm identifier. The algorithm identifier parameter field for id-alg-ESDH is KeyWrapAlgorithm, and this parameter MUST be present. The KeyWrapAlgorithm denotes the symmetric encryption algorithm used to encrypt the content-encryption key with the pairwise key-encryption key generated using the X9.42 Ephemeral-Static Diffie-Hellman key agreement algorithm. Triple-DES and RC2 key wrap algorithms are described in RFC 3217 [WRAP]. The id-alg-ESDH algorithm identifier and parameter syntax is:
         id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
             alg(3) 5 }

         KeyWrapAlgorithm ::= AlgorithmIdentifier
  • recipientEncryptedKeys contains an identifier and an encrypted key for each recipient. The RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either the issuerAndSerialNumber identifying the recipient's certificate or the RecipientKeyIdentifier containing the subject key identifier from the recipient's certificate. In both cases, the recipient's certificate contains the recipient's static public key. The RecipientEncryptedKey EncryptedKey MUST contain the content-encryption key encrypted with the X9.42 Ephemeral-Static Diffie-Hellman generated pairwise key-encryption key using the algorithm specified by the KeyWrapAlgorithm.

4.1.2. X9.42 Static-Static Diffie-Hellman

Static-Static Diffie-Hellman key agreement is defined in RFC 2631 [DH-X9.42]. When you use it, the EnvelopedData RecipientInfos KeyAgreeRecipientInfo and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields get used like this 💖

  • version MUST be 3.
  • originator MUST be either the issuerAndSerialNumber or subjectKeyIdentifier alternative. In both cases, the originator's certificate contains the sender's static public key. RFC 3279 [CERTALGS] specifies the AlgorithmIdentifier parameters syntax and values that are included in the originator's certificate. The originator's certificate subject public key information field MUST contain the dh-public-number object identifier:
         dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) ansi-x942(10046) number-type(2) 1 }
  • ukm MUST be present. The ukm ensures that a different key-encryption key is generated for each message between the same sender and recipient.
  • keyEncryptionAlgorithm MUST be the id-alg-SSDH algorithm identifier. The algorithm identifier parameter field for id-alg-SSDH is KeyWrapAlgorihtm, and this parameter MUST be present. The KeyWrapAlgorithm denotes the symmetric encryption algorithm used to encrypt the content-encryption key with the pairwise key-encryption key generated using the X9.42 Static-Static Diffie-Hellman key agreement algorithm. Triple-DES and RC2 key wrap algorithms are described in RFC 3217 [WRAP]. The id-alg-SSDH algorithm identifier and parameter syntax is:
         id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
             alg(3) 10 }

         KeyWrapAlgorithm ::= AlgorithmIdentifier
  • recipientEncryptedKeys contains an identifier and an encrypted key for each recipient. The RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either the issuerAndSerialNumber identifying the recipient's certificate or the RecipientKeyIdentifier containing the subject key identifier from the recipient's certificate. In both cases, the recipient's certificate contains the recipient's static public key. The RecipientEncryptedKey EncryptedKey MUST contain the content-encryption key encrypted with the X9.42 Static-Static Diffie-Hellman generated pairwise key-encryption key using the algorithm specified by the KeyWrapAlgortihm.

4.2. Key Transport Algorithms

This section covers CMS implementations that do key transport using RSA (PKCS #1 v1.5) 🚚

Key transport algorithm identifiers live in the EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field.

Key transport encrypted content-encryption keys live in the EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey field.

4.2.1. RSA (PKCS #1 v1.5)

The RSA key transport algorithm is the RSA encryption scheme defined in RFC 2313 [PKCS#1], block type is 02, where the message to be encrypted is the content-encryption key. 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 AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain NULL.

When using a Triple-DES content-encryption key, CMS implementations MUST adjust the parity bits for each DES key comprising the Triple-DES key prior to RSA encryption.

⚠️ Heads up, bestie: using RSA (PKCS #1 v1.5) encryption, as defined in RFC 2313 [PKCS#1], to provide confidentiality has a known vulnerability. The vulnerability is primarily relevant to usage in interactive applications rather than to store-and-forward environments. Further information and proposed countermeasures are discussed in the Security Considerations section of this document and RFC 3218 [MMA]. 🙈

Note that the same RSA encryption scheme is also defined in RFC 2437 [NEWPKCS#1]. Within RFC 2437, this RSA encryption scheme is called RSAES-PKCS1-v1_5.

4.3. Symmetric Key-Encryption Key Algorithms

This section covers CMS implementations that do symmetric key-encryption key management using Triple-DES or RC2 key-encryption keys 🍓 When RC2 is supported, RC2 128-bit keys MUST be used as key-encryption keys, and they MUST be used with the RC2ParameterVersion parameter set to 58. A CMS implementation MAY support mixed key-encryption and content-encryption algorithms. For example, a 40-bit RC2 content-encryption key MAY be wrapped with a 168-bit Triple-DES key-encryption key or with a 128-bit RC2 key-encryption key.

Key wrap algorithm identifiers live in the EnvelopedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm fields.

Wrapped content-encryption keys live in the EnvelopedData RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped message-authentication keys live in the AuthenticatedData RecipientInfos KEKRecipientInfo encryptedKey field.

The output of a key agreement algorithm is a key-encryption key, and this key-encryption key is used to encrypt the content-encryption key. To support key agreement, key wrap algorithm identifiers live in the KeyWrapAlgorithm parameter of the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. However, only key agreement algorithms that inherently provide authentication ought to be used with AuthenticatedData. Wrapped content-encryption keys live in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field, and wrapped message-authentication keys live in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field.

4.3.1. Triple-DES Key Wrap

A CMS implementation MAY support mixed key-encryption and content-encryption algorithms. For example, a 128-bit RC2 content-encryption key MAY be wrapped with a 168-bit Triple-DES key-encryption key.

Triple-DES key encryption has the algorithm identifier:

      id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }

The AlgorithmIdentifier parameter field MUST be NULL.

The key wrap algorithm used to encrypt a Triple-DES content-encryption key with a Triple-DES key-encryption key is specified in section 3.1 of RFC 3217 [WRAP]. The corresponding key unwrap algorithm is specified in section 3.2 of RFC 3217 [WRAP].

Out-of-band distribution of the Triple-DES key-encryption key used to encrypt the Triple-DES content-encryption key is beyond the scope of this document 🧚

4.3.2. RC2 Key Wrap ✨

okay so CMS implementations MAY mix and match key-encryption and content-encryption algorithms 🧚 like, a 128-bit RC2 content-encryption key MAY get wrapped with a 168-bit Triple-DES key-encryption key. and the other way around too: a 40-bit RC2 content-encryption key MAY be wrapped with a 128-bit RC2 key-encryption key. mix-and-match era, literally 💅

RC2 key encryption has the algorithm identifier:

   id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }

The AlgorithmIdentifier parameter field MUST be RC2wrapParameter:

   RC2wrapParameter ::= RC2ParameterVersion

   RC2ParameterVersion ::= INTEGER

so the RC2 effective-key-bits (key size) greater than 32 and less than 256 get encoded in the RC2ParameterVersion 🎀 for 40, 64, and 128 effective-key-bits, the rc2ParameterVersion values are 160, 120, and 58 respectively. these values are not simply the RC2 key length, so don't go guessing 🙈 and note that the value 160 must be encoded as two octets (00 A0), because the one octet (A0) encoding represents a negative number. this one is a whole trap, bestie 💀

RC2 128-bit keys MUST be used as key-encryption keys, and they MUST be used with the RC2ParameterVersion parameter set to 58. no exceptions, periodt 👑

the key wrap algorithm used to encrypt a RC2 content-encryption key with a RC2 key-encryption key is specified in section 4.1 of RFC 3217 [WRAP]. the corresponding key unwrap algorithm is specified 4.2 of RFC 3217 [WRAP] 🦋

out-of-band distribution of the RC2 key-encryption key used to encrypt the RC2 content-encryption key is beyond of the scope of this document. that's not this doc's job, iykyk 🌸

4.4. Key Derivation Algorithms ✨

this section spells out the conventions CMS implementations follow when they support password-based key management using PBKDF2 🔐

key derivation algorithms are used to convert a password into a key-encryption key as part of the password-based key management technique. main character energy 👑

key derivation algorithm identifiers are located in the EnvelopedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm and AuthenticatedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm fields 🍓

the key-encryption key that is derived from the password is used to encrypt the content-encryption key. so the password never directly encrypts the content key, the derived KEK does 🫶

the content-encryption keys encrypted with password-derived key-encryption keys are located in the EnvelopedData RecipientInfos PasswordRecipientInfo encryptedKey field. the message-authentication keys encrypted with password-derived key-encryption keys are located in the AuthenticatedData RecipientInfos PasswordRecipientInfo encryptedKey field ✨

4.4.1. PBKDF2

the PBKDF2 key derivation algorithm is specified in RFC 2898 [PKCS#5]. the KeyDerivationAlgorithmIdentifer identifies the key-derivation algorithm, and any associated parameters used to derive the key-encryption key from the user-supplied password. the algorithm identifier for the PBKDF2 key derivation algorithm is:

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

The AlgorithmIdentifier parameter field MUST be PBKDF2-params:

   PBKDF2-params ::= SEQUENCE {
     salt CHOICE {
       specified OCTET STRING,
       otherSource AlgorithmIdentifier },
     iterationCount INTEGER (1..MAX),
     keyLength INTEGER (1..MAX) OPTIONAL,
     prf AlgorithmIdentifier
       DEFAULT { algorithm hMAC-SHA1, parameters NULL } }

within the PBKDF2-params, the salt MUST use the specified OCTET STRING 🧂

5. Content Encryption Algorithms ✨

this section spells out the conventions CMS implementations follow when they do content encryption with Three-Key Triple-DES in CBC mode, Two-Key Triple-DES in CBC mode, or RC2 in CBC mode 🎀

content encryption algorithm identifiers are located in the EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields 🍓

content encryption algorithms are used to encipher the content located in the EnvelopedData EncryptedContentInfo encryptedContent field and the EncryptedData EncryptedContentInfo encryptedContent field 🔐

5.1. Triple-DES CBC

the Triple-DES algorithm is described in ANSI X9.52 [3DES]. Triple-DES is composed from three sequential DES [DES] operations: encrypt, decrypt, and encrypt. Three-Key Triple-DES uses a different key for each DES operation. Two-Key Triple-DES uses one key for the two encrypt operations and a different key for the decrypt operation. the same algorithm identifiers are used for Three-Key Triple-DES and Two-Key Triple-DES, which is kind of a plot twist 🦋 the algorithm identifier for Triple-DES in Cipher Block Chaining (CBC) mode is:

   des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }

The AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain a CBCParameter:

   CBCParameter ::= IV

   IV ::= OCTET STRING  -- exactly 8 octets

5.2. RC2 CBC

the RC2 algorithm is described in RFC 2268 [RC2]. the algorithm identifier for RC2 in CBC mode is:

   rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
       rsadsi(113549) encryptionAlgorithm(3) 2 }

The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain a RC2CBCParameter:

   RC2CBCParameter ::= SEQUENCE {
     rc2ParameterVersion INTEGER,
     iv OCTET STRING  }  -- exactly 8 octets

the RC2 effective-key-bits (key size) greater than 32 and less than 256 is encoded in the rc2ParameterVersion. for the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, and 58 respectively. these values are not simply the RC2 key length. note that the value 160 must be encoded as two octets (00 A0), since the one octet (A0) encoding represents a negative number. same trap as before, bestie, don't fall for it again 🙈💅

6. Message Authentication Code Algorithms ✨

this section spells out the conventions CMS implementations follow when they support the HMAC with SHA-1 message authentication code (MAC) 🔥

MAC algorithm identifiers are located in the AuthenticatedData macAlgorithm field 🌈

MAC values are located in the AuthenticatedData mac field 🧚

6.1. HMAC with SHA-1

the HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. the algorithm identifier for HMAC with SHA-1 is:

   hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1)
      identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) 8 1 2 }

there are two possible encodings for the HMAC with SHA-1 AlgorithmIdentifier parameters field 😭 the two alternatives arise from the fact that when the 1988 syntax for the AlgorithmIdentifier type was translated into the 1997 syntax, the OPTIONAL associated with the AlgorithmIdentifier parameters got lost. later the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. because of this history, some implementations may encode parameters as a NULL while others omit them entirely. the drama of ASN.1, honestly 💀

The AlgorithmIdentifier parameters field is OPTIONAL. If present, the parameters field MUST contain a NULL. Implementations MUST accept HMAC with SHA-1 AlgorithmIdentifiers with absent parameters. Implementations MUST accept HMAC with SHA-1 AlgorithmIdentifiers with NULL parameters. Implementations SHOULD generate HMAC with SHA-1 AlgorithmIdentifiers with absent parameters. 🫶

7. ASN.1 Module ✨

here's the whole ASN.1 module, copied exactly so nothing gets lost in translation 🧚 no edits, no cap 💜

   CryptographicMessageSyntaxAlgorithms
       { iso(1) member-body(2) us(840) rsadsi(113549)
         pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   -- EXPORTS All
   -- The types and values defined in this module are exported for use
   -- in the other ASN.1 modules.  Other applications may use them for
   -- their own purposes.

   IMPORTS
     -- Imports from RFC 3280 [PROFILE], Appendix A.1
           AlgorithmIdentifier
              FROM PKIX1Explicit88 { iso(1)
                   identified-organization(3) dod(6) internet(1)
                   security(5) mechanisms(5) pkix(7) mod(0)
                   pkix1-explicit(18) } ;

   -- Algorithm Identifiers

   sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
       oiw(14) secsig(3) algorithm(2) 26 }

   md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
       rsadsi(113549) digestAlgorithm(2) 5 }

   id-dsa OBJECT IDENTIFIER ::=  { iso(1) member-body(2) us(840)
       x9-57(10040) x9cm(4) 1 }

   id-dsa-with-sha1 OBJECT IDENTIFIER ::=  { iso(1) member-body(2)
       us(840) x9-57(10040) x9cm(4) 3 }

   rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

   md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }

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

   dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) ansi-x942(10046) number-type(2) 1 }

   id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
       rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }

   id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
       rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 }

   id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }

   id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }

   des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }

   rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
       rsadsi(113549) encryptionAlgorithm(3) 2 }

   hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
       dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }

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

   -- Public Key Types

   Dss-Pub-Key ::= INTEGER  -- Y

   RSAPublicKey ::= SEQUENCE {
     modulus INTEGER,  -- n
     publicExponent INTEGER }  -- e

   DHPublicKey ::= INTEGER  -- y = g^x mod p


   -- Signature Value Types

   Dss-Sig-Value ::= SEQUENCE {
     r INTEGER,
     s INTEGER }

   -- Algorithm Identifier Parameter Types

   Dss-Parms ::= SEQUENCE {
     p INTEGER,
     q INTEGER,
     g INTEGER }

   DHDomainParameters ::= SEQUENCE {
     p INTEGER,  -- odd prime, p=jq +1
     g INTEGER,  -- generator, g
     q INTEGER,  -- factor of p-1
     j INTEGER OPTIONAL,  -- subgroup factor
     validationParms ValidationParms OPTIONAL }

   ValidationParms ::= SEQUENCE {
     seed BIT STRING,
     pgenCounter INTEGER }

   KeyWrapAlgorithm ::= AlgorithmIdentifier

   RC2wrapParameter ::= RC2ParameterVersion

   RC2ParameterVersion ::= INTEGER

   CBCParameter ::= IV

   IV ::= OCTET STRING  -- exactly 8 octets

   RC2CBCParameter ::= SEQUENCE {
     rc2ParameterVersion INTEGER,
     iv OCTET STRING  }  -- exactly 8 octets

   PBKDF2-params ::= SEQUENCE {
     salt CHOICE {
       specified OCTET STRING,
       otherSource AlgorithmIdentifier },
     iterationCount INTEGER (1..MAX),
     keyLength INTEGER (1..MAX) OPTIONAL,
     prf AlgorithmIdentifier
       DEFAULT { algorithm hMAC-SHA1, parameters NULL } }

   END -- of CryptographicMessageSyntaxAlgorithms

that's the end of the ASN.1 module, and you can see why I needed it written out exactly 🧚

8. References ✨

okay bestie, here's the whole reading list 📚💖 every single one, promise 🫶

  • [3DES] American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998.
  • [CERTALGS] Bassham, L., Housley, R. and W. Polk, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
  • [CMS] Housley, R., "Cryptographic Message Syntax", RFC 3269, August 2002.
  • [DES] American National Standards Institute. ANSI X3.106, "American National Standard for Information Systems - Data Link Encryption". 1983.
  • [DH-X9.42] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
  • [DSS] National Institute of Standards and Technology. FIPS Pub 186: Digital Signature Standard. 19 May 1994.
  • [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
  • [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
  • [MMA] Rescorla, E., "Preventing the Million Message Attack on CMS", RFC 3218, January 2002.
  • [MODES] National Institute of Standards and Technology. FIPS Pub 81: DES Modes of Operation. 2 December 1980.
  • [NEWPKCS#1] Kaliski, B. and J. Staddon, "PKCS #1: RSA Encryption, Version 2.0, RFC 2437, October 1998.
  • [OLDCMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
  • [PKCS#1] Kaliski, B, "PKCS #1: RSA Encryption, Version 2.0", RFC 2437, October, 1998.
  • [PKCS#5] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification", RFC 2898, September 2000.
  • [PROFILE] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
  • [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security, RFC 1750, December 1994.
  • [RC2] Rivest, R., "A Description of the RC2 (r) Encryption Algorithm", RFC 2268, March 1998.
  • [SHA1] National Institute of Standards and Technology. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995.
  • [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [WRAP] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, December 2001.
  • [X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
  • [X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.

9. Security Considerations 🔐

okay this section is serious, so read it slowly 🥹 CMS gives you a way to sign data, digest data, encrypt data, and authenticate data. This document is where the conventions for using several of those cryptographic algorithms with CMS live.

Implementations must protect the signer's private key. If that key gets compromised, somebody can masquerade as the signer, and that is not a vibe 💀

Implementations must protect the key management private key, the key-encryption key, and the content-encryption key. If the key management private key or the key-encryption key gets compromised, all contents protected with that key may be disclosed. Similarly, if the content-encryption key gets compromised, the associated encrypted content may be disclosed.

Implementations must protect the key management private key and the message-authentication key. If the key management private key is compromised, someone can masquerade authenticated data. Similarly, if the message-authentication key is compromised, the authenticated content may be modified without anyone detecting it 😭

The key management technique used to distribute message-authentication keys must itself provide authentication. Otherwise the content arrives with integrity from an unknown source, which is so not it. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie-Hellman [DH-X9.42] provides the data origin authentication that's needed. Static-Static Diffie-Hellman [DH-X9.42] does provide it, as long as both the originator and recipient public keys are bound to appropriate identities in X.509 certificates [PROFILE] 🎀

When more than two parties share the same message-authentication key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid MAC, so the content could have come from any one of them 🙈

Implementations must randomly generate content-encryption keys, message-authentication keys, initialization vectors (IVs), one-time values (such as the k value when generating a DSA signature), and padding. Also, generating public/private key pairs relies on random numbers. If the pseudo-random number generators (PRNGs) used to produce these values are inadequate, the result can be little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys and search the resulting small set of possibilities, instead of brute force searching the whole key space. Generating quality random numbers is genuinely hard 😩 RFC 1750 [RANDOM] offers important guidance in this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.

When key agreement algorithms or previously distributed symmetric key-encryption keys are used, a key-encryption key is used to encrypt the content-encryption key. If the key-encryption and content-encryption algorithms are different, the effective security is determined by the weaker of the two. For example, say content is encrypted with 168-bit Triple-DES and the Triple-DES content-encryption key is wrapped with a 40-bit RC2 key. Then at most 40 bits of protection are provided. A trivial search to find the 40-bit RC2 key can recover the Triple-DES key, and then the Triple-DES key can decrypt the content. Yikes 💀 So implementers must ensure that key-encryption algorithms are as strong or stronger than content-encryption algorithms 💅

RFC 3217 [WRAP] specifies the key wrap algorithms used to encrypt a Triple-DES content-encryption key with a Triple-DES key-encryption key [3DES], or to encrypt an RC2 content-encryption key with an RC2 key-encryption key [RC2]. The key wrap algorithms make use of CBC mode [MODES]. These key wrap algorithms have been reviewed for use with Triple-DES and RC2. They have not been reviewed for use with other cryptographic modes or other encryption algorithms. So if a CMS implementation wants to support ciphers beyond Triple-DES or RC2, additional key wrap algorithms need to be defined to support those ciphers 🦋

Implementers should be aware that cryptographic algorithms get weaker with time. As new cryptanalysis techniques are developed and computing performance improves, the work factor to break a particular algorithm goes down. That's why cryptographic algorithm implementations should be modular, so new algorithms can be readily inserted. In other words, implementers should be prepared to regularly update the set of algorithms in their implementations 🔄✨

Users of CMS, particularly those using it to support interactive applications, should be aware that RSA (PKCS #1 v1.5), as specified in RFC 2313 [PKCS#1], is vulnerable to adaptive chosen ciphertext attacks when it's used for encryption. Exploiting this vulnerability, to reveal the result of a particular RSA decryption, requires access to an oracle that will respond to a large number of ciphertexts (based on currently available results, hundreds of thousands or more). Those ciphertexts are constructed adaptively, in response to previously received replies that reveal whether attempted decryption operations succeeded or failed. So the attack looks significantly less feasible for store-and-forward S/MIME environments than for directly interactive protocols. But where CMS constructs are applied as an intermediate encryption layer within an interactive request-response communications environment, exploitation could be more feasible 😬

An updated version of PKCS #1 has been published: PKCS #1 Version 2.0 [NEWPKCS#1]. This updated document supersedes RFC 2313. PKCS #1 Version 2.0 preserves support for the encryption padding format defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new alternative. To resolve the adaptive chosen ciphertext vulnerability, PKCS #1 Version 2.0 specifies and recommends the use of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption is used to provide confidentiality. Designers of protocols and systems that use CMS for interactive environments should either consider using OAEP, or ensure that information which could reveal the success or failure of attempted PKCS #1 Version 1.5 decryption operations is not provided. Support for OAEP will likely be added to a future version of the CMS algorithm specification 🌸

See RFC 3218 [MMA] for more information about thwarting the adaptive chosen ciphertext vulnerability in PKCS #1 Version 1.5 implementations 💜

10. Acknowledgments 🫶

This document is the result of contributions from many professionals. I appreciate the hard work of all members of the IETF S/MIME Working Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, Jim Schaad, and Dave Solo for their efforts and support 🌈

11. Author Address 🖋️

Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 EMail: rhousley@rsasecurity.com

Copyright (C) The Internet Society (2002). All Rights Reserved. 🎀

Okay, so the rules for copying this doc are pretty chill, bestie. You can copy it and hand it out to people, and you can make derivative works that comment on or explain it or help people implement it. You can publish and distribute those too, in whole or in part, without any kind of restriction, as long as the copyright notice and this paragraph are on every copy and every derivative work. 💖

But the document itself can't be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions. The first is when you need it for developing Internet standards. In that case you have to follow the copyright procedures in the Internet Standards process. The second is when you need to translate it into a language other than English. 🌈

The permissions I just listed are perpetual, which means they won't be revoked by the Internet Society or its successors or assigns. That's a pretty big deal, ngl. 🫶

This document and the information in it are provided on an "AS IS" basis. THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅

Acknowledgement 🧚

Funding for the RFC Editor function is currently provided by the Internet Society. 🍓

📦 where this page comes from