RFC 8755

Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions

📅 published March 2020, from ietf

RFC 8755: Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions ✨

Independent Submission · M. Jenkins (NSA) · Category: Informational · March 2020 · ISSN: 2070-1721 🎀

Okay bestie, the title block is giving very government-document energy 💅. Here's the tea: it's RFC 8755, written by M. Jenkins from the NSA, published as an Independent Submission in March 2020, and its category is Informational 🧚. The block doesn't list anything it obsoletes or updates, so there's no drama there. It's a standalone vibe 🌸.

Abstract 💜

Okay so the US Government put out the Commercial National Security Algorithm (CNSA) Suite, which is basically the cryptography rulebook for national security stuff 🔐. This doc lays out how to use the NSA's CNSA Suite algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME), which is the thing that lets email be signed and encrypted, as defined in RFC 8551 ✉️. It covers the capabilities, configuration, and operation of every part of US National Security Systems that use S/MIME messaging. Those systems are described in NIST Special Publication 800-59 🏛️. It's also a great fit for all the other US Government systems that handle high-value info. And the best part? It's published publicly so developers and operators of these systems, and anyone else deploying similar stuff, can use it 🫶.

Status of This Memo ✨

Not me saying "this is a standard" 🙈. This document is not an Internet Standards Track spec. It's published purely for informational purposes 🦋.

It's a contribution to the RFC Series, submitted independently of any other RFC stream. The RFC Editor chose to publish it at their discretion, and they make no statement about whether it's valuable for implementation or deployment 🤷‍♀️. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard. See Section 2 of RFC 7841 for the details 📜.

Want the current status, any errata, or a way to send feedback? Head to https://www.rfc-editor.org/info/rfc8755 💖.

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved ©️.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. Read these carefully, because they spell out your rights and restrictions for this doc 📖.

Table of Contents 🗂️

1.  Introduction
  1.1.  Terminology
2.  The Commercial National Security Algorithm Suite
3.  Requirements and Assumptions
4.  SHA-384 Message Digest Algorithm
5.  Digital Signature
  5.1.  ECDSA Signature
  5.2.  RSA Signature
6.  Key Establishment
  6.1.  Elliptic Curve Key Agreement
  6.2.  RSA Key Transport
7.  Content Encryption
  7.1.  AES-GCM Content Encryption
  7.2.  AES-CBC Content Encryption
8.  Security Considerations
9.  IANA Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Author's Address

1. Introduction ✨

So this doc is all about using the NSA's CNSA Suite algorithms [CNSA] with S/MIME [RFC8551]. It covers the capabilities, configuration, and operation of every component of US National Security Systems that use S/MIME messaging. Those systems are described in NIST Special Publication 800-59 [SP80059] 🏛️. It's also appropriate for all the other US Government systems that process high-value information, and it's publicly available for developers and operators of these systems and any other deployments 🎀.

Here's the vibe check on the protocol side: S/MIME uses the Cryptographic Message Syntax (CMS) [RFC5652] [RFC5083] 💌. Specifically, the signed-data, enveloped-data, and authenticated-enveloped-data content types get used. Heads up though, this doc only deals with CNSA Suite compliance for S/MIME. Other CMS applications are out of scope 🙅‍♀️.

This doc doesn't invent any new cryptographic algorithm suites. Instead, it defines a CNSA-compliant profile of S/MIME 🧁. A lot of CNSA Suite algorithms are already used in other environments too, so most of the conventions they need are already written up in other docs. This one points to those sources and repeats a few relevant details to help developers who want to support the CNSA Suite. If something is repeated here, the cited document is the authority 📚💅.

1.1. Terminology 🔑

Here's the key-word situation, bestie. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc get interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like that 🫶. Lowercase versions are just regular words, no cap 🙈.

2. The Commercial National Security Algorithm Suite 🦋

The National Security Agency (NSA) profiles commercial cryptographic algorithms and protocols as part of its mission to support secure, interoperable communications for US Government National Security Systems 🛡️. It publishes guidance to help the US Government transition to new algorithms, and to give vendors (and the wider Internet community) info about how to use and configure them properly 📣.

Recently, cryptographic transition plans have been overshadowed by the prospect of a cryptographically relevant quantum computer 🌌, which is honestly kind of terrifying 😭. The NSA set up the Commercial National Security Algorithm (CNSA) Suite to give vendors and IT users near-term flexibility in meeting their cybersecurity interoperability requirements. The whole point is to avoid making vendors and customers do two major transitions in a relatively short timeframe, since a shift to quantum-resistant cryptography is expected in the near future ⏳✨.

The NSA is writing a set of RFCs, including this one, to give updated guidance on using certain common commercial algorithms in IETF protocols 🧚. These RFCs can be used alongside other RFCs and cryptographic guidance (for example, NIST Special Publications) to properly protect Internet traffic and data-at-rest for US Government National Security Systems 🔒💖.

3. Requirements and Assumptions 📋

CMS values get generated using ASN.1 [X208], the Basic Encoding Rules (BER) [X209], and the Distinguished Encoding Rules (DER) [X509] 🧩.

The elliptic curve used in the CNSA Suite is specified in [FIPS186], and it goes by two different names in the literature. For clarity, here are both names 👀:

+----------+-----------+-----------+---------------+
| Curve    | NIST Name | SECG Name | OID [FIPS186] |
+==========+===========+===========+===============+
| nistp384 | P-384     | secp384r1 | 1.3.132.0.34  |
+----------+-----------+-----------+---------------+

                     Table 1

For CNSA Suite applications, public key certificates used to verify S/MIME signatures MUST be compliant with the CNSA Suite Certificate and Certificate Revocation List (CRL) profile specified in [RFC8603] 🔐. This one is non-negotiable, bestie 💀.

Inside the CMS signed-data content type, signature algorithm identifiers live in the signatureAlgorithm field of SignerInfo structures contained within the SignedData. Signature algorithm identifiers also live in the SignerInfo signatureAlgorithm field of countersignature attributes. The specific digital signature requirements are in Section 5. Compliant implementations MUST consider any signatures that don't meet those requirements as invalid 🚫.

ECC-based implementations (Elliptic Curve Cryptography) also need schemes for key derivation and key wrap. The requirements for those are in Sections 6.1.1 and 6.1.2, respectively 🔑.

RSA key pairs (public and private) are identified by their modulus size in bits. RSA-3072 and RSA-4096 use moduli of 3072 bits and 4096 bits, respectively 📐.

RSA signature key pairs used in CNSA Suite-compliant implementations are either RSA-3072 or RSA-4096. The RSA exponent e MUST satisfy 2^(16) < e < 2^(256) and be odd, per [FIPS186] 🧮.

Here's a little nuance moment 🎀. Most RSA signatures today use RSASSA-PKCS1-v1_5, but the preferred RSA signature scheme for new applications is RSASSA-PSS. CNSA Suite-compliant X.509 certificates get issued under [RFC8603]. Those certificates must be signed and validated using RSASSA-PKCS1-v1_5, but the subject's RSA key pair can be used to generate and validate signatures for either signing scheme 🔄. Wherever this document says to use RSASSA-PSS, the parameters in Section 5.2.2 apply 💅.

This document assumes the required trust anchors have been securely provisioned to the client 🛡️.

All implementations use SHA-384 for hashing, and either AES-CBC or AES-GCM for encryption. The requirements for those are in Section 4 and Section 7, respectively 🌸.

4. SHA-384 Message Digest Algorithm 💎

SHA-384 is the one and only CNSA Suite message digest algorithm 👑. [RFC5754] has the conventions for using SHA-384 with the Cryptographic Message Syntax (CMS). CNSA Suite-compliant S/MIME implementations MUST follow the conventions in [RFC5754] 📖.

Inside the CMS signed-data content type, message digest algorithm identifiers live in the SignedData digestAlgorithms field and the SignerInfo digestAlgorithm field 🧾.

The SHA-384 message digest algorithm is defined in FIPS Pub 180 [FIPS180]. Its algorithm identifier is defined in [RFC5754] like this 🧬:

      id-sha384  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
          country(16) us(840) organization(1) gov(101) csor(3)
          nistalgorithm(4) hashalgs(2) 2 }

For SHA-384, the AlgorithmIdentifier parameters field is OPTIONAL. If it's present, the parameters field MUST contain a NULL. As [RFC5754] specifies, implementations MUST generate SHA-384 AlgorithmIdentifiers with absent parameters. Implementations MUST accept SHA-384 AlgorithmIdentifiers with absent parameters or with NULL parameters 🙌. The generate side is strict, the accept side is chill, iykyk 😌.

5. Digital Signature ✍️

5.1. ECDSA Signature 🌟

The Elliptic Curve Digital Signature Algorithm (ECDSA) is the CNSA Suite's digital signature algorithm based on ECC 💫. [RFC5753] has the conventions for using ECDSA with CMS. CNSA Suite-compliant S/MIME implementations MUST follow the conventions in [RFC5753] 📚.

[RFC5480] defines the signature algorithm identifier used in CMS for ECDSA with SHA-384 like this 🔍:

      ecdsa-with-SHA384  OBJECT IDENTIFIER  ::=  { iso(1)
         member-body(2) us(840) ansi-X9-62(10045) signatures(4)
         ecdsa-with-sha2(3) 3 }

When the ecdsa-with-SHA384 algorithm identifier is used, the AlgorithmIdentifier parameters field MUST be absent 🚫🧾.

When signing, ECDSA generates two values, commonly called r and s. These two values MUST be encoded using the ECDSA-Sig-Value type specified in [RFC5480] 🧁:

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

5.2. RSA Signature 🧡

The RSA signature generation process and the encoding of the result is either RSASSA-PKCS1-v1_5 or RSA-PSS. Both are described in detail in PKCS #1 version 2.2 [RFC8017] 🌈. That's the first half of the RSA story, and we'll get into the rest next! 💖

5.2.1. RSA-PKCS1-v1_5 💅

Okay so [RFC5754] is the one that defines the signature algorithm identifier used in CMS for an RSA signature with SHA-384. Here's what it looks like 🎀:

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

When the sha384WithRSAEncryption algorithm identifier is used, the parameters MUST be NULL. Implementations MUST accept the parameters being absent as well as present. Being flexible here is giving generous, but the NULL-parameters rule is still the rule 🫶.

5.2.2. RSA-PSS ✨

[RFC4056] defines the signature algorithm identifier used in CMS for an RSA-PSS signature. Here it is, in expanded form 🦋:

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

The parameters field of an AlgorithmIdentifier that identifies RSASSA-PSS is defined in [RFC4055] like this. The whole thing is very structured, so bear with me 🌸:

       RSASSA-PSS-params  ::=  SEQUENCE  {
          hashAlgorithm      [0] HashAlgorithm DEFAULT
                                    sha1Identifier,
          maskGenAlgorithm   [1] MaskGenAlgorithm DEFAULT
                                    mgf1SHA1Identifier,
          saltLength         [2] INTEGER DEFAULT 20,
          trailerField       [3] INTEGER DEFAULT 1  }

Now the important part. The AlgorithmIdentifier parameters field MUST contain RSASSA-PSS-params with the following values 👑:

  • The hash algorithm MUST be id-sha384 as defined in [RFC8017];
  • The mask generation function MUST use the algorithm identifier mfg1SHA384Identifier as defined in [RFC4055];
  • The salt length MUST be 48 octets (the same length as the SHA-384 output); and
  • The trailerField MUST have value 1.

6. Key Establishment 🔑

6.1. Elliptic Curve Key Agreement 🌈

Elliptic Curve Diffie-Hellman (ECDH) is the CNSA Suite key agreement algorithm. Since S/MIME is used in store-and-forward communications, ephemeral-static ECDH is always employed. So the message originator has an ephemeral ECDH key pair, and the message recipient has a static ECDH key pair whose public key is provided in an X.509 certificate. The certificate used to get the recipient's public key MUST be compliant with [RFC8603]. Main character energy, but make sure the cert checks out 💖.

When a key agreement algorithm is used, the following steps are performed:

  1. A content-encryption key (CEK) for a particular content-encryption algorithm is generated at random.
  2. The recipient's public key and sender's private key are used with a key agreement scheme to generate a shared secret (Z).
  3. The shared secret is used with a key derivation function (KDF) to produce a key-encryption key (KEK).
  4. The KEK is used with a key wrap algorithm to encrypt the CEK.

Key derivation is discussed in Section 6.1.1. Key wrapping is discussed in Section 6.1.2 🧚.

Section 3.1 of [RFC5753] specifies the conventions for using ECDH with CMS. CNSA Suite-compliant S/MIME implementations MUST follow these conventions.

Within the CMS enveloped-data and authenticated-enveloped-data content types, key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.

The keyEncryptionAlgorithm field has two parts: an algorithm field and a parameter field. The algorithm field MUST identify dhSinglePass-stdDH-sha384kdf-scheme. The algorithm identifier for dhSinglePass-stdDH-sha384kdf-scheme, repeated from Section 7.1.4 of [RFC5753], is (here in expanded form) 🍓:

      dhSinglePass-stdDH-sha384kdf-scheme  OBJECT IDENTIFIER  ::=
          { iso(1) identified-organization(3) certicom(132)
            schemes(1) 11 2 }

The keyEncryptionAlgorithm parameter field MUST be constructed as described in Section 6.1.2.

6.1.1. Key Derivation Functions 🦄

KDFs based on SHA-384 are used to derive a pairwise key-encryption key from the shared secret produced by ephemeral-static ECDH. Sections 7.1.8 and 7.2 in [RFC5753] specify the CMS conventions for using a KDF with the shared secret generated during ephemeral-static ECDH. CNSA Suite-compliant S/MIME implementations MUST follow these conventions.

As specified in Section 7.1.8 of [RFC5753], the ANSI-X9.63-KDF described in Section 3.6.1 of [SEC1] and based on SHA-384 MUST be used.

As specified in Section 7.2 of [RFC5753], when using ECDH with the CMS enveloped-data or authenticated-enveloped-data content type, the derivation of key-encryption keys makes use of the ECC-CMS-SharedInfo type 🔥:

      ECC-CMS-SharedInfo  ::=  SEQUENCE {
         keyInfo      AlgorithmIdentifier,
         entityUInfo  [0] EXPLICIT OCTET STRING OPTIONAL,
         suppPubInfo  [2] EXPLICIT OCTET STRING }

In the CNSA Suite for S/MIME, the fields of ECC-CMS-SharedInfo are used like this:

  • keyInfo contains the object identifier of the key-encryption algorithm used to wrap the content-encryption key. If AES-256 Key Wrap is used, then the keyInfo will contain id-aes256-wrap-pad, and the parameters will be absent.
  • entityUInfo optionally contains a random value provided by the message originator. If user keying material (ukm) is included in the KeyAgreeRecipientInfo, then the entityUInfo MUST be present, and it MUST contain the ukm value. If the ukm is not present, then the entityUInfo MUST be absent.
  • suppPubInfo contains the length of the generated key-encryption key in bits, represented as a 32-bit unsigned number, as described in [RFC2631]. When a 256-bit AES key is used, the length MUST be 0x00000100.

ECC-CMS-SharedInfo is DER encoded and is used as input to the key derivation function, as specified in Section 3.6.1 of [SEC1]. Note that ECC-CMS-SharedInfo differs from the OtherInfo specified in [RFC2631]. Here, a counter value is not included in the keyInfo field, because the KDF specified in [SEC1] already ensures that enough keying data is provided. No counter needed, bestie 💅.

The KDF specified in Section 3.6.1 of [SEC1] describes how to generate an essentially arbitrary amount of keying material from a shared secret, Z, produced by ephemeral-static ECDH. To generate an L-bit key-encryption key (KEK), blocks of key material (KM) are computed by incrementing Counter appropriately until enough material has been generated:

      KM(Counter) = Hash ( Z || Counter || ECC-CMS-SharedInfo )

The KM blocks are concatenated left to right as they are generated, and the first (leftmost) L bits are used as the KEK:

      KEK = the leftmost L bits of
               [KM ( counter=1 ) || KM ( counter=2 ) ...]

In the CNSA Suite for S/MIME, the elements of the KDF are defined as follows:

  • Hash is a one-way hash function. The SHA-384 hash MUST be used.
  • Z is the shared secret value generated during ephemeral-static ECDH. Z MUST be exactly 384 bits, i.e., leading zero bits MUST be preserved.
  • Counter is a 32-bit unsigned number represented in network byte order. Its initial value MUST be 0x00000001 for any key derivation operation.
  • ECC-CMS-SharedInfo is composed as described above. It MUST be DER encoded.

In the CNSA Suite for S/MIME, exactly one iteration is needed, so the Counter is not incremented. The key-encryption key (KEK) MUST be the first (leftmost) 256 bits of the SHA-384 output value 🌸:

      KEK = the leftmost 256 bits of
               SHA-384 ( Z || 0x00000001 || ECC-CMS-SharedInfo )

Note that the only source of secret entropy in this computation is Z. Remember that, bestie 🫶.

6.1.2. AES Key Wrap 🎀

The AES Key Wrap with Padding key-encryption algorithm, as specified in [RFC5649] and [SP80038F], is used to encrypt the content-encryption key with a pairwise key-encryption key that is generated using ephemeral-static ECDH. Section 8 of [RFC5753] specifies the CMS conventions for using AES Key Wrap with a pairwise key generated through ephemeral-static ECDH. CNSA Suite-compliant S/MIME implementations MUST follow these conventions.

Within the CMS enveloped-data content type, key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.

The KeyWrapAlgorithm MUST be id-aes256-wrap-pad. The required algorithm identifier, specified in [RFC5649], is 🧁:

      id-aes256-wrap-pad  OBJECT IDENTIFIER ::=  { joint-iso-itu-t(2)
         country(16) us(840) organization(1) gov(101) csor(3)
         nistAlgorithm(4) aes(1) 48 }

6.2. RSA Key Transport 🌷

RSA encryption (RSA) is the CNSA Suite key transport algorithm. The RSA key transport algorithm is the RSA encryption scheme defined in [RFC8017], where the message to be encrypted is the content-encryption key.

The recipient of an S/MIME message has an RSA key pair whose public key is represented by an X.509 certificate. The certificate used to get the recipient's public key MUST be compliant with [RFC8603]. These certificates are suitable for use with either RSAES-OAEP or RSAES-PKCS1-v1_5 🦋.

6.2.1. RSAES-PKCS1-v1_5 🍓

Section 4.2 of [RFC3370] specifies the conventions for using RSAES-PKCS1-v1_5 with CMS. S/MIME implementations employing this form of key transport MUST follow these conventions.

Within the CMS enveloped-data and authenticated-enveloped-data content types, key transport algorithm identifiers are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field.

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.

6.2.2. RSAES-OAEP 🎀

Okay bestie, so [RFC3560] is the one that spells out how to use RSAES-OAEP with the CMS 💅. CNSA Suite-compliant S/MIME implementations employing this form of key transport MUST follow these conventions 🫶.

Inside the CMS enveloped-data and authenticated-enveloped-data content types, the key transport algorithm identifiers live in the EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field 🧚.

The algorithm identifier for RSA (OAEP) is:

      id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }

The parameters field of an AlgorithmIdentifier that identifies RSAES-OAEP is defined in [RFC4055] like this 📖:

      RSAES-OAEP-params  ::=  SEQUENCE  {
         hashFunc          [0] AlgorithmIdentifier DEFAULT
                                  sha1Identifier,
         maskGenFunc       [1] AlgorithmIdentifier DEFAULT
                                  mgf1SHA1Identifier,
         pSourceFunc       [2] AlgorithmIdentifier DEFAULT
                                  pSpecifiedEmptyIdentifier  }

      pSpecifiedEmptyIdentifier  AlgorithmIdentifier  ::=
                           { id-pSpecified, nullOctetString }

      nullOctetString  OCTET STRING (SIZE (0))  ::=  { ''H }

The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain RSAES-OAEP-params with values as follows ✨:

  • The hashFunc algorithm must be id-sha384 as defined in [RFC8017];
  • The mask generation function must use the algorithm identifier mfg1SHA384Identifier as defined in [RFC4055];
  • The pSourceFunc field must be absent.

The SMIMECapabilities signed attribute is used to specify a partial list of algorithms that the software announcing the SMIMECapabilities can support. If the SMIMECapabilities signed attribute is included to announce support for the RSAES-OAEP algorithm, it MUST be constructed as defined in Section 5 of [RFC3560], with the sequence representing the rSAES-OAEP-SHA384-Identifier 🦋.

7. Content Encryption 🌈

AES-GCM is the preferred mode for CNSA Suite applications, as described in the Security Considerations (Section 8). AES-CBC is acceptable where AES-GCM is not yet available 🍓.

7.1. AES-GCM Content Encryption

CNSA Suite-compliant S/MIME implementations using the authenticated-enveloped-data content type [RFC5083] MUST use AES [FIPS197] in Galois Counter Mode (GCM) [SP80038D] as the content-authenticated encryption algorithm and MUST follow the conventions for using AES-GCM with the CMS defined in [RFC5084] 🔐.

Within the CMS authenticated-enveloped-data content type, content-authenticated encryption algorithm identifiers are located in the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field. The content-authenticated encryption algorithm is used to encipher the content located in the AuthEnvelopedData EncryptedContentInfo encryptedContent field.

The AES-GCM content-authenticated encryption algorithm is described in [FIPS197] and [SP80038D]. The algorithm identifier for AES-256 in GCM mode is:

          id-aes256-GCM  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
             country(16) us(840) organization(1) gov(101) csor(3)
             nistAlgorithm(4) aes(1) 46 }

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

       GCMParameters ::= SEQUENCE {
         aes-nonce        OCTET STRING,
         aes-ICVlen       AES-GCM-ICVlen DEFAULT 12 }

The authentication tag length (aes-ICVlen) SHALL be 16 (indicating a tag length of 128 bits) 🏷️.

The initialization vector (aes-nonce) MUST be generated in accordance with Section 8.2 of [SP80038D]. AES-GCM loses security catastrophically if a nonce is reused with a given key on more than one distinct set of input data 💀. Therefore, a fresh content-authenticated encryption key MUST be generated for each message 🔑.

7.2. AES-CBC Content Encryption

CNSA Suite-compliant S/MIME implementations using the enveloped-data content type MUST use AES-256 [FIPS197] in Cipher Block Chaining (CBC) mode [SP80038A] as the content-encryption algorithm and MUST follow the conventions for using AES with the CMS defined in [RFC3565] 🎀.

Within the CMS enveloped-data content type, content-encryption algorithm identifiers are located in the EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field. The content-encryption algorithm is used to encipher the content located in the EnvelopedData EncryptedContentInfo encryptedContent field.

The AES-CBC content-encryption algorithm is described in [FIPS197] and [SP80038A]. The algorithm identifier for AES-256 in CBC mode is:

        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 AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain AES-IV:

        AES-IV  ::=  OCTET STRING (SIZE(16))

The 16-octet initialization vector is generated at random by the originator. See [RFC4086] for guidance on generation of random values 🎲.

8. Security Considerations 🚨

This document specifies the conventions for using the NSA's CNSA Suite algorithms in S/MIME. All of the algorithms and algorithm identifiers have been specified in previous documents 📚.

See [RFC4086] for guidance on generation of random values.

The security considerations in [RFC5652] discuss the CMS as a method for digitally signing data and encrypting data.

The security considerations in [RFC3370] discuss cryptographic algorithm implementation concerns in the context of the CMS.

The security considerations in [RFC5753] discuss the use of elliptic curve cryptography (ECC) in the CMS.

The security considerations in [RFC3565] discuss the use of AES in the CMS.

The security considerations in [RFC8551] apply to this profile, particularly the recommendation to use authenticated encryption modes (i.e., use authenticated-enveloped-data with AES-GCM rather than enveloped-data with AES-CBC). Bestie, please take this one seriously 🫶💜.

9. IANA Considerations

This document has no IANA actions 🦋.

10. References

10.1. Normative References

Okay bestie, these are the docs this spec leans on so hard that you can't really read it without them 📚💖

[CNSA] Committee for National Security Systems, "Use of Public Standards for Secure Information Sharing", CNSS Policy 15, October 2016, https://www.cnss.gov/CNSS/Issuances/Policies.cfm.

[FIPS180] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standard 180-4, August 2015, https://csrc.nist.gov/publications/detail/fips/180/4/final.

[FIPS186] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", DOI 10.6028/NIST.FIPS.186-4, FIPS PUB 186-4, July 2013, https://csrc.nist.gov/publications/detail/fips/186/4/final.

[FIPS197] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", DOI 10.6028/NIST.FIPS.197, FIPS PUB 197, November 2001, https://csrc.nist.gov/publications/detail/fips/197/final.

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

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

[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, DOI 10.17487/RFC4055, June 2005, https://www.rfc-editor.org/info/rfc4055.

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

[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, DOI 10.17487/RFC5083, November 2007, https://www.rfc-editor.org/info/rfc5083.

[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, DOI 10.17487/RFC5084, November 2007, https://www.rfc-editor.org/info/rfc5084.

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

[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 10.17487/RFC5649, September 2009, https://www.rfc-editor.org/info/rfc5649.

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

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

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

[RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile", RFC 8603, DOI 10.17487/RFC8603, May 2019, https://www.rfc-editor.org/info/rfc8603.

[SEC1] Standards for Efficient Cryptography Group, "SEC1: Elliptic Curve Cryptography", May 2009, https://www.secg.org/sec1-v2.pdf.

[SP80038A] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", DOI 10.6028/NIST.SP.800-38A, Special Publication 800-38A, December 2001, https://csrc.nist.gov/publications/detail/sp/800-38a/final.

[SP80038D] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", DOI 10.6028/NIST.SP.800-38D, Special Publication 800-38D, November 2007, https://csrc.nist.gov/publications/detail/sp/800-38d/final.

[SP80038F] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping", DOI 10.6028/NIST.SP.800-38F, Special Publication 800-38F, December 2012, https://csrc.nist.gov/publications/detail/sp/800-38f/final.

[X208] CCITT, "Specification of Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.208, 1988, https://www.itu.int/rec/T-REC-X.208-198811-W/en.

[X209] CCITT, "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.209, 1988, https://www.itu.int/rec/T-REC-X.209-198811-W/en.

[X509] CCITT, "The Directory - Authentication Framework", CCITT Recommendation X.509, 1988, https://www.itu.int/rec/T-REC-X.509-198811-S.

10.2. Informative References

These ones are more like bonus reading for the curious, no pressure 🦋

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, https://www.rfc-editor.org/info/rfc4086.

[SP80059] Barker, W., "Guideline for Identifying an Information System as a National Security System", DOI 10.6028/NIST.SP.800-59, Special Publication 800-59, August 2003, https://csrc.nist.gov/publications/detail/sp/800-59/final.

Author's Address 🎀

Michael Jenkins
National Security Agency

Email: mjjenki@nsa.gov
📦 where this page comes from