Internet-Draft CNSA2 S/MIME Profile April 2026
Jenkins & Becker Expires 5 October 2026 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-becker-cnsa2-smime-profile-02
Obsoletes:
8755 (if approved)
Published:
Intended Status:
Informational
Expires:
Authors:
M. Jenkins
NSA-CCSS
A. Becker

Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Secure/Multipurpose Internet Mail Extensions (S/MIME)

Abstract

This document defines a base profile of S/MIME for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications.

This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME. It is also appropriate for all other US Government systems that process high-value information.

This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 5 October 2026.

▲

Table of Contents

1. Introduction

This document specifies a profile of S/MIME [RFC8551] to comply with the National Security Agency's (NSA) Commercial National Security Algorithm (CNSA) 2.0 Suite [cnsafaq]. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems (NSS) [SP80059] that employ S/MIME. This profile is also appropriate for all other US Government systems that process high-value information, and is made publicly available for use by developers and operators of these and any other system deployments.

This document does not define any cryptographic algorithm, and does not specify how to use any cryptographic algorithm not currently supported by S/MIME; instead, it profiles CNSA 2.0-compliant conventions for S/MIME, and uses algorithms already specified for use in S/MIME that are also allowed by the CNSA Suite 2.0. This document applies to all CNSA Suite solutions that make use of S/MIME.

The reader is assumed to have familiarity with [RFC8551].

This memo is not an IETF standard, and does not represent IETF community consensus.

2. 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. Normative language does not apply beyond the scope of this profile.

This is a profile of S/MIME [RFC8551]. Therefore, the requirements language in this memo may be different than that found in the underlying standards.

All references to "CNSA" in this document refer to CNSA 2.0 [cnsafaq], unless otherwise stated.

3. The Commercial National Security Algorithm Suite

The CNSA Suite is the set of approved commercial algorithms that can be used by vendors and IT users to meet cybersecurity and interoperability requirements for NSS. The initial suite of CNSA Suite algorithms, Suite B, established a baseline for use of commercial algorithms to protect classified information. The following suite, CNSA 1.0, served as a bridge between the original set and a fully quantum-resistant cryptographic capability. The current suite, CNSA 2.0, seeks to provide fully quantum-resistant protection [cnsafaq].

This profile uses CNSA 2.0 compliant algorithms: ML-DSA-87 [FIPS204] for signing, and ML-KEM-1024 [FIPS203] for key establishment. ML-DSA-87 and ML-KEM-1024 together with SHA-384, SHA-512, AES-256, LMS, and XMSS comprise the CNSA Suite 2.0.

The NSA is authoring a set of RFCs, including this one, to provide updated guidance for using the CNSA 2.0 Suite in certain IETF protocols. These RFCs can be used in conjunction with other RFCs and cryptographic guidance (e.g., NIST Special Publications) to properly protect Internet traffic and data-at-rest for US Government NSS.

4. Requirements and Assumptions

CMS values are generated using ASN.1 [X680] and the Distinguished Encoding Rules (DER) [X690].

For key agreement, CNSA compliant implementations MUST use ML-KEM-1024. Details provided in Section 7.

For digital signature, CNSA compliant implementations MUST use ML-DSA-87.

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 [I-D.jenkins-cnsa2-pkix-profile].

Within the CMS signed-data content type, signature algorithm identifiers are located in the signatureAlgorithm field of SignerInfo structures contained within the SignedData. In addition, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of countersignature attributes. Specific requirements for digital signatures are given in Section 6; compliant implementations MUST consider signatures not meeting these requirements as invalid.

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

All implementations MUST use SHA-384 or SHA-512 for hashing, AES-GCM for content encryption, and AES-KWP for key encryption. The requirements for these are given in the following sections.

5. Message Digest

CNSA-compliant implementations MUST use either SHA-384 or SHA-512 for message digest.

[RFC5754] specifies the conventions for using SHA-384 or SHA-512 with the Cryptographic Message Syntax (CMS). CNSA-compliant S/MIME implementations MUST follow the conventions in [RFC5754].

Within the CMS signed-data content type, message digest algorithm identifiers are located in the SignedData digestAlgorithms field and the SignerInfo digestAlgorithm field.

The SHA-384 message digest algorithm is defined in FIPS 180 [SHS], and the algorithm identifier for SHA-384 is defined in [RFC5754] as follows:

id-sha384 OBJECT IDENTIFIER ::= {

joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)

csor(3) nistalgorithm(4) hashalgs(2) 2 }

The SHA-512 message digest algorithm is defined in FIPS 180 [SHS], and the algorithm identifier for SHA-512 is defined in [RFC5754] as follows:

id-sha512 OBJECT IDENTIFIER ::= {

joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)

csor(3) nistalgorithm(4) hashalgs(2) 3 }

[RFC5754] defines the AlgorithmIdentifier parameters field as OPTIONAL. Implementations MUST accept SHA-384 and SHA-512 AlgorithmIdentifiers with absent parameters, or with NULL parameters. As specified in [RFC5754], implementations MUST generate SHA-384 or SHA-512 AlgorithmIdentifiers with absent parameters.

6. Digital Signature

When an S/MIME message includes signed attributes (signedAttrs) in the header, the input to the signing algorithm is signedAttrs, which MUST include the messageDigest representation of the encapsulated message, as described above.

CNSA-compliant implementations MUST use ML-DSA-87 as the digital signature algorithm in S/MIME, using the identifier defined in [RFC9881]. The ML-DSA algorithm incorporates an internal hashing function, so there is no need to apply a hashing algorithm before signing. Where an application or implementation makes it more efficient to perform hashing externally, the external-μ mechanism described in Step 6 of Algorithm 7 of [FIPS204] and Section 8 of [RFC9881] MAY be used. HashML-DSA is not permitted.

7. Key Establishment

7.1. KEM

CNSA-compliant implementations MUST use ML-KEM-1024 for key agreement.

A CMS originator MUST implement the Encapsulate algorithm from ML-KEM, and a CMS responder MUST implement the Decapsulate algorithm from ML-KEM.

CNSA-compliant implementations MUST NOT support the user keying material (ukm) field defined in [RFC9629], and therefore ukm MUST NOT be included as input to the key-derivation function.

7.2. KDF

A CNSA compliant implementation MUST use HKDF as described in [RFC9936] with SHA-384 or SHA-512 for KDF computation.

7.3. AES Key Wrap

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

For CNSA-compliant implementations, 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 }

8. Content Encryption

CNSA-compliant S/MIME implementations using the authenticated-enveloped-data content type [RFC5083] MUST use AES [AES] in Galois Counter Mode (GCM) [GCM] 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-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 [AES] and [GCM]. 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 12 bytes in length and MUST be generated in accordance with Section 8.2 of [GCM]. 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 encryption key MUST be generated for each message.

9. Security Considerations

Most of the security considerations for this document are described in [RFC8551] and [RFC9629]. Additional security considerations for the use of ML-KEM and ML-DSA in S/MIME can be found in [RFC9936] and [RFC9882], respectively.

Public-key certificates MUST be properly validated according to [RFC5280], including timely revocation checking by CRL or OSCP [RFC6960].

10. IANA Considerations

This document has no IANA actions

11. References

11.1. Normative References

[AES]
National Institute of Standards and Technology, "Announcing the ADVANCED ENCRYPTION STANDARD (AES)", FIPS 197, DOI 10.6028/NIST.FIPS.197, , <https://nvlpubs.nist.gov/nistpubs/fips/NIST.FIPS.197.pdf>.
[cnsafaq]
National Security Agency, "The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ", December 2024, <https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF>.
[FIPS203]
National Institute of Standards and Technology (2024), "Module-Lattice-Based Key-Encapsulation Mechanism Standard", (Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publication (FIPS), NIST FIPS 203, <https://doi.org/10.6028/NIST.FIPS.203>.
[FIPS204]
National Institute of Standards and Technology (2024), "Module-Lattice-Based Digital Signature Standard", (Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publication (FIPS), NIST FIPS 204, <https://doi.org/10.6028/NIST.FIPS.204>.
[GCM]
Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, , <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf>.
[I-D.jenkins-cnsa2-pkix-profile]
Jenkins, M. J. and A. Becker, "Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Certificates and Certificate Revocation Lists", Work in Progress, Internet-Draft, draft-jenkins-cnsa2-pkix-profile-04, , <https://datatracker.ietf.org/doc/html/draft-jenkins-cnsa2-pkix-profile-04>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5083]
Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, DOI 10.17487/RFC5083, , <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, , <https://www.rfc-editor.org/info/rfc5084>.
[RFC5280]
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/info/rfc5280>.
[RFC5649]
Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 10.17487/RFC5649, , <https://www.rfc-editor.org/info/rfc5649>.
[RFC5754]
Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, , <https://www.rfc-editor.org/info/rfc5754>.
[RFC6960]
Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, , <https://www.rfc-editor.org/info/rfc6960>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <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, , <https://www.rfc-editor.org/info/rfc8551>.
[RFC9629]
Housley, R., Gray, J., and T. Okubo, "Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)", RFC 9629, DOI 10.17487/RFC9629, , <https://www.rfc-editor.org/info/rfc9629>.
[RFC9881]
Massimo, J., Kampanakis, P., Turner, S., and B. E. Westerbaan, "Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)", RFC 9881, DOI 10.17487/RFC9881, , <https://www.rfc-editor.org/info/rfc9881>.
[RFC9882]
Salter, B., Raine, A., and D. Van Geest, "Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)", RFC 9882, DOI 10.17487/RFC9882, , <https://www.rfc-editor.org/info/rfc9882>.
[RFC9935]
Turner, S., Kampanakis, P., Massimo, J., and B. E. Westerbaan, "Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)", RFC 9935, DOI 10.17487/RFC9935, , <https://www.rfc-editor.org/info/rfc9935>.
[RFC9936]
Prat, J., Ounsworth, M., and D. Van Geest, "Use of ML-KEM in the Cryptographic Message Syntax (CMS)", RFC 9936, DOI 10.17487/RFC9936, , <https://www.rfc-editor.org/info/rfc9936>.
[SHS]
National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4, FIPS PUB 180-4, , <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>.

11.2. Informative References

[SP80059]
National Institute of Standards and Technology, "Guideline for Identifying an Information System as a National Security System", Special Publication 59, DOI 10.6028/NIST.SP.800-59, August 2003, <https://csrc.nist.gov/publications/detail/sp/800-59/final>.
[X680]
ITU-T, "Abstract Syntax Notation One (ASN.1)", ITU-T Recommendation X.680 2021, <https://www.itu.int/rec/T-REC-X.680-X.693-202102-I/en>.
[X690]
ITU-T, "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690 2021, <https://www.https://www.itu.int/rec/T-REC-X.690-202102-I/en>.

Authors' Addresses

Michael Jenkins
National Security Agency
Alison Becker