[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 RFC 8755

Internet Engineering Task Force                               M. Jenkins
Internet-Draft                                                       NSA
Intended status: Informational                            August 6, 2019
Expires: February 7, 2020


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

Abstract

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

Status of This Memo

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

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

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

   This Internet-Draft will expire on February 7, 2020.

Copyright Notice

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




Jenkins                 Expires February 7, 2020                [Page 1]


Internet-Draft            CNSA Suite for S/MIME              August 2019


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The Commercial National Security Algorithm Suite  . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Requirements and Assumptions  . . . . . . . . . . . . . . . .   4
   5.  SHA-384 Message Digest Algorithm  . . . . . . . . . . . . . .   5
   6.  Digital Signature . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  ECDSA Signature . . . . . . . . . . . . . . . . . . . . .   5
     6.2.  RSA Signature . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Key Establishment . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Elliptic Curve Key Agreement  . . . . . . . . . . . . . .   7
     7.2.  RSA Key Transport . . . . . . . . . . . . . . . . . . . .  11
   8.  Content Encryption  . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  AES-CBC Content Encryption  . . . . . . . . . . . . . . .  13
     8.2.  AES-GCM Content Encryption  . . . . . . . . . . . . . . .  13
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

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





Jenkins                 Expires February 7, 2020                [Page 2]


Internet-Draft            CNSA Suite for S/MIME              August 2019


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

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

2.  The Commercial National Security Algorithm Suite

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

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

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

3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP




Jenkins                 Expires February 7, 2020                [Page 3]


Internet-Draft            CNSA Suite for S/MIME              August 2019


   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

4.  Requirements and Assumptions

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

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


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


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

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

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

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

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

   It is recognized that, while the vast majority of RSA signatures are
   currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred
   RSA signature scheme for new applications is RSASSA-PSS.  CNSA Suite
   compliant X.509 certificates will be issued in accordance with
   [RFC8603], and while those certificates must be signed and validated
   using RSASSA-PKCS1-v1_5, the subject's RSA key pair can be used to
   generate and validate signatures appropriate for either signing



Jenkins                 Expires February 7, 2020                [Page 4]


Internet-Draft            CNSA Suite for S/MIME              August 2019


   scheme.  Where use of RSASSA-PSS is indicated in this document, the
   parameters in Section 6.2.2 apply.

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

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

5.  SHA-384 Message Digest Algorithm

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

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

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


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


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

6.  Digital Signature

6.1.  ECDSA Signature

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




Jenkins                 Expires February 7, 2020                [Page 5]


Internet-Draft            CNSA Suite for S/MIME              August 2019


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


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


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

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


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


6.2.  RSA Signature

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

6.2.1.  RSA-PKCS1-v1_5

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


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


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

6.2.2.  RSA-PSS

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





Jenkins                 Expires February 7, 2020                [Page 6]


Internet-Draft            CNSA Suite for S/MIME              August 2019


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


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


          RSASSA-PSS-params  ::=  SEQUENCE  {
             hashAlgorithm      [0] HashAlgorithm DEFAULT
                                       sha1Identifier,
             maskGenAlgorithm   [1] MaskGenAlgorithm DEFAULT
                                       mgf1SHA1Identifier,
             saltLength         [2] INTEGER DEFAULT 20,
             trailerField       [3] INTEGER DEFAULT 1  }


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

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

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

   o  the salt length MUST be 48 octets; and

   o  the trailerField MUST have value 1.

7.  Key Establishment

7.1.  Elliptic Curve Key Agreement

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

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

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





Jenkins                 Expires February 7, 2020                [Page 7]


Internet-Draft            CNSA Suite for S/MIME              August 2019


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

   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
   with the CMS.  CNSA Suite compliant S/MIME implementations MUST
   follow these conventions.

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

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


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


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

7.1.1.  Key Derivation Functions

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

   The KDF based on SHA-384 MUST be used.

   As specified in Section 7.2 of [RFC5753], when using ECDH with the
   CMS enveloped-data or authenticated-enveloped-data content type, the



Jenkins                 Expires February 7, 2020                [Page 8]


Internet-Draft            CNSA Suite for S/MIME              August 2019


   derivation of key-encryption keys makes use of the ECC-CMS-SharedInfo
   type:


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


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

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

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

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

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

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


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


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



Jenkins                 Expires February 7, 2020                [Page 9]


Internet-Draft            CNSA Suite for S/MIME              August 2019


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


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

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

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

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

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

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


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


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

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

7.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.



Jenkins                 Expires February 7, 2020               [Page 10]


Internet-Draft            CNSA Suite for S/MIME              August 2019


   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

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

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

7.2.1.  RSAES-PKCS1-v1_5

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

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

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


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


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

7.2.2.  RSAES-OAEP

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



Jenkins                 Expires February 7, 2020               [Page 11]


Internet-Draft            CNSA Suite for S/MIME              August 2019


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

   The algorithm identifier for RSA (OAEP) is:


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


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


          RSAES-OAEP-params  ::=  SEQUENCE  {
             hashFunc          [0] AlgorithmIdentifier DEFAULT
                                      sha1Identifier,
             maskGenFunc       [1] AlgorithmIdentifier DEFAULT
                                      mgf1SHA1Identifier,
             pSourceFunc       [2] AlgorithmIdentifier DEFAULT
                                      pSpecifiedEmptyIdentifier  }

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

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


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

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

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

   o  the pSourceFunc field must be absent.

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




Jenkins                 Expires February 7, 2020               [Page 12]


Internet-Draft            CNSA Suite for S/MIME              August 2019


8.  Content Encryption

8.1.  AES-CBC Content Encryption

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

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

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

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

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


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


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

8.2.  AES-GCM Content Encryption

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

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

   Within the CMS authenticated-enveloped-data content type, content-
   authenticated encryption algorithm identifiers are located in the
   AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm
   field.  The content-authenticated encryption algorithm is used to



Jenkins                 Expires February 7, 2020               [Page 13]


Internet-Draft            CNSA Suite for S/MIME              August 2019


   encipher the content located in the AuthEnvelopedData
   EncryptedContentInfo encryptedContent field.

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

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

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

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

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

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

9.  Security Considerations

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

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

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

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

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

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





Jenkins                 Expires February 7, 2020               [Page 14]


Internet-Draft            CNSA Suite for S/MIME              August 2019


   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

   This document has no IANA actions.

11.  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
              Hash Standard (SHS)", Federal Information Processing
              Standard 180-4, August 2015,
              <https://csrc.nist.gov/publications/detail/fips/180/4/
              final>.

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

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

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

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

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



Jenkins                 Expires February 7, 2020               [Page 15]


Internet-Draft            CNSA Suite for S/MIME              August 2019


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

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

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

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

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

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

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

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

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






Jenkins                 Expires February 7, 2020               [Page 16]


Internet-Draft            CNSA Suite for S/MIME              August 2019


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

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

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

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

   [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:
              Elliptic Curve Cryptography", May 2009,
              <https://www.secg.org/sec1-v2.pdf>.

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

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




Jenkins                 Expires February 7, 2020               [Page 17]


Internet-Draft            CNSA Suite for S/MIME              August 2019


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

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

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

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

11.2.  Informative References

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

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

Author's Address

   Michael Jenkins
   National Security Agency

   Email: mjjenki@nsa.gov













Jenkins                 Expires February 7, 2020               [Page 18]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/