idnits 2.17.1 

draft-jenkins-cnsa-smime-profile-00.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 (March 6, 2019) is 1876 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
  ----------------------------------------------------------------------------

  == Missing Reference: 'CNSSP15' is mentioned on line 134, but not defined

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

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

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

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

  == Outdated reference: A later version (-06) exists of
     draft-jenkins-cnsa-cert-crl-profile-01


     Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 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                             March 6, 2019
5	Expires: September 7, 2019

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

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 September 7, 2019.

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 Agreement . . . . . . . . . . . . . . . . . . . . . . . .   7
70	     7.1.  Elliptic Curve Key Exchange . . . . . . . . . . . . . . .   7
71	     7.2.  RSA Key Transport . . . . . . . . . . . . . . . . . . . .  11
72	   8.  Content Encryption  . . . . . . . . . . . . . . . . . . . . .  13
73	     8.1.  AES-CBC Content Encryption  . . . . . . . . . . . . . . .  13
74	     8.2.  AES-GCM Content Encryption  . . . . . . . . . . . . . . .  13
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  . . . . . . . . . . . . . . . . . . . . . . . .  18

82	1.  Introduction

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

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

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

110	2.  The Commercial National Security Algorithm Suite

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

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

130	   Transition to post-quantum algorithms will occur after NIST has
131	   completed their evaluation and standardization.  In the meantime, NSA
132	   is publishing a set of RFCs, including this one, to provide updated
133	   guidance concerning the use of certain commonly available commercial
134	   algorithms [CNSSP15] in IETF protocols.  These RFCs can be used in
135	   conjunction with other RFCs and cryptographic guidance (e.g., NIST
136	   Special Publications) to properly protect Internet traffic and data-
137	   at-rest.

139	3.  Terminology

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

147	4.  Requirements and Assumptions

149	   CMS values are generated using ASN.1 [X.208-88], the Basic Encoding
150	   Rules (BER) [X.209-88], and the Distinguished Encoding Rules (DER)
151	   [X.509-88].

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

157	         Curve       NIST Name    SECG Name    OID  [FIPS186]
158	         ---------------------------------------------------------
159	         nistp384    P-384        secp384r1    1.3.132.0.34

161	   For CNSA Suite applications, public key certificates used to verify
162	   S/MIME signatures MUST be compliant with the CNSA Suite Certificate
163	   and CRL Profile specified in [ID.cnsa-cert-profile].

165	   Within the CMS signed-data content type, signature algorithm
166	   identifiers are located in the SignerInfo signatureAlgorithm field of
167	   SignedData.  In addition, signature algorithm identifiers are located
168	   in the SignerInfo signatureAlgorithm field of countersignature
169	   attributes.

171	   ECC based implementations also require specification of schemes for
172	   key derivation and key wrap.  Requirements for these schemes are in
173	   sections Section 7.1.2 and Section 7.1.1 repectively.

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

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

183	   It is recognized that, while the vast majority of RSA signatures are
184	   currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred
185	   RSA signature scheme for new applications is RSASSA-PSS.  CNSA Suite
186	   compliant X.509 certificates will be issued in accordance with
187	   [ID.cnsa-cert-profile], and while those certificates must be signed
188	   and validated using RSASSA-PKCS1-v1_5, the subject's RSA key pair can
189	   be used to generate and validate signatures appropriate for either
190	   signing scheme.  Where use of RSASSA-PSS is indicated in this
191	   document, the parameters in Section 6.2.2 apply.

193	   This document assumes that required trust anchors have been securely
194	   provisioned to the client.

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

200	5.  SHA-384 Message Digest Algorithm

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

207	   Within the CMS signed-data content type, message digest algorithm
208	   identifiers are located in the SignedData digestAlgorithms field and
209	   the SignerInfo digestAlgorithm field.

211	   The SHA-384 message digest algorithm is defined in FIPS Pub 180
212	   [FIPS180].  The algorithm identifier for SHA-384 is defined in
213	   [RFC5754] as follows:

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

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

226	6.  Digital Signature

228	6.1.  ECDSA Signature

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

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

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

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

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

251	         ECDSA-Sig-Value  ::=  SEQUENCE {
252	            r  INTEGER,
253	            s  INTEGER }

255	6.2.  RSA Signature

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

261	6.2.1.  RSA-PKCS1-v1_5

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

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

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

273	6.2.2.  RSA-PSS

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

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

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

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

292	   The AlgorithmIdentifier parameters field MUST contain RSASSA-PSS-
293	   params with the following values:

295	   o  the hash algorithm must be id-sha384 as defined in [RFC8017];

297	   o  the mask generation function must use the algorithm identifier
298	      mfg1SHA384Identifier as defined in [RFC4055];

300	   o  the salt length must be 48 octets; and

302	   o  the trailerField must have value 1.

304	7.  Key Agreement

306	7.1.  Elliptic Curve Key Exchange

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

317	   When a key agreement algorithm is used, a key-encryption algorithm is
318	   also needed.  In the CNSA Suite for S/MIME, the Advanced Encryption
319	   Standard (AES) Key Wrap with Padding Algorithm, as specified in
320	   [RFC5649] and [SP80038F], MUST be used as the key-encryption
321	   algorithm.  AES Key Wrap is discussed further in Section 7.1.1.  The
322	   key-encryption key used with the AES Key Wrap algorithm is obtained
323	   from a key derivation function (KDF).  In the CNSA Suite for S/MIME,
324	   the KDF described in Section 7.1.2 -- based on SHA-384 -- MUST be
325	   used.

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

331	   Within the CMS enveloped-data and authenticated-enveloped-data
332	   content types, key agreement algorithm identifiers are located in the
333	   EnvelopedData RecipientInfos KeyAgreeRecipientInfo
334	   keyEncryptionAlgorithm field.

336	   The keyEncryptionAlgorithm MUST be dhSinglePass-stdDH-sha384kdf-
337	   scheme, and the keyEncryptionAlgorithm parameter MUST be a
338	   KeyWrapAlgorithm containing id-aes256-wrap-pad (see Section 7.1.1).
339	   The key wrap algorithm denotes the symmetric encryption algorithm
340	   used to encrypt the randomly generated content-encryption key,
341	   employing the pairwise key-encryption key generated using the
342	   ephemeral-static ECDH key agreement algorithm (see Section 7.1.2).

344	   The algorithm identifier for the dhSinglePass-stdDH-sha384kdf-scheme,
345	   repeated from Section 7.1.4 of [RFC5753], is:

347	         dhSinglePass-stdDH-sha384kdf-scheme  OBJECT IDENTIFIER  ::=
348	             { iso(1) identified-organization(3) certicom(132)
349	               schemes(1) 11 2 }

351	   with KeyWrapAlgorithm as the type for its parameter:

353	         KeyWrapAlgorithm  ::=  AlgorithmIdentifier

355	7.1.1.  AES Key Wrap

357	   The AES Key Wrap with Padding key-encryption algorithm, as specified
358	   in [RFC5649] and [SP80038F], is used to encrypt the content-
359	   encryption key with a pairwise key-encryption key that is generated
360	   using ephemeral-static ECDH.  Section 8 of [RFC5753] specifies the
361	   CMS conventions for using AES Key Wrap with a pairwise key generated
362	   through ephemeral-static ECDH.  CNSA Suite compliant S/MIME
363	   implementations MUST follow these conventions.

365	   Within the CMS enveloped-data content type, key wrap algorithm
366	   identifiers are located in the KeyWrapAlgorithm parameters within the
367	   EnvelopedData RecipientInfos KeyAgreeRecipientInfo
368	   keyEncryptionAlgorithm field.

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

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

377	7.1.2.  Key Derivation Functions

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

386	   The KDF based on SHA-384 MUST be used.

388	   As specified in Section 7.2 of [RFC5753], using ECDH with the CMS
389	   enveloped-data or authenticated-enveloped-data content type, the
390	   derivation of key-encryption keys makes use of the ECC-CMS-SharedInfo
391	   type:

393	         ECC-CMS-SharedInfo  ::=  SEQUENCE {
394	            keyInfo      AlgorithmIdentifier,
395	            entityUInfo  [0] EXPLICIT OCTET STRING OPTIONAL,
396	            suppPubInfo  [2] EXPLICIT OCTET STRING }

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

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

406	      entityUInfo optionally contains a random value provided by the
407	      message originator.  If the user keying material (ukm) is present,
408	      then the entityUInfo MUST be present, and it MUST contain the ukm
409	      value.  If the ukm is not present, then the entityUInfo MUST be
410	      absent.

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

417	   ECC-CMS-SharedInfo is DER encoded and used as input to the key
418	   derivation function, as specified in Section 3.6.1 of [SEC1].  Note
419	   that ECC-CMS-SharedInfo differs from the OtherInfo specified in
420	   [RFC2631].  Here, a counter value is not included in the keyInfo
421	   field because the KDF specified in [SEC1] ensures that sufficient
422	   keying data is provided.

424	   The KDF specified in [SEC1] provides an algorithm for generating an
425	   essentially arbitrary amount of keying material (KM) from a shared
426	   secret, Z, produced by ephemeral-static ECDH.  The KDF generates
427	   successive blocks of keying material, KM(1), KM(2), and so on, using:

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

431	   To generate an L-bit key-encryption key (KEK), one or more KM blocks
432	   are generated, incrementing Counter appropriately, until enough
433	   material has been generated.  The KM blocks are concatenated left to
434	   right, as they are generated, and the first (leftmost) L bits are
435	   used as the KEK:

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

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

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

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

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

453	      ECC-CMS-SharedInfo is composed as described above.  It MUST be DER
454	      encoded.

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

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

463	   In CNSA Suite for S/MIME, the key-encryption key MUST be the most
464	   significant 256 bits of the SHA-384 output value.

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

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], block type is 02, where the message to be encrypted is the
473	   content-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	   [ID.cnsa-cert-profile].  These certificates are suitable for use with
479	   either 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 content type, key transport algorithm
488	   identifiers are located in the EnvelopedData RecipientInfos
489	   KeyTransRecipientInfo keyEncryptionAlgorithm field.

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

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

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

499	7.2.2.  RSAES-OAEP

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

505	   Within the CMS enveloped-data content type, key transport algorithm
506	   identifiers are located in the EnvelopedData RecipientInfos
507	   KeyTransRecipientInfo keyEncryptionAlgorithm field.

509	   The algorithm identifier for RSA (OAEP) is:

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

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

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

525	          pSpecifiedEmptyIdentifier  AlgorithmIdentifier  ::=
526	                               { id-pSpecified, nullOctetString }

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

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

534	   o  the hashFunc algorithm must be id-sha384 as defined in [RFC8017];

536	   o  the mask generation function must use the algorithm identifier
537	      mfg1SHA384Identifier as defined in [RFC4055];

539	   o  the pSourceFunc field must be absent.

541	   If the SMIMECapabilities signed attribute is included to announce
542	   support for the RSAES-OAEP algorithm, it MUST be constructed as
543	   defined in Section 5 of [RFC3560], with the sequence representing the
544	   rSAES-OAEP-SHA384-Identifier.

546	8.  Content Encryption

548	8.1.  AES-CBC Content Encryption

550	   CNSA Suite compliant S/MIME implementations MUST use AES-256
551	   [FIPS197] in Cipher Block Chaining (CBC) mode [SP80038A] as the
552	   content encryption algorithm when using the enveloped-data content
553	   type, and MUST follow the conventions for using AES with the CMS
554	   defined in [RFC3565].

556	   Within the CMS enveloped-data content type, content-encryption
557	   algorithm identifiers are located in the EnvelopedData
558	   EncryptedContentInfo contentEncryptionAlgorithm field.  The content-
559	   encryption algorithm is used to encipher the content located in the
560	   EnvelopedData EncryptedContentInfo encryptedContent field.

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

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

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

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

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

578	8.2.  AES-GCM Content Encryption

580	   CNSA Suite compliant S/MIME implementations MUST use AES [FIPS197] in
581	   Galois Counter Mode (GCM) [SP80038D] as the content-authenticated
582	   encryption algorithm when using the authenticated-enveloped-data
583	   content type [RFC5083], and MUST follow the conventions for using
584	   AES-GCM with the CMS defined in [RFC5084].

586	   In CNSA Suite for S/MIME AES-256 in GCM mode MUST be used.

588	   Within the CMS authenticated-enveloped-data content type, content-
589	   authenticated encryption algorithm identifiers are located in the
590	   AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm
591	   field.  The content-authenticated encryption algorithm is used to
592	   encipher the content located in the AuthEnvelopedData
593	   EncryptedContentInfo encryptedContent field.

595	   The AES-GCM content-authenticated encryption algorithm is described
596	   in [FIPS197] and [SP80038D].  The algorithm identifier for AES-256 in
597	   GCM mode is:

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

603	   The AlgorithmIdentifier parameters field MUST be present, and the
604	   parameters field must contain GCMParameters:

606	         GCMParameters ::= SEQUENCE {
607	           aes-nonce        OCTET STRING,
608	           aes-ICVlen       AES-GCM-IVClen DEFAULT 12 }

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

613	   The initialization vector (aes-nonce) MUST be generated in accordance
614	   with [SP80038D].  AES-GCM loses security catastrophically if a nonce
615	   is reused with a given key on more than one distinct set of input
616	   data.  Therefore, a fresh content-authenticated encryption key MUST
617	   be generated for each message.

619	9.  Security Considerations

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

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

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

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

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

636	   The security considerations in [RFC3565] discuss the use of AES in
637	   the CMS.

639	10.  IANA Considerations

641	   This document has no IANA actions.

643	11.  References

645	11.1.  Normative References

647	   [FIPS180]  National Institute of Standards and Technology, "Secure
648	              Hash Standard (SHS)", FIPS 180-4, August 2015,
649	              <https://csrc.nist.gov/publications/detail/fips/180/4/
650	              final>.

652	   [FIPS186]  National Institute of Standards and Technology, "Digital
653	              Signature Standard", FIPS 186-4, July 2013,
654	              <https://csrc.nist.gov/publications/detail/fips/186/4/
655	              final>.

657	   [FIPS197]  National Institute of Standards and Technology, "Advanced
658	              Encryption Standard (AES)", FIPS 197, November 2001,
659	              <https://csrc.nist.gov/publications/detail/fips/197/
660	              final>.

662	   [ID.cnsa-cert-profile]
663	              Jenkins, M. and L. Zieglar, "Commercial National Security
664	              Algorithms (CNSA) Suite Certificate and Certificate
665	              Revocation List (CRL) Profile", January 2018,
666	              <https://www.ietf.org/internet-drafts/
667	              draft-jenkins-cnsa-cert-crl-profile-01>.

669	              Work in progress.

671	   [ID.rfc5751-bis]
672	              Schaad, J., Ramsdell, B., and S. Turner, "Secure/
673	              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
674	              Message Specification", September 2018,
675	              <https://datatracker.ietf.org/doc/
676	              draft-ietf-lamps-rfc5751-bis>.

678	              Work in progress.

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	   [SEC1]     Standards for Efficient Cryptography Group, "SEC1:
758	              Elliptic Curve Cryptography", September 2000,
759	              <http://www.secg.org/collateral/sec1_final.pdf>.

761	   [SP80038A]
762	              National Institute of Standards and Technology,
763	              "Recommendation for Block Cipher Modes of Operation:
764	              Methods and Techniques", SP 800-38A, December 2001,
765	              <https://csrc.nist.gov/publications/detail/sp/800-38a/
766	              final>.

768	   [SP80038D]
769	              National Institute of Standards and Technology,
770	              "Recommendation for Block Cipher Modes of Operation:
771	              Galois/Counter Mode (GCM) and GMAC", SP 800-38D, November
772	              2007, <https://csrc.nist.gov/publications/detail/sp/800-
773	              38d/final>.

775	   [SP80038F]
776	              National Institute of Standards and Technology,
777	              "Recommendation for Block Cipher Modes of Operation:
778	              Methods for Key Wrapping", SP 800-38F, December 2012,
779	              <https://csrc.nist.gov/publications/detail/sp/800-38f/
780	              final>.

782	   [X.208-88]
783	              CCITT, "Recommendation X.208: Specification of Abstract
784	              Syntax Notation One (ASN.1)", 1988,
785	              <https://www.itu.int/rec/T-REC-X.208-198811-W/en>.

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

792	   [X.509-88]
793	              CCITT, "Recommendation X.509: The Directory -
794	              Authentication Framework", 1988,
795	              <https://www.itu.int/rec/T-REC-X.509-198811-S>.

797	11.2.  Informative References

799	   [CNSA]     Committee for National Security Systems, "Commercial
800	              National Security Algorithm (CNSA) Suite Fact Sheet",
801	              December 2015, <https://www.iad.gov/iad/library/ia-
802	              guidance/ia-solutions-for-classified/algorithm-guidance/
803	              commercial-national-security-algorithm-suite-
804	              factsheet.cfm>.

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

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

818	Author's Address
819	   Michael Jenkins
820	   National Security Agency

822	   Email: mjjenki@nsa.gov