| Internet Engineering Task Force | M. Jenkins |
| Internet-Draft | NSA |
| Intended status: Informational | August 6, 2019 |
| Expires: February 7, 2020 |
Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions
draft-jenkins-cnsa-smime-profile-01
The United States Government has published the NSA Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 8551. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME messaging. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.
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 February 7, 2020.
Copyright (c) 2019 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document specifies the conventions for using the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite algorithms [CNSA] in Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC8551]. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME messaging. US National Security Systems are described in NIST Special Publication 800-59 [SP80059]. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.
S/MIME makes use of the Cryptographic Message Syntax (CMS) [RFC5652] [RFC5083]. In particular, the signed-data, enveloped-data, and authenticated-enveloped-data content types are used. This document only addresses CNSA Suite compliance for S/MIME. Other applications of CMS are outside the scope of this document.
This document does not define any new cryptographic algorithm suite; instead, it defines a CNSA compliant profile of S/MIME. Since many of the CNSA Suite algorithms enjoy uses in other environments as well, the majority of the conventions needed for these algorithms are already specified in other documents. This document references the source of these conventions, with some relevant details repeated to aid developers that choose to support the CNSA Suite. Where details have been repeated, the cited documents are authoritative.
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. To this end, it publishes guidance both to assist with the US Government transition to new algorithms, and to provide vendors - and the Internet community in general - with information concerning their proper use and configuration.
Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically-relevant quantum computer. NSA has established the Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users near-term flexibility in meeting their IA interoperability requirements. The purpose behind this flexibility is to avoid vendors and customers making two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future.
NSA is authoring a set of RFCs, including this one, to provide updated guidance concerning the use of certain commonly available commercial algorithms in 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 National Security Systems..
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.
CMS values are generated using ASN.1 [X208], the Basic Encoding Rules (BER) [X209], and the Distinguished Encoding Rules (DER) [X509].
Curve NIST Name SECG Name OID [FIPS186]
---------------------------------------------------------
nistp384 P-384 secp384r1 1.3.132.0.34
The elliptic curve used in the CNSA Suite is specified in [FIPS186], and appears in the literature under two different names. For the sake of clarity, we list both names below:
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].
Within the CMS signed-data content type, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of SignedData. In addition, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of countersignature attributes.
Elliptic Curve Cryptography (ECC) based implementations also require specification of schemes for key derivation and key wrap. Requirements for these schemes are in sections Section 7.1.1 and Section 7.1.2 repectively.
RSA key pairs (public, private) are identified by the modulus size expressed in bits; RSA-3072 and RSA-4096 are computed using 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].
It is recognized that, while the vast majority of RSA signatures are currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred RSA signature scheme for new applications is RSASSA-PSS. CNSA Suite compliant X.509 certificates will be issued in accordance with [RFC8603], and while those certificates must be signed and validated using RSASSA-PKCS1-v1_5, the subject's RSA key pair can be used to generate and validate signatures appropriate for either signing scheme. Where use of RSASSA-PSS is indicated in this document, the parameters in Section 6.2.2 apply.
This document assumes that 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 which are given in Section 5 and Section 8, respectively.
SHA-384 is the sole CNSA Suite message digest algorithm. [RFC5754] specifies the conventions for using SHA-384 with the Cryptographic Message Syntax (CMS). CNSA Suite 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.
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-384 message digest algorithm is defined in FIPS Pub 180 [FIPS180]. The algorithm identifier for SHA-384 is defined in [RFC5754] as follows:
For SHA-384, the AlgorithmIdentifier parameters field is OPTIONAL, and if present, the parameters field MUST contain a NULL. As specified in [RFC5754], implementations MUST generate SHA-384 AlgorithmIdentifiers with absent parameters. Implementations MUST accept SHA-384 AlgorithmIdentifiers with absent parameters or with NULL parameters.
The Elliptic Curve Digital Signature Algorithm (ECDSA) is the CNSA Suite digital signature algorithm based on ECC. [RFC5753] specifies the conventions for using ECDSA with the Cryptographic Message Syntax (CMS). CNSA Suite compliant S/MIME implementations MUST follow the conventions in [RFC5753].
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-sha2(3) 3 }
[RFC5480] defines the signature algorithm identifier used in CMS for ECDSA with SHA-384 as follows:
When the ecdsa-with-SHA384 algorithm identifier is used, the AlgorithmIdentifier parameters field MUST be absent.
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
When signing, the ECDSA algorithm generates two values, commonly called r and s. These two values MUST be encoded using the ECDSA-Sig-Value type specified in [RFC5480]:
The RSA signature generation process and the encoding of the result is either RSASSA-PKCS1-v1_5 or RSA-PSS as described in detail in PKCS #1 version 2.2 [RFC8017].
sha384WithRSAEncryption OBJECT IDENTIFIER :== { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 }
[RFC5754] defines the signature algorithm identifier used in CMS for RSA signature with SHA-384 as follows:
When the sha384WithRSAEncryption algorithm identifier is used, the parameters MUST be NULL. Implementations MUST accept the parameters being absent as well as present.
RSASSA-PSS OBJECT IDENTIFIER :== { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 }
[RFC4056] defines the signature algorithm identifier used in CMS for RSA-PSS signature as follows:
RSASSA-PSS-params ::= SEQUENCE {
hashAlgorithm [0] HashAlgorithm DEFAULT
sha1Identifier,
maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT
mgf1SHA1Identifier,
saltLength [2] INTEGER DEFAULT 20,
trailerField [3] INTEGER DEFAULT 1 }
The parameters field of an AlgorithmIdentifier that identifies RSASSA-PSS is defined in [RFC4055] as follows:
The AlgorithmIdentifier parameters field MUST contain RSASSA-PSS-params with the following values:
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. This means that the message originator possesses an ephemeral ECDH key pair and that the message recipient possesses a static ECDH key pair whose public key is provided in an X.509 certificate. The certificate used to obtain the recipient's public key MUST be compliant with [RFC8603].
When a key agreement algorithm is used, the following steps are performed: Section 7.1.1. Key wrapping is discussed in Section 7.1.2.
Key derivation is discussed in
Section 3.1 of [RFC5753] specifies the conventions for using ECDH with the 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.
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 2 }
The keyEncryptionAlgorithm field comprises two fields, an algorithm field and a parameter field. The algorithm field MUST identify dhSinglePass-stdDH-sha384kdf-scheme. The algorithm identifier for the dhSinglePass-stdDH-sha384kdf-scheme, repeated from Section 7.1.4 of [RFC5753], is:
The keyEncryptionAlgorithm parameter field MUST be constructed as described in Section 7.1.2.
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 of [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.
The KDF based on SHA-384 MUST be used.
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING }
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:
In CNSA Suite for S/MIME, the fields of ECC-CMS-SharedInfo are used as follows:
ECC-CMS-SharedInfo is DER encoded and 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] ensures that sufficient keying data is provided.
KM(Counter) = Hash ( Z || Counter || ECC-CMS-SharedInfo )
KEK = the leftmost L bits of
[KM ( counter=1 ) || KM ( counter=2 ) ...]
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), KM is computed:
In CNSA Suite for S/MIME, the elements of the KDF are defined as follows:
KEK = the leftmost 256 bits of
SHA-384 ( Z || 0x00000001 || ECC-CMS-SharedInfo )
In CNSA Suite for S/MIME, exactly one iteration is needed; the Counter is not incremented. The key-encryption key (KEK) MUST be the first (leftmost) 256 bits of the SHA-384 output value:
In CNSA Suite for S/MIME, the key-encryption key MUST be the most significant 256 bits of the SHA-384 output value.
Note that the only source of secret entropy in this computation is Z.
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.
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 }
The KeyWrapAlgorithm MUST be id-aes256-wrap-pad. The required algorithm identifier, specified in [RFC5649], is:
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 possesses an RSA key pair whose public key is represented by an X.509 certificate. The certificate used to obtain 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.
Section 4.2 of [RFC3370] specifies the conventions for using RSAES-PKCS1-v1_5 with the 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.
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
The algorithm identifier for RSA (PKCS #1 v1.5) is:
The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain NULL.
[RFC3560] specifies the conventions for using RSAES-OAEP with the CMS. CNSA Suite compliant 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.
id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }
The algorithm identifier for RSA (OAEP) is:
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 parameters field of an AlgorithmIdentifier that identifies RSAES-OAEP is defined in [RFC4055] as follows:
The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain RSAES-OAEP-params with values as follows:
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.
CNSA Suite compliant S/MIME implementations MUST use AES-256 in Cipher Block Chaining (CBC) mode as the content encryption algorithm when using the enveloped-data content type, 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.
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 AES CBC content-encryption algorithm is described in [FIPS197] and [SP80038A]. The algorithm identifier for AES-256 in CBC mode is:
AES-IV ::= OCTET STRING (SIZE(16))
The AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain AES-IV:
The 16-octet initialization vector is generated at random by the originator. See [RFC4086] for guidance on generation of random values.
CNSA Suite compliant S/MIME implementations MUST use AES in Galois Counter Mode (GCM) as the content-authenticated encryption algorithm when using the authenticated-enveloped-data content type [RFC5083], and MUST follow the conventions for using AES-GCM with the CMS defined in [RFC5084].
In CNSA Suite for S/MIME AES-256 in GCM mode MUST be used.
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.
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 AES-GCM content-authenticated encryption algorithm is described in [FIPS197] and [SP80038D]. The algorithm identifier for AES-256 in GCM mode is:
GCMParameters ::= SEQUENCE {
aes-nonce OCTET STRING,
aes-ICVlen AES-GCM-IVClen DEFAULT 12 }
The AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain GCMParameters:
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 [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.
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, in particular the recommendation to use authenticated encryption modes (i.e. use authenticated-enveloped-data with AES-GCM rather than enveloped-data with AES-CBC).
This document has no IANA actions.
| [RFC4086] | Eastlake 3rd, D., Schiller, J. and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005. |
| [SP80059] | National Institute of Standards and Technology, "Guideline for Identifying an Information System as a National Security System", Special Publication 800-59 , August 2003. |