< draft-jenkins-cnsa-smime-profile-00.txt   draft-jenkins-cnsa-smime-profile-01.txt >
Internet Engineering Task Force M. Jenkins Internet Engineering Task Force M. Jenkins
Internet-Draft NSA Internet-Draft NSA
Intended status: Informational March 6, 2019 Intended status: Informational August 6, 2019
Expires: September 7, 2019 Expires: February 7, 2020
Using Commercial National Security Algorithm Suite Algorithms in Secure/ Using Commercial National Security Algorithm Suite Algorithms in Secure/
Multipurpose Internet Mail Extensions Multipurpose Internet Mail Extensions
draft-jenkins-cnsa-smime-profile-00 draft-jenkins-cnsa-smime-profile-01
Abstract Abstract
The United States government has published the NSA Commercial The United States Government has published the NSA Commercial
National Security Algorithm (CNSA) Suite, which defines cryptographic National Security Algorithm (CNSA) Suite, which defines cryptographic
algorithm policy for national security applications. This document algorithm policy for national security applications. This document
specifies the conventions for using the United States National specifies the conventions for using the United States National
Security Agency's CNSA Suite algorithms in Secure/Multipurpose Security Agency's CNSA Suite algorithms in Secure/Multipurpose
Internet Mail Extensions (S/MIME) as specified in RFC 8551. It Internet Mail Extensions (S/MIME) as specified in RFC 8551. It
applies to the capabilities, configuration, and operation of all applies to the capabilities, configuration, and operation of all
components of US National Security Systems that employ S/MIME components of US National Security Systems that employ S/MIME
messaging. US National Security Systems are described in NIST messaging. US National Security Systems are described in NIST
Special Publication 800-59. It is also appropriate for all other US Special Publication 800-59. It is also appropriate for all other US
Government systems that process high-value information. It is made Government systems that process high-value information. It is made
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 2019. This Internet-Draft will expire on February 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Commercial National Security Algorithm Suite . . . . . . 3 2. The Commercial National Security Algorithm Suite . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Requirements and Assumptions . . . . . . . . . . . . . . . . 4 4. Requirements and Assumptions . . . . . . . . . . . . . . . . 4
5. SHA-384 Message Digest Algorithm . . . . . . . . . . . . . . 5 5. SHA-384 Message Digest Algorithm . . . . . . . . . . . . . . 5
6. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 5 6. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 5
6.1. ECDSA Signature . . . . . . . . . . . . . . . . . . . . . 5 6.1. ECDSA Signature . . . . . . . . . . . . . . . . . . . . . 5
6.2. RSA Signature . . . . . . . . . . . . . . . . . . . . . . 6 6.2. RSA Signature . . . . . . . . . . . . . . . . . . . . . . 6
7. Key Agreement . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Key Establishment . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Elliptic Curve Key Exchange . . . . . . . . . . . . . . . 7 7.1. Elliptic Curve Key Agreement . . . . . . . . . . . . . . 7
7.2. RSA Key Transport . . . . . . . . . . . . . . . . . . . . 11 7.2. RSA Key Transport . . . . . . . . . . . . . . . . . . . . 11
8. Content Encryption . . . . . . . . . . . . . . . . . . . . . 13 8. Content Encryption . . . . . . . . . . . . . . . . . . . . . 13
8.1. AES-CBC Content Encryption . . . . . . . . . . . . . . . 13 8.1. AES-CBC Content Encryption . . . . . . . . . . . . . . . 13
8.2. AES-GCM Content Encryption . . . . . . . . . . . . . . . 13 8.2. AES-GCM Content Encryption . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document specifies the conventions for using the United States This document specifies the conventions for using the United States
National Security Agency's CNSA Suite algorithms [CNSA] in Secure/ National Security Agency's Commercial National Security Algorithm
Multipurpose Internet Mail Extensions (S/MIME) [ID.rfc5751-bis]. It (CNSA) Suite algorithms [CNSA] in Secure/Multipurpose Internet Mail
applies to the capabilities, configuration, and operation of all Extensions (S/MIME) [RFC8551]. It applies to the capabilities,
components of US National Security Systems that employ S/MIME configuration, and operation of all components of US National
messaging. US National Security Systems are described in NIST Security Systems that employ S/MIME messaging. US National Security
Special Publication 800-59 [SP-800-59]. It is also appropriate for Systems are described in NIST Special Publication 800-59 [SP80059].
all other US Government systems that process high-value information. It is also appropriate for all other US Government systems that
It is made publicly available for use by developers and operators of process high-value information. It is made publicly available for
these and any other system deployments. use by developers and operators of these and any other system
deployments.
S/MIME makes use of the Cryptographic Message Syntax (CMS) [RFC5652] S/MIME makes use of the Cryptographic Message Syntax (CMS) [RFC5652]
[RFC5083]. In particular, the signed-data, enveloped-data, and [RFC5083]. In particular, the signed-data, enveloped-data, and
authenticated-enveloped-data content types are used. This document authenticated-enveloped-data content types are used. This document
only addresses CNSA Suite compliance for S/MIME. Other applications only addresses CNSA Suite compliance for S/MIME. Other applications
of CMS are outside the scope of this document. of CMS are outside the scope of this document.
This document does not define any new cryptographic algorithm suite; This document does not define any new cryptographic algorithm suite;
instead, it defines a CNSA compliant profile of S/MIME. Since many instead, it defines a CNSA compliant profile of S/MIME. Since many
of the CNSA Suite algorithms enjoy uses in other environments as of the CNSA Suite algorithms enjoy uses in other environments as
skipping to change at page 3, line 23 skipping to change at page 3, line 26
source of these conventions, with some relevant details repeated to source of these conventions, with some relevant details repeated to
aid developers that choose to support the CNSA Suite. Where details aid developers that choose to support the CNSA Suite. Where details
have been repeated, the cited documents are authoritative. have been repeated, the cited documents are authoritative.
2. The Commercial National Security Algorithm Suite 2. The Commercial National Security Algorithm Suite
The National Security Agency (NSA) profiles commercial cryptographic The National Security Agency (NSA) profiles commercial cryptographic
algorithms and protocols as part of its mission to support secure, algorithms and protocols as part of its mission to support secure,
interoperable communications for US Government National Security interoperable communications for US Government National Security
Systems. To this end, it publishes guidance both to assist with the Systems. To this end, it publishes guidance both to assist with the
USG transition to new algorithms, and to provide vendors - and the US Government transition to new algorithms, and to provide vendors -
Internet community in general - with information concerning their and the Internet community in general - with information concerning
proper use and configuration. their proper use and configuration.
Recently, cryptographic transition plans have become overshadowed by Recently, cryptographic transition plans have become overshadowed by
the prospect of the development of a cryptographically-relevant the prospect of the development of a cryptographically-relevant
quantum computer. NSA has established the Commercial National quantum computer. NSA has established the Commercial National
Security Algorithm (CNSA) Suite to provide vendors and IT users near- Security Algorithm (CNSA) Suite to provide vendors and IT users near-
term flexibility in meeting their IA interoperability requirements. term flexibility in meeting their IA interoperability requirements.
The purpose behind this flexibility is to avoid vendors and customers The purpose behind this flexibility is to avoid vendors and customers
making two major transitions in a relatively short timeframe, as we making two major transitions in a relatively short timeframe, as we
anticipate a need to shift to quantum-resistant cryptography in the anticipate a need to shift to quantum-resistant cryptography in the
near future. near future.
Transition to post-quantum algorithms will occur after NIST has NSA is authoring a set of RFCs, including this one, to provide
completed their evaluation and standardization. In the meantime, NSA updated guidance concerning the use of certain commonly available
is publishing a set of RFCs, including this one, to provide updated commercial algorithms in IETF protocols. These RFCs can be used in
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 conjunction with other RFCs and cryptographic guidance (e.g., NIST
Special Publications) to properly protect Internet traffic and data- Special Publications) to properly protect Internet traffic and data-
at-rest. at-rest for US Government National Security Systems..
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
4. Requirements and Assumptions 4. Requirements and Assumptions
CMS values are generated using ASN.1 [X.208-88], the Basic Encoding CMS values are generated using ASN.1 [X208], the Basic Encoding Rules
Rules (BER) [X.209-88], and the Distinguished Encoding Rules (DER) (BER) [X209], and the Distinguished Encoding Rules (DER) [X509].
[X.509-88].
The elliptic curve used in the CNSA Suite is specified in [FIPS186], The elliptic curve used in the CNSA Suite is specified in [FIPS186],
and appears in the literature under two different names. For the and appears in the literature under two different names. For the
sake of clarity, we list both names below: sake of clarity, we list both names below:
Curve NIST Name SECG Name OID [FIPS186] Curve NIST Name SECG Name OID [FIPS186]
--------------------------------------------------------- ---------------------------------------------------------
nistp384 P-384 secp384r1 1.3.132.0.34 nistp384 P-384 secp384r1 1.3.132.0.34
For CNSA Suite applications, public key certificates used to verify For CNSA Suite applications, public key certificates used to verify
S/MIME signatures MUST be compliant with the CNSA Suite Certificate S/MIME signatures MUST be compliant with the CNSA Suite Certificate
and CRL Profile specified in [ID.cnsa-cert-profile]. and Certificate Revocation List (CRL) Profile specified in [RFC8603].
Within the CMS signed-data content type, signature algorithm Within the CMS signed-data content type, signature algorithm
identifiers are located in the SignerInfo signatureAlgorithm field of identifiers are located in the SignerInfo signatureAlgorithm field of
SignedData. In addition, signature algorithm identifiers are located SignedData. In addition, signature algorithm identifiers are located
in the SignerInfo signatureAlgorithm field of countersignature in the SignerInfo signatureAlgorithm field of countersignature
attributes. attributes.
ECC based implementations also require specification of schemes for Elliptic Curve Cryptography (ECC) based implementations also require
key derivation and key wrap. Requirements for these schemes are in specification of schemes for key derivation and key wrap.
sections Section 7.1.2 and Section 7.1.1 repectively. 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 RSA key pairs (public, private) are identified by the modulus size
expressed in bits; RSA-3072 and RSA-4096 are computed using moduli of expressed in bits; RSA-3072 and RSA-4096 are computed using moduli of
3072 bits and 4096 bits, respectively. 3072 bits and 4096 bits, respectively.
RSA signature key pairs used in CNSA Suite compliant implementations RSA signature key pairs used in CNSA Suite compliant implementations
are either RSA-3072 or RSA-4096. The RSA exponent e MUST satisfy are either RSA-3072 or RSA-4096. The RSA exponent e MUST satisfy
2^16<e<2^256 and be odd per [FIPS186]. 2^16<e<2^256 and be odd per [FIPS186].
It is recognized that, while the vast majority of RSA signatures are It is recognized that, while the vast majority of RSA signatures are
currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred
RSA signature scheme for new applications is RSASSA-PSS. CNSA Suite RSA signature scheme for new applications is RSASSA-PSS. CNSA Suite
compliant X.509 certificates will be issued in accordance with compliant X.509 certificates will be issued in accordance with
[ID.cnsa-cert-profile], and while those certificates must be signed [RFC8603], and while those certificates must be signed and validated
and validated using RSASSA-PKCS1-v1_5, the subject's RSA key pair can using RSASSA-PKCS1-v1_5, the subject's RSA key pair can be used to
be used to generate and validate signatures appropriate for either generate and validate signatures appropriate for either signing
signing scheme. Where use of RSASSA-PSS is indicated in this scheme. Where use of RSASSA-PSS is indicated in this document, the
document, the parameters in Section 6.2.2 apply. parameters in Section 6.2.2 apply.
This document assumes that required trust anchors have been securely This document assumes that required trust anchors have been securely
provisioned to the client. provisioned to the client.
All implementations use SHA-384 for hashing and either AES-CBC or All implementations use SHA-384 for hashing and either AES-CBC or
AES-GCM for encryption, the requirements for which are given in AES-GCM for encryption, the requirements for which are given in
Section 5 and Section 8, respectively. Section 5 and Section 8, respectively.
5. SHA-384 Message Digest Algorithm 5. SHA-384 Message Digest Algorithm
skipping to change at page 5, line 45 skipping to change at page 5, line 45
specified in [RFC5754], implementations MUST generate SHA-384 specified in [RFC5754], implementations MUST generate SHA-384
AlgorithmIdentifiers with absent parameters. Implementations MUST AlgorithmIdentifiers with absent parameters. Implementations MUST
accept SHA-384 AlgorithmIdentifiers with absent parameters or with accept SHA-384 AlgorithmIdentifiers with absent parameters or with
NULL parameters. NULL parameters.
6. Digital Signature 6. Digital Signature
6.1. ECDSA Signature 6.1. ECDSA Signature
The Elliptic Curve Digital Signature Algorithm (ECDSA) is the CNSA The Elliptic Curve Digital Signature Algorithm (ECDSA) is the CNSA
Suite digital signature algorithm based on Elliptic Curve Suite digital signature algorithm based on ECC. [RFC5753] specifies
Cryptography (ECC). [RFC5753] specifies the conventions for using the conventions for using ECDSA with the Cryptographic Message Syntax
ECDSA with the Cryptographic Message Syntax (CMS). CNSA Suite (CMS). CNSA Suite compliant S/MIME implementations MUST follow the
compliant S/MIME implementations MUST follow the conventions in conventions in [RFC5753].
[RFC5753].
[RFC5480] defines the signature algorithm identifier used in CMS for [RFC5480] defines the signature algorithm identifier used in CMS for
ECDSA with SHA-384 as follows: ECDSA with SHA-384 as follows:
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) ansi-X9-62(10045) signatures(4) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-sha2(3) 3 } ecdsa-with-sha2(3) 3 }
When the ecdsa-with-SHA384 algorithm identifier is used, the When the ecdsa-with-SHA384 algorithm identifier is used, the
AlgorithmIdentifier parameters field MUST be absent. AlgorithmIdentifier parameters field MUST be absent.
skipping to change at page 7, line 22 skipping to change at page 7, line 22
hashAlgorithm [0] HashAlgorithm DEFAULT hashAlgorithm [0] HashAlgorithm DEFAULT
sha1Identifier, sha1Identifier,
maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT
mgf1SHA1Identifier, mgf1SHA1Identifier,
saltLength [2] INTEGER DEFAULT 20, saltLength [2] INTEGER DEFAULT 20,
trailerField [3] INTEGER DEFAULT 1 } trailerField [3] INTEGER DEFAULT 1 }
The AlgorithmIdentifier parameters field MUST contain RSASSA-PSS- The AlgorithmIdentifier parameters field MUST contain RSASSA-PSS-
params with the following values: params with the following values:
o the hash algorithm must be id-sha384 as defined in [RFC8017]; o the hash algorithm MUST be id-sha384 as defined in [RFC8017];
o the mask generation function must use the algorithm identifier o the mask generation function MUST use the algorithm identifier
mfg1SHA384Identifier as defined in [RFC4055]; mfg1SHA384Identifier as defined in [RFC4055];
o the salt length must be 48 octets; and o the salt length MUST be 48 octets; and
o the trailerField must have value 1. o the trailerField MUST have value 1.
7. Key Agreement 7. Key Establishment
7.1. Elliptic Curve Key Exchange 7.1. Elliptic Curve Key Agreement
Elliptic Curve Diffie-Hellman (ECDH) is the CNSA Suite key agreement Elliptic Curve Diffie-Hellman (ECDH) is the CNSA Suite key agreement
algorithm. Since S/MIME is used in store-and-forward communications, algorithm. Since S/MIME is used in store-and-forward communications,
ephemeral-static ECDH is always employed. This means that the ephemeral-static ECDH is always employed. This means that the
message originator possesses an ephemeral ECDH key pair and that the message originator possesses an ephemeral ECDH key pair and that the
message recipient possesses a static ECDH key pair whose public key message recipient possesses a static ECDH key pair whose public key
is provided in an X.509 certificate. The certificate used to obtain is provided in an X.509 certificate. The certificate used to obtain
the recipient's public key MUST be compliant with the recipient's public key MUST be compliant with [RFC8603].
[ID.cnsa-cert-profile].
When a key agreement algorithm is used, a key-encryption algorithm is When a key agreement algorithm is used, the following steps are
also needed. In the CNSA Suite for S/MIME, the Advanced Encryption performed:
Standard (AES) Key Wrap with Padding Algorithm, as specified in
[RFC5649] and [SP80038F], MUST be used as the key-encryption 1. A content-encryption key (CEK) for a particular content-
algorithm. AES Key Wrap is discussed further in Section 7.1.1. The encryption algorithm is generated at random.
key-encryption key used with the AES Key Wrap algorithm is obtained
from a key derivation function (KDF). In the CNSA Suite for S/MIME, 2. The recipient's public key and sender's private key are used with
the KDF described in Section 7.1.2 -- based on SHA-384 -- MUST be a key agreement scheme to generate a shared secret (Z).
used.
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 7.1.1. Key wrapping is
discussed in Section 7.1.2.
Section 3.1 of [RFC5753] specifies the conventions for using ECDH Section 3.1 of [RFC5753] specifies the conventions for using ECDH
with the CMS. CNSA Suite compliant S/MIME implementations MUST with the CMS. CNSA Suite compliant S/MIME implementations MUST
follow these conventions. follow these conventions.
Within the CMS enveloped-data and authenticated-enveloped-data Within the CMS enveloped-data and authenticated-enveloped-data
content types, key agreement algorithm identifiers are located in the content types, key agreement algorithm identifiers are located in the
EnvelopedData RecipientInfos KeyAgreeRecipientInfo EnvelopedData RecipientInfos KeyAgreeRecipientInfo
keyEncryptionAlgorithm field. keyEncryptionAlgorithm field.
The keyEncryptionAlgorithm MUST be dhSinglePass-stdDH-sha384kdf- The keyEncryptionAlgorithm field comprises two fields, an algorithm
scheme, and the keyEncryptionAlgorithm parameter MUST be a field and a parameter field. The algorithm field MUST identify
KeyWrapAlgorithm containing id-aes256-wrap-pad (see Section 7.1.1). dhSinglePass-stdDH-sha384kdf-scheme. The algorithm identifier for
The key wrap algorithm denotes the symmetric encryption algorithm the dhSinglePass-stdDH-sha384kdf-scheme, repeated from Section 7.1.4
used to encrypt the randomly generated content-encryption key, of [RFC5753], is:
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 ::= dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132) { iso(1) identified-organization(3) certicom(132)
schemes(1) 11 2 } schemes(1) 11 2 }
with KeyWrapAlgorithm as the type for its parameter: The keyEncryptionAlgorithm parameter field MUST be constructed as
described in Section 7.1.2.
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
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 7.1.1. Key Derivation Functions
KDFs based on SHA-384 are used to derive a pairwise key-encryption KDFs based on SHA-384 are used to derive a pairwise key-encryption
key from the shared secret produced by ephemeral-static ECDH. key from the shared secret produced by ephemeral-static ECDH.
Sections 7.1.8 and 7.2 of [RFC5753] specify the CMS conventions for 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 using a KDF with the shared secret generated during ephemeral-static
ECDH. CNSA Suite compliant S/MIME implementations MUST follow these ECDH. CNSA Suite compliant S/MIME implementations MUST follow these
conventions. conventions.
The KDF based on SHA-384 MUST be used. The KDF based on SHA-384 MUST be used.
As specified in Section 7.2 of [RFC5753], using ECDH with the CMS As specified in Section 7.2 of [RFC5753], when using ECDH with the
enveloped-data or authenticated-enveloped-data content type, the CMS enveloped-data or authenticated-enveloped-data content type, the
derivation of key-encryption keys makes use of the ECC-CMS-SharedInfo derivation of key-encryption keys makes use of the ECC-CMS-SharedInfo
type: type:
ECC-CMS-SharedInfo ::= SEQUENCE { ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier, keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING } suppPubInfo [2] EXPLICIT OCTET STRING }
In CNSA Suite for S/MIME, the fields of ECC-CMS-SharedInfo are used In CNSA Suite for S/MIME, the fields of ECC-CMS-SharedInfo are used
as follows: as follows:
keyInfo contains the object identifier of the key-encryption keyInfo contains the object identifier of the key-encryption
algorithm used to wrap the content-encryption key. If AES-256 Key algorithm used to wrap the content-encryption key. If AES-256 Key
Wrap is used, then the keyInfo will contain id-aes256-wrap-pad, Wrap is used, then the keyInfo will contain id-aes256-wrap-pad,
and the parameters will be absent. and the parameters will be absent.
entityUInfo optionally contains a random value provided by the entityUInfo optionally contains a random value provided by the
message originator. If the user keying material (ukm) is present, message originator. If user keying material (ukm) is included in
then the entityUInfo MUST be present, and it MUST contain the ukm the KeyAgreeRecipientInfo, then the entityUInfo MUST be present,
value. If the ukm is not present, then the entityUInfo MUST be and it MUST contain the ukm value. If the ukm is not present,
absent. then the entityUInfo MUST be absent.
suppPubInfo contains the length of the generated key-encryption suppPubInfo contains the length of the generated key-encryption
key, in bits, represented as a 32-bit unsigned number, as key, in bits, represented as a 32-bit unsigned number, as
described in [RFC2631]. When a 256-bit AES key is used, the described in [RFC2631]. When a 256-bit AES key is used, the
length MUST be 0x00000100. length MUST be 0x00000100.
ECC-CMS-SharedInfo is DER encoded and used as input to the key 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 derivation function, as specified in Section 3.6.1 of [SEC1]. Note
that ECC-CMS-SharedInfo differs from the OtherInfo specified in that ECC-CMS-SharedInfo differs from the OtherInfo specified in
[RFC2631]. Here, a counter value is not included in the keyInfo [RFC2631]. Here, a counter value is not included in the keyInfo
field because the KDF specified in [SEC1] ensures that sufficient field because the KDF specified in [SEC1] ensures that sufficient
keying data is provided. keying data is provided.
The KDF specified in [SEC1] provides an algorithm for generating an The KDF specified in Section 3.6.1 of [SEC1] describes how to
essentially arbitrary amount of keying material (KM) from a shared generate an essentially arbitrary amount of keying material from a
secret, Z, produced by ephemeral-static ECDH. The KDF generates shared secret, Z, produced by ephemeral-static ECDH. To generate an
successive blocks of keying material, KM(1), KM(2), and so on, using: L-bit key-encryption key (KEK), KM is computed:
KM(Counter) = Hash ( Z || Counter || ECC-CMS-SharedInfo ) KM(Counter) = Hash ( Z || Counter || ECC-CMS-SharedInfo )
To generate an L-bit key-encryption key (KEK), one or more KM blocks incrementing Counter appropriately, until enough material has been
are generated, incrementing Counter appropriately, until enough generated. The KM blocks are concatenated left to right, as they are
material has been generated. The KM blocks are concatenated left to generated, and the first (leftmost) L bits are used as the KEK:
right, as they are generated, and the first (leftmost) L bits are
used as the KEK:
KEK = the leftmost L bits of KEK = the leftmost L bits of
[KM ( counter=1 ) || KM ( counter=2 ) ...] [KM ( counter=1 ) || KM ( counter=2 ) ...]
In CNSA Suite for S/MIME, the elements of the KDF are defined as In CNSA Suite for S/MIME, the elements of the KDF are defined as
follows: follows:
Hash is a one-way hash function. The SHA-384 hash MUST be used. Hash is a one-way hash function. The SHA-384 hash MUST be used.
Z is the shared secret value generated during ephemeral-static Z is the shared secret value generated during ephemeral-static
skipping to change at page 11, line 17 skipping to change at page 10, line 36
first (leftmost) 256 bits of the SHA-384 output value: first (leftmost) 256 bits of the SHA-384 output value:
KEK = the leftmost 256 bits of KEK = the leftmost 256 bits of
SHA-384 ( Z || 0x00000001 || ECC-CMS-SharedInfo ) SHA-384 ( Z || 0x00000001 || ECC-CMS-SharedInfo )
In CNSA Suite for S/MIME, the key-encryption key MUST be the most In CNSA Suite for S/MIME, the key-encryption key MUST be the most
significant 256 bits of the SHA-384 output value. significant 256 bits of the SHA-384 output value.
Note that the only source of secret entropy in this computation is Z. Note that the only source of secret entropy in this computation is Z.
7.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 }
7.2. RSA Key Transport 7.2. RSA Key Transport
RSA encryption (RSA) is the CNSA Suite key transport algorithm. The RSA encryption (RSA) is the CNSA Suite key transport algorithm. The
RSA key transport algorithm is the RSA encryption scheme defined in RSA key transport algorithm is the RSA encryption scheme defined in
[RFC8017], block type is 02, where the message to be encrypted is the [RFC8017], where the message to be encrypted is the content-
content-encryption key. encryption key.
The recipient of an S/MIME message possesses an RSA key pair whose The recipient of an S/MIME message possesses an RSA key pair whose
public key is represented by an X.509 certificate. The certificate public key is represented by an X.509 certificate. The certificate
used to obtain the recipient's public key MUST be compliant with used to obtain the recipient's public key MUST be compliant with
[ID.cnsa-cert-profile]. These certificates are suitable for use with [RFC8603]. These certificates are suitable for use with either
either RSAES-OAEP or RSAES-PKCS1-v1_5. RSAES-OAEP or RSAES-PKCS1-v1_5.
7.2.1. RSAES-PKCS1-v1_5 7.2.1. RSAES-PKCS1-v1_5
Section 4.2 of [RFC3370] specifies the conventions for using RSAES- Section 4.2 of [RFC3370] specifies the conventions for using RSAES-
PKCS1-v1_5 with the CMS. S/MIME implementations employing this form PKCS1-v1_5 with the CMS. S/MIME implementations employing this form
of key transport MUST follow these conventions. of key transport MUST follow these conventions.
Within the CMS enveloped-data content type, key transport algorithm Within the CMS enveloped-data and authenticated-enveloped-data
identifiers are located in the EnvelopedData RecipientInfos content types, key transport algorithm identifiers are located in the
KeyTransRecipientInfo keyEncryptionAlgorithm field. EnvelopedData RecipientInfos KeyTransRecipientInfo
keyEncryptionAlgorithm field.
The algorithm identifier for RSA (PKCS #1 v1.5) is: The algorithm identifier for RSA (PKCS #1 v1.5) is:
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
The AlgorithmIdentifier parameters field MUST be present, and the The AlgorithmIdentifier parameters field MUST be present, and the
parameters field MUST contain NULL. parameters field MUST contain NULL.
7.2.2. RSAES-OAEP 7.2.2. RSAES-OAEP
[RFC3560] specifies the conventions for using RSAES-OAEP with the [RFC3560] specifies the conventions for using RSAES-OAEP with the
CMS. CNSA Suite compliant S/MIME implementations employing this form CMS. CNSA Suite compliant S/MIME implementations employing this form
of key transport MUST follow these conventions. of key transport MUST follow these conventions.
Within the CMS enveloped-data content type, key transport algorithm Within the CMS enveloped-data and authenticated-enveloped-data
identifiers are located in the EnvelopedData RecipientInfos content types, key transport algorithm identifiers are located in the
KeyTransRecipientInfo keyEncryptionAlgorithm field. EnvelopedData RecipientInfos KeyTransRecipientInfo
keyEncryptionAlgorithm field.
The algorithm identifier for RSA (OAEP) is: The algorithm identifier for RSA (OAEP) is:
id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }
The parameters field of an AlgorithmIdentifier that identifies RSAES- The parameters field of an AlgorithmIdentifier that identifies RSAES-
OAEP is defined in [RFC4055] as follows: OAEP is defined in [RFC4055] as follows:
RSAES-OAEP-params ::= SEQUENCE { RSAES-OAEP-params ::= SEQUENCE {
skipping to change at page 12, line 47 skipping to change at page 12, line 42
parameters field MUST contain RSAES-OAEP-params with values as parameters field MUST contain RSAES-OAEP-params with values as
follows: follows:
o the hashFunc algorithm must be id-sha384 as defined in [RFC8017]; o the hashFunc algorithm must be id-sha384 as defined in [RFC8017];
o the mask generation function must use the algorithm identifier o the mask generation function must use the algorithm identifier
mfg1SHA384Identifier as defined in [RFC4055]; mfg1SHA384Identifier as defined in [RFC4055];
o the pSourceFunc field must be absent. o the pSourceFunc field must be absent.
If the SMIMECapabilities signed attribute is included to announce The SMIMECapabilities signed attribute is used to specify a partial
support for the RSAES-OAEP algorithm, it MUST be constructed as list of algorithms that the software announcing the SMIMECapabilities
defined in Section 5 of [RFC3560], with the sequence representing the can support. If the SMIMECapabilities signed attribute is included
rSAES-OAEP-SHA384-Identifier. 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.
8. Content Encryption 8. Content Encryption
8.1. AES-CBC Content Encryption 8.1. AES-CBC Content Encryption
CNSA Suite compliant S/MIME implementations MUST use AES-256 CNSA Suite compliant S/MIME implementations MUST use AES-256
[FIPS197] in Cipher Block Chaining (CBC) mode [SP80038A] as the [FIPS197] in Cipher Block Chaining (CBC) mode [SP80038A] as the
content encryption algorithm when using the enveloped-data content content encryption algorithm when using the enveloped-data content
type, and MUST follow the conventions for using AES with the CMS type, and MUST follow the conventions for using AES with the CMS
defined in [RFC3565]. defined in [RFC3565].
skipping to change at page 15, line 8 skipping to change at page 15, line 5
The security considerations in [RFC3370] discuss cryptographic The security considerations in [RFC3370] discuss cryptographic
algorithm implementation concerns in the context of the CMS. algorithm implementation concerns in the context of the CMS.
The security considerations in [RFC5753] discuss the use of elliptic The security considerations in [RFC5753] discuss the use of elliptic
curve cryptography (ECC) in the CMS. curve cryptography (ECC) in the CMS.
The security considerations in [RFC3565] discuss the use of AES in The security considerations in [RFC3565] discuss the use of AES in
the CMS. 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).
10. IANA Considerations 10. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[CNSA] Committee for National Security Systems, "Use of Public
Standards for Secure Information Sharing", CNSSP 15,
October 2016,
<https://www.cnss.gov/CNSS/Issuances/Policies.htm>.
[FIPS180] National Institute of Standards and Technology, "Secure [FIPS180] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS 180-4, August 2015, Hash Standard (SHS)", Federal Information Processing
Standard 180-4, August 2015,
<https://csrc.nist.gov/publications/detail/fips/180/4/ <https://csrc.nist.gov/publications/detail/fips/180/4/
final>. final>.
[FIPS186] National Institute of Standards and Technology, "Digital [FIPS186] National Institute of Standards and Technology, "Digital
Signature Standard", FIPS 186-4, July 2013, Signature Standard", Federal Information Processing
Standard 186-4, July 2013,
<https://csrc.nist.gov/publications/detail/fips/186/4/ <https://csrc.nist.gov/publications/detail/fips/186/4/
final>. final>.
[FIPS197] National Institute of Standards and Technology, "Advanced [FIPS197] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", FIPS 197, November 2001, Encryption Standard (AES)", Federal Information Processing
Standard 197, November 2001,
<https://csrc.nist.gov/publications/detail/fips/197/ <https://csrc.nist.gov/publications/detail/fips/197/
final>. 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, DOI 10.17487/RFC2631, June 1999, RFC 2631, DOI 10.17487/RFC2631, June 1999,
<https://www.rfc-editor.org/info/rfc2631>. <https://www.rfc-editor.org/info/rfc2631>.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
skipping to change at page 17, line 32 skipping to change at page 17, line 23
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016, RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>. <https://www.rfc-editor.org/info/rfc8017>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/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: [SEC1] Standards for Efficient Cryptography Group, "SEC1:
Elliptic Curve Cryptography", September 2000, Elliptic Curve Cryptography", May 2009,
<http://www.secg.org/collateral/sec1_final.pdf>. <https://www.secg.org/sec1-v2.pdf>.
[SP80038A] [SP80038A]
National Institute of Standards and Technology, National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation: "Recommendation for Block Cipher Modes of Operation:
Methods and Techniques", SP 800-38A, December 2001, Methods and Techniques", Special Publication 800-38A,
<https://csrc.nist.gov/publications/detail/sp/800-38a/ December 2001, <https://csrc.nist.gov/publications/detail/
final>. sp/800-38a/final>.
[SP80038D] [SP80038D]
National Institute of Standards and Technology, National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation: "Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", SP 800-38D, November Galois/Counter Mode (GCM) and GMAC", Special
2007, <https://csrc.nist.gov/publications/detail/sp/800- Publication 800-38D, November 2007,
38d/final>. <https://csrc.nist.gov/publications/detail/sp/800-38d/
final>.
[SP80038F] [SP80038F]
National Institute of Standards and Technology, National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation: "Recommendation for Block Cipher Modes of Operation:
Methods for Key Wrapping", SP 800-38F, December 2012, Methods for Key Wrapping", Special Publication 800-38F,
<https://csrc.nist.gov/publications/detail/sp/800-38f/ December 2012, <https://csrc.nist.gov/publications/detail/
final>. sp/800-38f/final>.
[X.208-88] [X208] CCITT, "Recommendation X.208: Specification of Abstract
CCITT, "Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1)", 1988, Syntax Notation One (ASN.1)", 1988,
<https://www.itu.int/rec/T-REC-X.208-198811-W/en>. <https://www.itu.int/rec/T-REC-X.208-198811-W/en>.
[X.209-88] [X209] CCITT, "Recommendation X.209: Specification of Basic
CCITT, "Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1)", Encoding Rules for Abstract Syntax Notation One (ASN.1)",
1988, <https://www.itu.int/rec/T-REC-X.209-198811-W/en>. 1988, <https://www.itu.int/rec/T-REC-X.209-198811-W/en>.
[X.509-88] [X509] CCITT, "Recommendation X.509: The Directory -
CCITT, "Recommendation X.509: The Directory -
Authentication Framework", 1988, Authentication Framework", 1988,
<https://www.itu.int/rec/T-REC-X.509-198811-S>. <https://www.itu.int/rec/T-REC-X.509-198811-S>.
11.2. Informative References 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, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[SP-800-59] [SP80059] National Institute of Standards and Technology, "Guideline
National Institute of Standards and Technology, "Guideline
for Identifying an Information System as a National for Identifying an Information System as a National
Security System", Special Publication 800 59, August 2003, Security System", Special Publication 800-59 , August
<https://csrc.nist.gov/publications/detail/sp/800-59/ > 2003, <https://csrc.nist.gov/publications/detail/sp/800-
final>. 59/final>.
Author's Address Author's Address
Michael Jenkins Michael Jenkins
National Security Agency National Security Agency
Email: mjjenki@nsa.gov Email: mjjenki@nsa.gov
 End of changes. 53 change blocks. 
174 lines changed or deleted 171 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/