idnits 2.17.1 

draft-jenkins-cnsa-smime-profile-03.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  -- The document date (November 26, 2019) is 1612 days in the past.  Is this
     intentional?

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '<CODE BEGINS>' and
     '<CODE ENDS>' lines.


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  -- Looks like a reference, but probably isn't: '0' on line 520

  -- Looks like a reference, but probably isn't: '1' on line 522

  -- Looks like a reference, but probably isn't: '2' on line 524

  -- Looks like a reference, but probably isn't: '3' on line 292


     Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------


2	Internet Engineering Task Force                               M. Jenkins
3	Internet-Draft                                                       NSA
4	Intended status: Informational                         November 26, 2019
5	Expires: May 29, 2020

7	Using Commercial National Security Algorithm Suite Algorithms in Secure/
8	                 Multipurpose Internet Mail Extensions
9	                  draft-jenkins-cnsa-smime-profile-03

11	Abstract

13	   The United States Government has published the NSA Commercial
14	   National Security Algorithm (CNSA) Suite, which defines cryptographic
15	   algorithm policy for national security applications.  This document
16	   specifies the conventions for using the United States National
17	   Security Agency's CNSA Suite algorithms in Secure/Multipurpose
18	   Internet Mail Extensions (S/MIME) as specified in RFC 8551.  It
19	   applies to the capabilities, configuration, and operation of all
20	   components of US National Security Systems that employ S/MIME
21	   messaging.  US National Security Systems are described in NIST
22	   Special Publication 800-59.  It is also appropriate for all other US
23	   Government systems that process high-value information.  It is made
24	   publicly available for use by developers and operators of these and
25	   any other system deployments.

27	Status of This Memo

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

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

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

42	   This Internet-Draft will expire on May 29, 2020.

44	Copyright Notice

46	   Copyright (c) 2019 IETF Trust and the persons identified as the
47	   document authors.  All rights reserved.

49	   This document is subject to BCP 78 and the IETF Trust's Legal
50	   Provisions Relating to IETF Documents
51	   (https://trustee.ietf.org/license-info) in effect on the date of
52	   publication of this document.  Please review these documents
53	   carefully, as they describe your rights and restrictions with respect
54	   to this document.  Code Components extracted from this document must
55	   include Simplified BSD License text as described in Section 4.e of
56	   the Trust Legal Provisions and are provided without warranty as
57	   described in the Simplified BSD License.

59	Table of Contents

61	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
62	   2.  The Commercial National Security Algorithm Suite  . . . . . .   3
63	   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
64	   4.  Requirements and Assumptions  . . . . . . . . . . . . . . . .   4
65	   5.  SHA-384 Message Digest Algorithm  . . . . . . . . . . . . . .   5
66	   6.  Digital Signature . . . . . . . . . . . . . . . . . . . . . .   5
67	     6.1.  ECDSA Signature . . . . . . . . . . . . . . . . . . . . .   5
68	     6.2.  RSA Signature . . . . . . . . . . . . . . . . . . . . . .   6
69	   7.  Key Establishment . . . . . . . . . . . . . . . . . . . . . .   7
70	     7.1.  Elliptic Curve Key Agreement  . . . . . . . . . . . . . .   7
71	     7.2.  RSA Key Transport . . . . . . . . . . . . . . . . . . . .  11
72	   8.  Content Encryption  . . . . . . . . . . . . . . . . . . . . .  13
73	     8.1.  AES-GCM Content Encryption  . . . . . . . . . . . . . . .  13
74	     8.2.  AES-CBC Content Encryption  . . . . . . . . . . . . . . .  14
75	   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
76	   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
77	   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
78	     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
79	     11.2.  Informative References . . . . . . . . . . . . . . . . .  18
80	   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  19

82	1.  Introduction

84	   This document specifies the conventions for using the United States
85	   National Security Agency's Commercial National Security Algorithm
86	   (CNSA) Suite algorithms [CNSA] in Secure/Multipurpose Internet Mail
87	   Extensions (S/MIME) [RFC8551].  It applies to the capabilities,
88	   configuration, and operation of all components of US National
89	   Security Systems that employ S/MIME messaging.  US National Security
90	   Systems are described in NIST Special Publication 800-59 [SP80059].
91	   It is also appropriate for all other US Government systems that
92	   process high-value information.  It is made publicly available for
93	   use by developers and operators of these and any other system
94	   deployments.

96	   S/MIME makes use of the Cryptographic Message Syntax (CMS) [RFC5652]
97	   [RFC5083].  In particular, the signed-data, enveloped-data, and
98	   authenticated-enveloped-data content types are used.  This document
99	   only addresses CNSA Suite compliance for S/MIME.  Other applications
100	   of CMS are outside the scope of this document.

102	   This document does not define any new cryptographic algorithm suite;
103	   instead, it defines a CNSA compliant profile of S/MIME.  Since many
104	   of the CNSA Suite algorithms enjoy uses in other environments as
105	   well, the majority of the conventions needed for these algorithms are
106	   already specified in other documents.  This document references the
107	   source of these conventions, with some relevant details repeated to
108	   aid developers that choose to support the CNSA Suite.  Where details
109	   have been repeated, the cited documents are authoritative.

111	2.  The Commercial National Security Algorithm Suite

113	   The National Security Agency (NSA) profiles commercial cryptographic
114	   algorithms and protocols as part of its mission to support secure,
115	   interoperable communications for US Government National Security
116	   Systems.  To this end, it publishes guidance both to assist with the
117	   US Government transition to new algorithms, and to provide vendors -
118	   and the Internet community in general - with information concerning
119	   their proper use and configuration.

121	   Recently, cryptographic transition plans have become overshadowed by
122	   the prospect of the development of a cryptographically-relevant
123	   quantum computer.  NSA has established the Commercial National
124	   Security Algorithm (CNSA) Suite to provide vendors and IT users near-
125	   term flexibility in meeting their cybersecurity interoperability
126	   requirements.  The purpose behind this flexibility is to avoid
127	   vendors and customers making two major transitions in a relatively
128	   short timeframe, as we anticipate a need to shift to quantum-
129	   resistant cryptography in the near future.

131	   NSA is authoring a set of RFCs, including this one, to provide
132	   updated guidance concerning the use of certain commonly available
133	   commercial algorithms in IETF protocols.  These RFCs can be used in
134	   conjunction with other RFCs and cryptographic guidance (e.g., NIST
135	   Special Publications) to properly protect Internet traffic and data-
136	   at-rest for US Government National Security Systems..

138	3.  Terminology

140	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
141	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
142	   "OPTIONAL" in this document are to be interpreted as described in BCP
143	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
144	   capitals, as shown here.

146	4.  Requirements and Assumptions

148	   CMS values are generated using ASN.1 [X208], the Basic Encoding Rules
149	   (BER) [X209], and the Distinguished Encoding Rules (DER) [X509].

151	   The elliptic curve used in the CNSA Suite is specified in [FIPS186],
152	   and appears in the literature under two different names.  For the
153	   sake of clarity, we list both names below:

155	         Curve       NIST Name    SECG Name    OID  [FIPS186]
156	         ---------------------------------------------------------
157	         nistp384    P-384        secp384r1    1.3.132.0.34

159	   For CNSA Suite applications, public key certificates used to verify
160	   S/MIME signatures MUST be compliant with the CNSA Suite Certificate
161	   and Certificate Revocation List (CRL) Profile specified in [RFC8603].

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

172	   Elliptic Curve Cryptography (ECC) based implementations also require
173	   specification of schemes for key derivation and key wrap.
174	   Requirements for these schemes are in sections Section 7.1.1 and
175	   Section 7.1.2 repectively.

177	   RSA key pairs (public, private) are identified by the modulus size
178	   expressed in bits; RSA-3072 and RSA-4096 are computed using moduli of
179	   3072 bits and 4096 bits, respectively.

181	   RSA signature key pairs used in CNSA Suite compliant implementations
182	   are either RSA-3072 or RSA-4096.  The RSA exponent e MUST satisfy
183	   2^16<e<2^256 and be odd per [FIPS186].

185	   It is recognized that, while the vast majority of RSA signatures are
186	   currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred
187	   RSA signature scheme for new applications is RSASSA-PSS.  CNSA Suite
188	   compliant X.509 certificates will be issued in accordance with

190	   [RFC8603], and while those certificates must be signed and validated
191	   using RSASSA-PKCS1-v1_5, the subject's RSA key pair can be used to
192	   generate and validate signatures appropriate for either signing
193	   scheme.  Where use of RSASSA-PSS is indicated in this document, the
194	   parameters in Section 6.2.2 apply.

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

199	   All implementations use SHA-384 for hashing and either AES-CBC or
200	   AES-GCM for encryption, the requirements for which are given in
201	   Section 5 and Section 8, respectively.

203	5.  SHA-384 Message Digest Algorithm

205	   SHA-384 is the sole CNSA Suite message digest algorithm.  [RFC5754]
206	   specifies the conventions for using SHA-384 with the Cryptographic
207	   Message Syntax (CMS).  CNSA Suite compliant S/MIME implementations
208	   MUST follow the conventions in [RFC5754].

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

214	   The SHA-384 message digest algorithm is defined in FIPS Pub 180
215	   [FIPS180].  The algorithm identifier for SHA-384 is defined in
216	   [RFC5754] as follows:

218	         id-sha384  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
219	             country(16) us(840) organization(1) gov(101) csor(3)
220	             nistalgorithm(4) hashalgs(2) 2 }

222	   For SHA-384, the AlgorithmIdentifier parameters field is OPTIONAL,
223	   and if present, the parameters field MUST contain a NULL.  As
224	   specified in [RFC5754], implementations MUST generate SHA-384
225	   AlgorithmIdentifiers with absent parameters.  Implementations MUST
226	   accept SHA-384 AlgorithmIdentifiers with absent parameters or with
227	   NULL parameters.

229	6.  Digital Signature

231	6.1.  ECDSA Signature

233	   The Elliptic Curve Digital Signature Algorithm (ECDSA) is the CNSA
234	   Suite digital signature algorithm based on ECC.  [RFC5753] specifies
235	   the conventions for using ECDSA with the Cryptographic Message Syntax
236	   (CMS).  CNSA Suite compliant S/MIME implementations MUST follow the
237	   conventions in [RFC5753].

239	   [RFC5480] defines the signature algorithm identifier used in CMS for
240	   ECDSA with SHA-384 as follows:

242	         ecdsa-with-SHA384  OBJECT IDENTIFIER  ::=  { iso(1)
243	            member-body(2) us(840) ansi-X9-62(10045) signatures(4)
244	            ecdsa-with-sha2(3) 3 }

246	   When the ecdsa-with-SHA384 algorithm identifier is used, the
247	   AlgorithmIdentifier parameters field MUST be absent.

249	   When signing, the ECDSA algorithm generates two values, commonly
250	   called r and s.  These two values MUST be encoded using the ECDSA-
251	   Sig-Value type specified in [RFC5480]:

253	         ECDSA-Sig-Value  ::=  SEQUENCE {
254	            r  INTEGER,
255	            s  INTEGER }

257	6.2.  RSA Signature

259	   The RSA signature generation process and the encoding of the result
260	   is either RSASSA-PKCS1-v1_5 or RSA-PSS as described in detail in PKCS
261	   #1 version 2.2 [RFC8017].

263	6.2.1.  RSA-PKCS1-v1_5

265	   [RFC5754] defines the signature algorithm identifier used in CMS for
266	   RSA signature with SHA-384 as follows:

268	         sha384WithRSAEncryption  OBJECT IDENTIFIER  :== { iso(1)
269	           member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 }

271	   When the sha384WithRSAEncryption algorithm identifier is used, the
272	   parameters MUST be NULL.  Implementations MUST accept the parameters
273	   being absent as well as present.

275	6.2.2.  RSA-PSS

277	   [RFC4056] defines the signature algorithm identifier used in CMS for
278	   RSA-PSS signature as follows:

280	         RSASSA-PSS  OBJECT IDENTIFIER  :== { iso(1)
281	           member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 }

283	   The parameters field of an AlgorithmIdentifier that identifies
284	   RSASSA-PSS is defined in [RFC4055] as follows:

286	          RSASSA-PSS-params  ::=  SEQUENCE  {
287	             hashAlgorithm      [0] HashAlgorithm DEFAULT
288	                                       sha1Identifier,
289	             maskGenAlgorithm   [1] MaskGenAlgorithm DEFAULT
290	                                       mgf1SHA1Identifier,
291	             saltLength         [2] INTEGER DEFAULT 20,
292	             trailerField       [3] INTEGER DEFAULT 1  }

294	   The AlgorithmIdentifier parameters field MUST contain RSASSA-PSS-
295	   params with the following values:

297	   o  the hash algorithm MUST be id-sha384 as defined in [RFC8017];

299	   o  the mask generation function MUST use the algorithm identifier
300	      mfg1SHA384Identifier as defined in [RFC4055];

302	   o  the salt length MUST be 48 octets (the same length as the SHA-384
303	      output); and

305	   o  the trailerField MUST have value 1.

307	7.  Key Establishment

309	7.1.  Elliptic Curve Key Agreement

311	   Elliptic Curve Diffie-Hellman (ECDH) is the CNSA Suite key agreement
312	   algorithm.  Since S/MIME is used in store-and-forward communications,
313	   ephemeral-static ECDH is always employed.  This means that the
314	   message originator possesses an ephemeral ECDH key pair and that the
315	   message recipient possesses a static ECDH key pair whose public key
316	   is provided in an X.509 certificate.  The certificate used to obtain
317	   the recipient's public key MUST be compliant with [RFC8603].

319	   When a key agreement algorithm is used, the following steps are
320	   performed:

322	   1.  A content-encryption key (CEK) for a particular content-
323	       encryption algorithm is generated at random.

325	   2.  The recipient's public key and sender's private key are used with
326	       a key agreement scheme to generate a shared secret (Z).

328	   3.  The shared secret is used with a key derivation function (KDF) to
329	       produce a key-encryption key (KEK).

331	   4.  The KEK is used with a key wrap algorithm to encrypt the CEK.

333	   Key derivation is discussed in Section 7.1.1.  Key wrapping is
334	   discussed in Section 7.1.2.

336	   Section 3.1 of [RFC5753] specifies the conventions for using ECDH
337	   with the CMS.  CNSA Suite compliant S/MIME implementations MUST
338	   follow these conventions.

340	   Within the CMS enveloped-data and authenticated-enveloped-data
341	   content types, key agreement algorithm identifiers are located in the
342	   EnvelopedData RecipientInfos KeyAgreeRecipientInfo
343	   keyEncryptionAlgorithm field.

345	   The keyEncryptionAlgorithm field comprises two fields, an algorithm
346	   field and a parameter field.  The algorithm field MUST identify
347	   dhSinglePass-stdDH-sha384kdf-scheme.  The algorithm identifier for
348	   the dhSinglePass-stdDH-sha384kdf-scheme, repeated from Section 7.1.4
349	   of [RFC5753], is:

351	         dhSinglePass-stdDH-sha384kdf-scheme  OBJECT IDENTIFIER  ::=
352	             { iso(1) identified-organization(3) certicom(132)
353	               schemes(1) 11 2 }

355	   The keyEncryptionAlgorithm parameter field MUST be constructed as
356	   described in Section 7.1.2.

358	7.1.1.  Key Derivation Functions

360	   KDFs based on SHA-384 are used to derive a pairwise key-encryption
361	   key from the shared secret produced by ephemeral-static ECDH.
362	   Sections 7.1.8 and 7.2 of [RFC5753] specify the CMS conventions for
363	   using a KDF with the shared secret generated during ephemeral-static
364	   ECDH.  CNSA Suite compliant S/MIME implementations MUST follow these
365	   conventions.

367	   As specified in Section 7.1.8 of [RFC5753], the ANSI-X9.63-KDF
368	   described in Section 3.6.1 of [SEC1] and based on SHA-384 MUST be
369	   used.

371	   As specified in Section 7.2 of [RFC5753], when using ECDH with the
372	   CMS enveloped-data or authenticated-enveloped-data content type, the
373	   derivation of key-encryption keys makes use of the ECC-CMS-SharedInfo
374	   type:

376	         ECC-CMS-SharedInfo  ::=  SEQUENCE {
377	            keyInfo      AlgorithmIdentifier,
378	            entityUInfo  [0] EXPLICIT OCTET STRING OPTIONAL,
379	            suppPubInfo  [2] EXPLICIT OCTET STRING }

381	   In CNSA Suite for S/MIME, the fields of ECC-CMS-SharedInfo are used
382	   as follows:

384	      keyInfo contains the object identifier of the key-encryption
385	      algorithm used to wrap the content-encryption key.  If AES-256 Key
386	      Wrap is used, then the keyInfo will contain id-aes256-wrap-pad,
387	      and the parameters will be absent.

389	      entityUInfo optionally contains a random value provided by the
390	      message originator.  If user keying material (ukm) is included in
391	      the KeyAgreeRecipientInfo, then the entityUInfo MUST be present,
392	      and it MUST contain the ukm value.  If the ukm is not present,
393	      then the entityUInfo MUST be absent.

395	      suppPubInfo contains the length of the generated key-encryption
396	      key, in bits, represented as a 32-bit unsigned number, as
397	      described in [RFC2631].  When a 256-bit AES key is used, the
398	      length MUST be 0x00000100.

400	   ECC-CMS-SharedInfo is DER encoded and used as input to the key
401	   derivation function, as specified in Section 3.6.1 of [SEC1].  Note
402	   that ECC-CMS-SharedInfo differs from the OtherInfo specified in
403	   [RFC2631].  Here, a counter value is not included in the keyInfo
404	   field because the KDF specified in [SEC1] ensures that sufficient
405	   keying data is provided.

407	   The KDF specified in Section 3.6.1 of [SEC1] describes how to
408	   generate an essentially arbitrary amount of keying material from a
409	   shared secret, Z, produced by ephemeral-static ECDH.  To generate an
410	   L-bit key-encryption key (KEK), KM is computed:

412	         KM(Counter) = Hash ( Z || Counter || ECC-CMS-SharedInfo )

414	   incrementing Counter appropriately, until enough material has been
415	   generated.  The KM blocks are concatenated left to right, as they are
416	   generated, and the first (leftmost) L bits are used as the KEK:

418	         KEK = the leftmost L bits of
419	                  [KM ( counter=1 ) || KM ( counter=2 ) ...]

421	   In CNSA Suite for S/MIME, the elements of the KDF are defined as
422	   follows:

424	      Hash is a one-way hash function.  The SHA-384 hash MUST be used.

426	      Z is the shared secret value generated during ephemeral-static
427	      ECDH.  Z MUST be exactly 384 bits, i.e., leading zero bits MUST be
428	      preserved.

430	      Counter is a 32-bit unsigned number, represented in network byte
431	      order.  Its initial value MUST be 0x00000001 for any key
432	      derivation operation.

434	      ECC-CMS-SharedInfo is composed as described above.  It MUST be DER
435	      encoded.

437	   In CNSA Suite for S/MIME, exactly one iteration is needed; the
438	   Counter is not incremented.  The key-encryption key (KEK) MUST be the
439	   first (leftmost) 256 bits of the SHA-384 output value:

441	         KEK = the leftmost 256 bits of
442	                  SHA-384 ( Z || 0x00000001 || ECC-CMS-SharedInfo )

444	   Note that the only source of secret entropy in this computation is Z.

446	7.1.2.  AES Key Wrap

448	   The AES Key Wrap with Padding key-encryption algorithm, as specified
449	   in [RFC5649] and [SP80038F], is used to encrypt the content-
450	   encryption key with a pairwise key-encryption key that is generated
451	   using ephemeral-static ECDH.  Section 8 of [RFC5753] specifies the
452	   CMS conventions for using AES Key Wrap with a pairwise key generated
453	   through ephemeral-static ECDH.  CNSA Suite compliant S/MIME
454	   implementations MUST follow these conventions.

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

461	   The KeyWrapAlgorithm MUST be id-aes256-wrap-pad.  The required
462	   algorithm identifier, specified in [RFC5649], is:

464	         id-aes256-wrap-pad  OBJECT IDENTIFIER ::=  { joint-iso-itu-t(2)
465	            country(16) us(840) organization(1) gov(101) csor(3)
466	            nistAlgorithm(4) aes(1) 48 }

468	7.2.  RSA Key Transport

470	   RSA encryption (RSA) is the CNSA Suite key transport algorithm.  The
471	   RSA key transport algorithm is the RSA encryption scheme defined in
472	   [RFC8017], where the message to be encrypted is the content-
473	   encryption key.

475	   The recipient of an S/MIME message possesses an RSA key pair whose
476	   public key is represented by an X.509 certificate.  The certificate
477	   used to obtain the recipient's public key MUST be compliant with
478	   [RFC8603].  These certificates are suitable for use with either
479	   RSAES-OAEP or RSAES-PKCS1-v1_5.

481	7.2.1.  RSAES-PKCS1-v1_5

483	   Section 4.2 of [RFC3370] specifies the conventions for using RSAES-
484	   PKCS1-v1_5 with the CMS.  S/MIME implementations employing this form
485	   of key transport MUST follow these conventions.

487	   Within the CMS enveloped-data and authenticated-enveloped-data
488	   content types, key transport algorithm identifiers are located in the
489	   EnvelopedData RecipientInfos KeyTransRecipientInfo
490	   keyEncryptionAlgorithm field.

492	   The algorithm identifier for RSA (PKCS #1 v1.5) is:

494	         rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
495	             us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

497	   The AlgorithmIdentifier parameters field MUST be present, and the
498	   parameters field MUST contain NULL.

500	7.2.2.  RSAES-OAEP

502	   [RFC3560] specifies the conventions for using RSAES-OAEP with the
503	   CMS.  CNSA Suite compliant S/MIME implementations employing this form
504	   of key transport MUST follow these conventions.

506	   Within the CMS enveloped-data and authenticated-enveloped-data
507	   content types, key transport algorithm identifiers are located in the
508	   EnvelopedData RecipientInfos KeyTransRecipientInfo
509	   keyEncryptionAlgorithm field.

511	   The algorithm identifier for RSA (OAEP) is:

513	         id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { iso(1) member-body(2)
514	             us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }

516	   The parameters field of an AlgorithmIdentifier that identifies RSAES-
517	   OAEP is defined in [RFC4055] as follows:

519	          RSAES-OAEP-params  ::=  SEQUENCE  {
520	             hashFunc          [0] AlgorithmIdentifier DEFAULT
521	                                      sha1Identifier,
522	             maskGenFunc       [1] AlgorithmIdentifier DEFAULT
523	                                      mgf1SHA1Identifier,
524	             pSourceFunc       [2] AlgorithmIdentifier DEFAULT
525	                                      pSpecifiedEmptyIdentifier  }

527	          pSpecifiedEmptyIdentifier  AlgorithmIdentifier  ::=
528	                               { id-pSpecified, nullOctetString }

530	          nullOctetString  OCTET STRING (SIZE (0))  ::=  { ''H }

532	   The AlgorithmIdentifier parameters field MUST be present, and the
533	   parameters field MUST contain RSAES-OAEP-params with values as
534	   follows:

536	   o  the hashFunc algorithm must be id-sha384 as defined in [RFC8017];
537	   o  the mask generation function must use the algorithm identifier
538	      mfg1SHA384Identifier as defined in [RFC4055];

540	   o  the pSourceFunc field must be absent.

542	   The SMIMECapabilities signed attribute is used to specify a partial
543	   list of algorithms that the software announcing the SMIMECapabilities
544	   can support.  If the SMIMECapabilities signed attribute is included
545	   to announce support for the RSAES-OAEP algorithm, it MUST be
546	   constructed as defined in Section 5 of [RFC3560], with the sequence
547	   representing the rSAES-OAEP-SHA384-Identifier.

549	8.  Content Encryption

551	   AES-GCM is the preferred mode for CNSA Suite applications as
552	   described in the Security Considerations (Section 9).  AES-CBC is
553	   acceptable where AES-GCM is not yet available.

555	8.1.  AES-GCM Content Encryption

557	   CNSA Suite compliant S/MIME implementations using the authenticated-
558	   enveloped-data content type [RFC5083] MUST use AES [FIPS197] in
559	   Galois Counter Mode (GCM) [SP80038D] as the content-authenticated
560	   encryption algorithm, and MUST follow the conventions for using AES-
561	   GCM with the CMS defined in [RFC5084].

563	   Within the CMS authenticated-enveloped-data content type, content-
564	   authenticated encryption algorithm identifiers are located in the
565	   AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm
566	   field.  The content-authenticated encryption algorithm is used to
567	   encipher the content located in the AuthEnvelopedData
568	   EncryptedContentInfo encryptedContent field.

570	   The AES-GCM content-authenticated encryption algorithm is described
571	   in [FIPS197] and [SP80038D].  The algorithm identifier for AES-256 in
572	   GCM mode is:

574	            id-aes256-GCM  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
575	               country(16) us(840) organization(1) gov(101) csor(3)
576	               nistAlgorithm(4) aes(1) 46 }

578	   The AlgorithmIdentifier parameters field MUST be present, and the
579	   parameters field must contain GCMParameters:

581	         GCMParameters ::= SEQUENCE {
582	           aes-nonce        OCTET STRING,
583	           aes-ICVlen       AES-GCM-IVClen DEFAULT 12 }

585	   The authentication tag length (aes-ICVlen) SHALL be 16 (indicating a
586	   tag length of 128 bits).

588	   The initialization vector (aes-nonce) MUST be generated in accordance
589	   with Section 8.2 of [SP80038D].  AES-GCM loses security
590	   catastrophically if a nonce is reused with a given key on more than
591	   one distinct set of input data.  Therefore, a fresh content-
592	   authenticated encryption key MUST be generated for each message.

594	8.2.  AES-CBC Content Encryption

596	   CNSA Suite compliant S/MIME implementations using the enveloped-data
597	   content type MUST use AES-256 [FIPS197] in Cipher Block Chaining
598	   (CBC) mode [SP80038A] as the content encryption algorithm, and MUST
599	   follow the conventions for using AES with the CMS defined in
600	   [RFC3565].

602	   Within the CMS enveloped-data content type, content-encryption
603	   algorithm identifiers are located in the EnvelopedData
604	   EncryptedContentInfo contentEncryptionAlgorithm field.  The content-
605	   encryption algorithm is used to encipher the content located in the
606	   EnvelopedData EncryptedContentInfo encryptedContent field.

608	   The AES CBC content-encryption algorithm is described in [FIPS197]
609	   and [SP80038A].  The algorithm identifier for AES-256 in CBC mode is:

611	         id-aes256-CBC  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
612	            country(16) us(840) organization(1) gov(101) csor(3)
613	            nistAlgorithm(4) aes(1) 42 }

615	   The AlgorithmIdentifier parameters field MUST be present, and the
616	   parameters field must contain AES-IV:

618	         AES-IV  ::=  OCTET STRING (SIZE(16))

620	   The 16-octet initialization vector is generated at random by the
621	   originator.  See [RFC4086] for guidance on generation of random
622	   values.

624	9.  Security Considerations

626	   This document specifies the conventions for using the NSA's CNSA
627	   Suite algorithms in S/MIME.  All of the algorithms and algorithm
628	   identifiers have been specified in previous documents.

630	   See [RFC4086] for guidance on generation of random values.

632	   The security considerations in [RFC5652] discuss the CMS as a method
633	   for digitally signing data and encrypting data.

635	   The security considerations in [RFC3370] discuss cryptographic
636	   algorithm implementation concerns in the context of the CMS.

638	   The security considerations in [RFC5753] discuss the use of elliptic
639	   curve cryptography (ECC) in the CMS.

641	   The security considerations in [RFC3565] discuss the use of AES in
642	   the CMS.

644	   The security considerations in [RFC8551] apply to this profile, in
645	   particular the recommendation to use authenticated encryption modes
646	   (i.e. use authenticated-enveloped-data with AES-GCM rather than
647	   enveloped-data with AES-CBC).

649	10.  IANA Considerations

651	   This document has no IANA actions.

653	11.  References

655	11.1.  Normative References

657	   [CNSA]     Committee for National Security Systems, "Use of Public
658	              Standards for Secure Information Sharing", CNSSP 15,
659	              October 2016,
660	              <https://www.cnss.gov/CNSS/Issuances/Policies.htm>.

662	   [FIPS180]  National Institute of Standards and Technology, "Secure
663	              Hash Standard (SHS)", Federal Information Processing
664	              Standard 180-4, August 2015,
665	              <https://csrc.nist.gov/publications/detail/fips/180/4/
666	              final>.

668	   [FIPS186]  National Institute of Standards and Technology, "Digital
669	              Signature Standard", Federal Information Processing
670	              Standard 186-4, July 2013,
671	              <https://csrc.nist.gov/publications/detail/fips/186/4/
672	              final>.

674	   [FIPS197]  National Institute of Standards and Technology, "Advanced
675	              Encryption Standard (AES)", Federal Information Processing
676	              Standard 197, November 2001,
677	              <https://csrc.nist.gov/publications/detail/fips/197/
678	              final>.

680	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
681	              Requirement Levels", BCP 14, RFC 2119,
682	              DOI 10.17487/RFC2119, March 1997,
683	              <https://www.rfc-editor.org/info/rfc2119>.

685	   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
686	              RFC 2631, DOI 10.17487/RFC2631, June 1999,
687	              <https://www.rfc-editor.org/info/rfc2631>.

689	   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
690	              Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002,
691	              <https://www.rfc-editor.org/info/rfc3370>.

693	   [RFC3560]  Housley, R., "Use of the RSAES-OAEP Key Transport
694	              Algorithm in Cryptographic Message Syntax (CMS)",
695	              RFC 3560, DOI 10.17487/RFC3560, July 2003,
696	              <https://www.rfc-editor.org/info/rfc3560>.

698	   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
699	              Encryption Algorithm in Cryptographic Message Syntax
700	              (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,
701	              <https://www.rfc-editor.org/info/rfc3565>.

703	   [RFC4055]  Schaad, J., Kaliski, B., and R. Housley, "Additional
704	              Algorithms and Identifiers for RSA Cryptography for use in
705	              the Internet X.509 Public Key Infrastructure Certificate
706	              and Certificate Revocation List (CRL) Profile", RFC 4055,
707	              DOI 10.17487/RFC4055, June 2005,
708	              <https://www.rfc-editor.org/info/rfc4055>.

710	   [RFC4056]  Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in
711	              Cryptographic Message Syntax (CMS)", RFC 4056,
712	              DOI 10.17487/RFC4056, June 2005,
713	              <https://www.rfc-editor.org/info/rfc4056>.

715	   [RFC5083]  Housley, R., "Cryptographic Message Syntax (CMS)
716	              Authenticated-Enveloped-Data Content Type", RFC 5083,
717	              DOI 10.17487/RFC5083, November 2007,
718	              <https://www.rfc-editor.org/info/rfc5083>.

720	   [RFC5084]  Housley, R., "Using AES-CCM and AES-GCM Authenticated
721	              Encryption in the Cryptographic Message Syntax (CMS)",
722	              RFC 5084, DOI 10.17487/RFC5084, November 2007,
723	              <https://www.rfc-editor.org/info/rfc5084>.

725	   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
726	              "Elliptic Curve Cryptography Subject Public Key
727	              Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
728	              <https://www.rfc-editor.org/info/rfc5480>.

730	   [RFC5649]  Housley, R. and M. Dworkin, "Advanced Encryption Standard
731	              (AES) Key Wrap with Padding Algorithm", RFC 5649,
732	              DOI 10.17487/RFC5649, September 2009,
733	              <https://www.rfc-editor.org/info/rfc5649>.

735	   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
736	              RFC 5652, DOI 10.17487/RFC5652, September 2009,
737	              <https://www.rfc-editor.org/info/rfc5652>.

739	   [RFC5753]  Turner, S. and D. Brown, "Use of Elliptic Curve
740	              Cryptography (ECC) Algorithms in Cryptographic Message
741	              Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January
742	              2010, <https://www.rfc-editor.org/info/rfc5753>.

744	   [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic
745	              Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
746	              2010, <https://www.rfc-editor.org/info/rfc5754>.

748	   [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
749	              "PKCS #1: RSA Cryptography Specifications Version 2.2",
750	              RFC 8017, DOI 10.17487/RFC8017, November 2016,
751	              <https://www.rfc-editor.org/info/rfc8017>.

753	   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
754	              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
755	              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

757	   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
758	              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
759	              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
760	              April 2019, <https://www.rfc-editor.org/info/rfc8551>.

762	   [RFC8603]  Jenkins, M. and L. Zieglar, "Commercial National Security
763	              Algorithm (CNSA) Suite Certificate and Certificate
764	              Revocation List (CRL) Profile", RFC 8603,
765	              DOI 10.17487/RFC8603, May 2019,
766	              <https://www.rfc-editor.org/info/rfc8603>.

768	   [SEC1]     Standards for Efficient Cryptography Group, "SEC1:
769	              Elliptic Curve Cryptography", May 2009,
770	              <https://www.secg.org/sec1-v2.pdf>.

772	   [SP80038A]
773	              National Institute of Standards and Technology,
774	              "Recommendation for Block Cipher Modes of Operation:
775	              Methods and Techniques", Special Publication 800-38A,
776	              December 2001, <https://csrc.nist.gov/publications/detail/
777	              sp/800-38a/final>.

779	   [SP80038D]
780	              National Institute of Standards and Technology,
781	              "Recommendation for Block Cipher Modes of Operation:
782	              Galois/Counter Mode (GCM) and GMAC", Special
783	              Publication 800-38D, November 2007,
784	              <https://csrc.nist.gov/publications/detail/sp/800-38d/
785	              final>.

787	   [SP80038F]
788	              National Institute of Standards and Technology,
789	              "Recommendation for Block Cipher Modes of Operation:
790	              Methods for Key Wrapping", Special Publication 800-38F,
791	              December 2012, <https://csrc.nist.gov/publications/detail/
792	              sp/800-38f/final>.

794	   [X208]     CCITT, "Recommendation X.208: Specification of Abstract
795	              Syntax Notation One (ASN.1)", 1988,
796	              <https://www.itu.int/rec/T-REC-X.208-198811-W/en>.

798	   [X209]     CCITT, "Recommendation X.209: Specification of Basic
799	              Encoding Rules for Abstract Syntax Notation One (ASN.1)",
800	              1988, <https://www.itu.int/rec/T-REC-X.209-198811-W/en>.

802	   [X509]     CCITT, "Recommendation X.509: The Directory -
803	              Authentication Framework", 1988,
804	              <https://www.itu.int/rec/T-REC-X.509-198811-S>.

806	11.2.  Informative References

808	   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
809	              "Randomness Requirements for Security", BCP 106, RFC 4086,
810	              DOI 10.17487/RFC4086, June 2005,
811	              <https://www.rfc-editor.org/info/rfc4086>.

813	   [SP80059]  National Institute of Standards and Technology, "Guideline
814	              for Identifying an Information System as a National
815	              Security System", Special Publication 800-59 , August
816	              2003, <https://csrc.nist.gov/publications/detail/sp/800-
817	              59/final>.

819	Author's Address

821	   Michael Jenkins
822	   National Security Agency

824	   Email: mjjenki@nsa.gov