Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions
draft-jenkins-cnsa-smime-profile-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8755.
|
|
|---|---|---|---|
| Author | Michael J. Jenkins | ||
| Last updated | 2019-08-02 (Latest revision 2019-03-06) | ||
| RFC stream | Independent Submission | ||
| Formats | |||
| IETF conflict review | conflict-review-jenkins-cnsa-smime-profile, conflict-review-jenkins-cnsa-smime-profile, conflict-review-jenkins-cnsa-smime-profile, conflict-review-jenkins-cnsa-smime-profile, conflict-review-jenkins-cnsa-smime-profile, conflict-review-jenkins-cnsa-smime-profile | ||
| Stream | ISE state | Response to Review Needed | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | Eliot Lear | ||
| IESG | IESG state | Became RFC 8755 (Informational) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | Adrian Farrel <rfc-ise@rfc-editor.org> |
draft-jenkins-cnsa-smime-profile-00
Internet Engineering Task Force M. Jenkins
Internet-Draft NSA
Intended status: Informational March 6, 2019
Expires: September 7, 2019
Using Commercial National Security Algorithm Suite Algorithms in Secure/
Multipurpose Internet Mail Extensions
draft-jenkins-cnsa-smime-profile-00
Abstract
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.
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 September 7, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jenkins Expires September 7, 2019 [Page 1]
Internet-Draft CNSA Suite for S/MIME March 2019
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Commercial National Security Algorithm Suite . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Requirements and Assumptions . . . . . . . . . . . . . . . . 4
5. SHA-384 Message Digest Algorithm . . . . . . . . . . . . . . 5
6. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 5
6.1. ECDSA Signature . . . . . . . . . . . . . . . . . . . . . 5
6.2. RSA Signature . . . . . . . . . . . . . . . . . . . . . . 6
7. Key Agreement . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Elliptic Curve Key Exchange . . . . . . . . . . . . . . . 7
7.2. RSA Key Transport . . . . . . . . . . . . . . . . . . . . 11
8. Content Encryption . . . . . . . . . . . . . . . . . . . . . 13
8.1. AES-CBC Content Encryption . . . . . . . . . . . . . . . 13
8.2. AES-GCM Content Encryption . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
This document specifies the conventions for using the United States
National Security Agency's CNSA Suite algorithms [CNSA] in Secure/
Multipurpose Internet Mail Extensions (S/MIME) [ID.rfc5751-bis]. 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 [SP-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.
S/MIME makes use of the Cryptographic Message Syntax (CMS) [RFC5652]
[RFC5083]. In particular, the signed-data, enveloped-data, and
Jenkins Expires September 7, 2019 [Page 2]
Internet-Draft CNSA Suite for S/MIME March 2019
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.
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. To this end, it publishes guidance both to assist with the
USG 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.
Transition to post-quantum algorithms will occur after NIST has
completed their evaluation and standardization. In the meantime, NSA
is publishing a set of RFCs, including this one, to provide updated
guidance concerning the use of certain commonly available commercial
algorithms [CNSSP15] 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.
3. 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
Jenkins Expires September 7, 2019 [Page 3]
Internet-Draft CNSA Suite for S/MIME March 2019
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
4. Requirements and Assumptions
CMS values are generated using ASN.1 [X.208-88], the Basic Encoding
Rules (BER) [X.209-88], and the Distinguished Encoding Rules (DER)
[X.509-88].
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:
Curve NIST Name SECG Name OID [FIPS186]
---------------------------------------------------------
nistp384 P-384 secp384r1 1.3.132.0.34
For CNSA Suite applications, public key certificates used to verify
S/MIME signatures MUST be compliant with the CNSA Suite Certificate
and CRL Profile specified in [ID.cnsa-cert-profile].
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.
ECC based implementations also require specification of schemes for
key derivation and key wrap. Requirements for these schemes are in
sections Section 7.1.2 and Section 7.1.1 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
[ID.cnsa-cert-profile], 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
Jenkins Expires September 7, 2019 [Page 4]
Internet-Draft CNSA Suite for S/MIME March 2019
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.
5. SHA-384 Message Digest Algorithm
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.
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:
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,
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.
6. Digital Signature
6.1. ECDSA Signature
The Elliptic Curve Digital Signature Algorithm (ECDSA) is the CNSA
Suite digital signature algorithm based on Elliptic Curve
Cryptography (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].
Jenkins Expires September 7, 2019 [Page 5]
Internet-Draft CNSA Suite for S/MIME March 2019
[RFC5480] defines the signature algorithm identifier used in CMS for
ECDSA with SHA-384 as follows:
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, 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]:
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
6.2. RSA Signature
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].
6.2.1. RSA-PKCS1-v1_5
[RFC5754] defines the signature algorithm identifier used in CMS for
RSA signature with SHA-384 as follows:
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.
6.2.2. RSA-PSS
[RFC4056] defines the signature algorithm identifier used in CMS for
RSA-PSS signature as follows:
Jenkins Expires September 7, 2019 [Page 6]
Internet-Draft CNSA Suite for S/MIME March 2019
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] 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 AlgorithmIdentifier parameters field MUST contain RSASSA-PSS-
params with the following values:
o the hash algorithm must be id-sha384 as defined in [RFC8017];
o the mask generation function must use the algorithm identifier
mfg1SHA384Identifier as defined in [RFC4055];
o the salt length must be 48 octets; and
o the trailerField must have value 1.
7. Key Agreement
7.1. Elliptic Curve Key Exchange
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
[ID.cnsa-cert-profile].
When a key agreement algorithm is used, a key-encryption algorithm is
also needed. In the CNSA Suite for S/MIME, the Advanced Encryption
Standard (AES) Key Wrap with Padding Algorithm, as specified in
[RFC5649] and [SP80038F], MUST be used as the key-encryption
algorithm. AES Key Wrap is discussed further in Section 7.1.1. The
key-encryption key used with the AES Key Wrap algorithm is obtained
Jenkins Expires September 7, 2019 [Page 7]
Internet-Draft CNSA Suite for S/MIME March 2019
from a key derivation function (KDF). In the CNSA Suite for S/MIME,
the KDF described in Section 7.1.2 -- based on SHA-384 -- MUST be
used.
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.
The keyEncryptionAlgorithm MUST be dhSinglePass-stdDH-sha384kdf-
scheme, and the keyEncryptionAlgorithm parameter MUST be a
KeyWrapAlgorithm containing id-aes256-wrap-pad (see Section 7.1.1).
The key wrap algorithm denotes the symmetric encryption algorithm
used to encrypt the randomly generated content-encryption key,
employing the pairwise key-encryption key generated using the
ephemeral-static ECDH key agreement algorithm (see Section 7.1.2).
The algorithm identifier for the dhSinglePass-stdDH-sha384kdf-scheme,
repeated from Section 7.1.4 of [RFC5753], is:
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 2 }
with KeyWrapAlgorithm as the type for its parameter:
KeyWrapAlgorithm ::= AlgorithmIdentifier
7.1.1. 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
Jenkins Expires September 7, 2019 [Page 8]
Internet-Draft CNSA Suite for S/MIME March 2019
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 }
7.1.2. 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 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.
As specified in Section 7.2 of [RFC5753], 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 CNSA Suite for S/MIME, the fields of ECC-CMS-SharedInfo are used
as follows:
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 the user keying material (ukm) is present,
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.
Jenkins Expires September 7, 2019 [Page 9]
Internet-Draft CNSA Suite for S/MIME March 2019
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 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.
The KDF specified in [SEC1] provides an algorithm for generating an
essentially arbitrary amount of keying material (KM) from a shared
secret, Z, produced by ephemeral-static ECDH. The KDF generates
successive blocks of keying material, KM(1), KM(2), and so on, using:
KM(Counter) = Hash ( Z || Counter || ECC-CMS-SharedInfo )
To generate an L-bit key-encryption key (KEK), one or more KM blocks
are generated, incrementing Counter appropriately, until enough
material has been generated. 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 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.
Jenkins Expires September 7, 2019 [Page 10]
Internet-Draft CNSA Suite for S/MIME March 2019
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:
KEK = the leftmost 256 bits of
SHA-384 ( Z || 0x00000001 || ECC-CMS-SharedInfo )
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.
7.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], block type is 02, 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
[ID.cnsa-cert-profile]. These certificates are suitable for use with
either RSAES-OAEP or RSAES-PKCS1-v1_5.
7.2.1. 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 content type, 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.
Jenkins Expires September 7, 2019 [Page 11]
Internet-Draft CNSA Suite for S/MIME March 2019
7.2.2. RSAES-OAEP
[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 content type, key transport algorithm
identifiers are located 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] as follows:
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:
o the hashFunc algorithm must be id-sha384 as defined in [RFC8017];
o the mask generation function must use the algorithm identifier
mfg1SHA384Identifier as defined in [RFC4055];
o the pSourceFunc field must be absent.
If the SMIMECapabilities signed attribute is included to announce
support for the RSAES-OAEP algorithm, it MUST be constructed as
Jenkins Expires September 7, 2019 [Page 12]
Internet-Draft CNSA Suite for S/MIME March 2019
defined in Section 5 of [RFC3560], with the sequence representing the
rSAES-OAEP-SHA384-Identifier.
8. Content Encryption
8.1. AES-CBC Content Encryption
CNSA Suite compliant S/MIME implementations MUST use AES-256
[FIPS197] in Cipher Block Chaining (CBC) mode [SP80038A] 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.
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.2. AES-GCM Content Encryption
CNSA Suite compliant S/MIME implementations MUST use AES [FIPS197] in
Galois Counter Mode (GCM) [SP80038D] 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.
Jenkins Expires September 7, 2019 [Page 13]
Internet-Draft CNSA Suite for S/MIME March 2019
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-IVClen 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 [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.
9. 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.
Jenkins Expires September 7, 2019 [Page 14]
Internet-Draft CNSA Suite for S/MIME March 2019
The security considerations in [RFC3565] discuss the use of AES in
the CMS.
10. IANA Considerations
This document has no IANA actions.
11. References
11.1. Normative References
[FIPS180] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS 180-4, August 2015,
<https://csrc.nist.gov/publications/detail/fips/180/4/
final>.
[FIPS186] National Institute of Standards and Technology, "Digital
Signature Standard", FIPS 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)", FIPS 197, November 2001,
<https://csrc.nist.gov/publications/detail/fips/197/
final>.
[ID.cnsa-cert-profile]
Jenkins, M. and L. Zieglar, "Commercial National Security
Algorithms (CNSA) Suite Certificate and Certificate
Revocation List (CRL) Profile", January 2018,
<https://www.ietf.org/internet-drafts/
draft-jenkins-cnsa-cert-crl-profile-01>.
Work in progress.
[ID.rfc5751-bis]
Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", September 2018,
<https://datatracker.ietf.org/doc/
draft-ietf-lamps-rfc5751-bis>.
Work in progress.
[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>.
Jenkins Expires September 7, 2019 [Page 15]
Internet-Draft CNSA Suite for S/MIME March 2019
[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>.
Jenkins Expires September 7, 2019 [Page 16]
Internet-Draft CNSA Suite for S/MIME March 2019
[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>.
[SEC1] Standards for Efficient Cryptography Group, "SEC1:
Elliptic Curve Cryptography", September 2000,
<http://www.secg.org/collateral/sec1_final.pdf>.
[SP80038A]
National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation:
Methods and Techniques", SP 800-38A, December 2001,
<https://csrc.nist.gov/publications/detail/sp/800-38a/
final>.
[SP80038D]
National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", SP 800-38D, November
2007, <https://csrc.nist.gov/publications/detail/sp/800-
38d/final>.
Jenkins Expires September 7, 2019 [Page 17]
Internet-Draft CNSA Suite for S/MIME March 2019
[SP80038F]
National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation:
Methods for Key Wrapping", SP 800-38F, December 2012,
<https://csrc.nist.gov/publications/detail/sp/800-38f/
final>.
[X.208-88]
CCITT, "Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1)", 1988,
<https://www.itu.int/rec/T-REC-X.208-198811-W/en>.
[X.209-88]
CCITT, "Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1)",
1988, <https://www.itu.int/rec/T-REC-X.209-198811-W/en>.
[X.509-88]
CCITT, "Recommendation X.509: The Directory -
Authentication Framework", 1988,
<https://www.itu.int/rec/T-REC-X.509-198811-S>.
11.2. Informative References
[CNSA] Committee for National Security Systems, "Commercial
National Security Algorithm (CNSA) Suite Fact Sheet",
December 2015, <https://www.iad.gov/iad/library/ia-
guidance/ia-solutions-for-classified/algorithm-guidance/
commercial-national-security-algorithm-suite-
factsheet.cfm>.
[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>.
[SP-800-59]
National Institute of Standards and Technology, "Guideline
for Identifying an Information System as a National
Security System", Special Publication 800 59, August 2003,
<https://csrc.nist.gov/publications/detail/sp/800-59/ >
final>.
Author's Address
Jenkins Expires September 7, 2019 [Page 18]
Internet-Draft CNSA Suite for S/MIME March 2019
Michael Jenkins
National Security Agency
Email: mjjenki@nsa.gov
Jenkins Expires September 7, 2019 [Page 19]