National Security Agency

aebecke@uwe.nsa.gov

National Security Agency

mjjenki@cyber.nsa.gov

This document defines a base profile of S/MIME for use with the U.S. 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 U.S. national security applications. This profile applies to the capabilities, configuration, and operation of all components of U.S. National Security Systems that employ S/MIME. It is also appropriate for all other U.S. Government systems that process high-value information. This profile is made publicly available for use by developers and operators of these and any other system deployments.

Introduction This document specifies a profile of S/MIME to comply with the National Security Agency's (NSA) Commercial National Security Algorithm (CNSA) 2.0 Suite . This profile applies to the capabilities, configuration, and operation of all components of U.S. National Security Systems (NSS) that employ S/MIME. U.S. National Security Systems are described in NIST Special Publication 800-59 . This profile is also appropriate for all other U.S. 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. The reader is assumed to have familiarity with . [ED NOTE: This document uses some details from to specify use of ML-KEM in CMS, and to specify use of ML-DSA in CMS. We note that these drafts are not yet RFCs, and we may need to adjust this text accordingly based on the progress of these documents.] All usage of the term "CNSA" in this document refers to CNSA 2.0 , unless otherwise stated.

Terminology Text from RFC2119. 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 if and only if they appear in all capitals, as shown here. All MUST-level requirements of , apply throughout this profile; they are generally not repeated. In cases where a MUST-level requirement is repeated for clarity, the source document prevails. This profile may contain changes that elevate or downgrade some SHOULD- or MUST-level options from a specified RFC. All options from , that are not mentioned in this profile remain at the requirement level of the reference. All usage of the term "CNSA" in this document refers to CNSA 2.0 , unless otherwise stated.

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 U.S. Government National Security Systems (NSS). To this end, it publishes guidance both to assist with the U.S. Government transition to new algorithms and to provide vendors - and the internet community in general - with information concerning their proper use and configuration within the scope of U.S. Government National Security Systems. The Commercial National Security Algorithm (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, establishes fully quantum-resistant protection . Pursuant to the National Security Memorandum on Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems , the National Institute for Standards and Technology (NIST) selected several quantum-resistant, or post-quantum, asymmetric algorithms for standardization. From these, NSA has included two in CNSA 2.0: ML-DSA-87 for signing, and ML-KEM-1024 for key establishment. ML-DSA-87 and ML-KEM-1024 together with SHA384, SHA512, 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 U.S. Government National Security Systems.

Requirements and Assumptions CMS values are generated using ASN.1 , the Basic Encoding Rules (BER) , and the Distinguished Encoding Rules (DER) . 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 . 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 and AES-GCM for encryption, the requirements for which are given in the following sections.

Message Digest CNSA 2.0 allows either SHA-384 or SHA-512 to be used as a message digest algorithm. specifies the conventions for using SHA-384 or SHA-512 with the Cryptographic Message Syntax (CMS). CNSA Suite-compliant S/MIME implementations follow the conventions in . 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 , and the algorithm identifier for SHA-384 is defined in 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 , and the algorithm identifier for SHA-512 is defined in 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 } 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 , implementations MUST generate SHA-384 or SHA-512 AlgorithmIdentifiers with absent parameters.

Digital Signature CNSA 2.0 requires the use of ML-DSA-87 as the digital signature algorithm in S/MIME. is ongoing work detailing the conventions for using ML-DSA with the Cryptographic Message Syntax (CMS). Note that only specifies use of the pure mode (not pre-hash) of ML-DSA in CMS, which is also in accordance with CNSA. The “message digest” supplied to the signature algorithm is the entire message. [EDNOTE: This guidance is subject to change as conventions for External Mu, as defined in , are further defined.] The algorithm identifier for ML-DSA-87 is defined in Section 2 of , and this document will be updated accordingly.

Key Establishment

KEM For key agreement, CNSA 2.0 requires the use of ML-KEM-1024. is ongoing work detailing the conventions for implementing ML-KEM in the KEMRecipientInfo structure in CMS to securely transfer the content-encryption key from the originator to the recipient. We also refer to guidance from . 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 include the ukm input to the key-derivation function.

KDF A CNSA compliant implementation MUST support SHA-384 or SHA-512 for KDF computation. We note the KDF used to process the KEMRecipientInfo structure MAY be different from the KDF used in the ML-KEM-1024 algorithm.

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 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 }

Content Encryption CNSA-compliant S/MIME implementations using the authenticated-enveloped-data content type MUST use AES in Galois Counter Mode (GCM) as the content authenticated encryption algorithm and MUST follow the conventions for using AES-GCM with the CMS defined in . 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 and . 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 . 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.

Security Considerations Most of the security considerations for this document are described in . Additional security considerations for the use of ML-KEM and ML-DSA in S/MIME can be found in and , respectively.

IANA Considerations This document has no IANA actions

References National Institute of Standards and Technology National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (2024) National Institute of Standards and Technology (2024) National Security Agency National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology United States, The White House CCITT CCITT CCITT