Difference between revisions of "RFC8755"

Latest revision as of 10:47, 30 October 2020

Independent Submission M. Jenkins Request for Comments: 8755 NSA Category: Informational March 2020 ISSN: 2070-1721

Using Commercial National Security Algorithm Suite Algorithms in
          Secure/Multipurpose Internet Mail Extensions

Abstract

The United States Government has published the National Security Agency (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 document is not an Internet Standards Track specification; it is published for informational purposes.

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8755.

Copyright Notice

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.

1. Introduction

 1.1.  Terminology

2. The Commercial National Security Algorithm Suite 3. Requirements and Assumptions 4. SHA-384 Message Digest Algorithm 5. Digital Signature

 5.1.  ECDSA Signature
 5.2.  RSA Signature

6. Key Establishment

 6.1.  Elliptic Curve Key Agreement
 6.2.  RSA Key Transport

7. Content Encryption

 7.1.  AES-GCM Content Encryption
 7.2.  AES-CBC Content Encryption

8. Security Considerations 9. IANA Considerations 10. References

 10.1.  Normative References
 10.2.  Informative References

Author's Address

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.

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

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 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.

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. The NSA has established the Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users near- term flexibility in meeting their cybersecurity interoperability requirements. The purpose behind this flexibility is to avoid having vendors and customers make two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum- resistant cryptography in the near future.

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

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

                     Table 1

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 signatureAlgorithm field of SignerInfo structures contained within the SignedData. In addition, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of countersignature attributes. Specific requirements for digital signatures are given in Section 5; compliant implementations MUST consider signatures not meeting these requirements as invalid.

Implementations based on Elliptic Curve Cryptography (ECC) also require specification of schemes for key derivation and key wrap. Requirements for these schemes are in Sections 6.1.1 and 6.1.2, respectively.

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 scheme. Where use of RSASSA-PSS is indicated in this document, the parameters in Section 5.2.2 apply.

This document assumes that the 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 4 and Section 7, respectively.

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.

Digital Signature

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.

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 }

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.

RSA-PKCS1-v1_5

RFC5754 defines the signature algorithm identifier used in CMS for an 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.

RSA-PSS

RFC4056 defines the signature algorithm identifier used in CMS for an RSA-PSS signature as follows (presented here in expanded form):

     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:

The hash algorithm MUST be id-sha384 as defined in RFC8017;

The mask generation function MUST use the algorithm identifier

  mfg1SHA384Identifier as defined in RFC4055;

The salt length MUST be 48 octets (the same length as the SHA-384

  output); and

The trailerField MUST have value 1.

Key Establishment

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.

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 6.1.1. Key wrapping is discussed in Section 6.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 (presented here in expanded form):

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

Key Derivation Functions

KDFs based on SHA-384 are used to derive a pairwise key-encryption key from the shared secret produced by ephemeral-static ECDH. Sections 7.1.8 and 7.2 in 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.

As specified in Section 7.1.8 of RFC5753, the ANSI-X9.63-KDF described in Section 3.6.1 of [SEC1] and 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 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 the 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 is 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), blocks of key material (KM) are computed by incrementing Counter appropriately until enough material has been generated:

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

The KM blocks are concatenated left to right as they are generated, and the first (leftmost) L bits are used as the KEK:

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

In the 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 the 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 )

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

AES Key Wrap

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

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

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

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

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.

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.

RSAES-OAEP

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

Within the CMS enveloped-data 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:

The hashFunc algorithm must be id-sha384 as defined in RFC8017;

The mask generation function must use the algorithm identifier

  mfg1SHA384Identifier as defined in RFC4055;

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.

Content Encryption

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

AES-GCM Content Encryption

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

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

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

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

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

     GCMParameters ::= SEQUENCE {
       aes-nonce        OCTET STRING,
       aes-ICVlen       AES-GCM-ICVlen 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 Section 8.2 of [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.

AES-CBC Content Encryption

CNSA Suite-compliant S/MIME implementations using the enveloped-data content type MUST use AES-256 [FIPS197] in Cipher Block Chaining (CBC) mode [SP80038A] as the content-encryption algorithm 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.

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.

The security considerations in RFC8551 apply to this profile, particularly the recommendation to use authenticated encryption modes (i.e., use authenticated-enveloped-data with AES-GCM rather than enveloped-data with AES-CBC).

IANA Considerations

This document has no IANA actions.

10. References

10.1. Normative References

[CNSA] Committee for National Security Systems, "Use of Public

          Standards for Secure Information Sharing", CNSS Policy 15,
          October 2016,
          <https://www.cnss.gov/CNSS/Issuances/Policies.cfm>.

[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 (DSS)", DOI 10.6028/NIST.FIPS.186-4,
          FIPS PUB 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)", DOI 10.6028/NIST.FIPS.197,
          FIPS PUB 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>.

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

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] Dworkin, M., "Recommendation for Block Cipher Modes of

          Operation: Methods and Techniques",
          DOI 10.6028/NIST.SP.800-38A, Special Publication 800-38A,
          December 2001, <https://csrc.nist.gov/publications/detail/
          sp/800-38a/final>.

[SP80038D] Dworkin, M., "Recommendation for Block Cipher Modes of

          Operation: Galois/Counter Mode (GCM) and GMAC",
          DOI 10.6028/NIST.SP.800-38D, Special Publication 800-38D,
          November 2007, <https://csrc.nist.gov/publications/detail/
          sp/800-38d/final>.

[SP80038F] Dworkin, M., "Recommendation for Block Cipher Modes of

          Operation: Methods for Key Wrapping",
          DOI 10.6028/NIST.SP.800-38F, Special Publication 800-38F,
          December 2012, <https://csrc.nist.gov/publications/detail/
          sp/800-38f/final>.

[X208] CCITT, "Specification of Abstract Syntax Notation One

          (ASN.1)", CCITT Recommendation X.208, 1988,
          <https://www.itu.int/rec/T-REC-X.208-198811-W/en>.

[X209] CCITT, "Specification of Basic Encoding Rules for Abstract

          Syntax Notation One (ASN.1)", CCITT Recommendation X.209,
          1988, <https://www.itu.int/rec/T-REC-X.209-198811-W/en>.

[X509] CCITT, "The Directory - Authentication Framework", CCITT

          Recommendation X.509, 1988,
          <https://www.itu.int/rec/T-REC-X.509-198811-S>.

10.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] Barker, W., "Guideline for Identifying an Information

          System as a National Security System",
          DOI 10.6028/NIST.SP.800-59, 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: [email protected]

Anonymous

Search

Difference between revisions of "RFC8755"

Namespaces

More

Page actions

Latest revision as of 10:47, 30 October 2020

Contents

Introduction

Terminology

The Commercial National Security Algorithm Suite

Requirements and Assumptions

SHA-384 Message Digest Algorithm

Digital Signature

ECDSA Signature

RSA Signature

RSA-PKCS1-v1_5

RSA-PSS

Key Establishment

Elliptic Curve Key Agreement

Key Derivation Functions

AES Key Wrap

RSA Key Transport

RSAES-PKCS1-v1_5

RSAES-OAEP

Content Encryption

AES-GCM Content Encryption

AES-CBC Content Encryption

Security Considerations

IANA Considerations

Navigation

Navigation

Wiki tools

Wiki tools

@@ Line 1: / Line 1: @@
 Independent Submission                                        M. Jenkins
@@ Line 8: / Line 6: @@
 ISSN: 2070-1721
+ Using Commercial National Security Algorithm Suite Algorithms in
+          Secure/Multipurpose Internet Mail Extensions
-    Using Commercial National Security Algorithm Suite Algorithms in
+'''Abstract'''
-              Secure/Multipurpose Internet Mail Extensions
-Abstract
+The United States Government has published the National Security
+Agency (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
+[[RFC8551|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.
-  The United States Government has published the National Security
+'''Status of This Memo'''
-  Agency (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 document is not an Internet Standards Track specification; it is
+published for informational purposes.
-  This document is not an Internet Standards Track specification; it is
+This is a contribution to the RFC Series, independently of any other
-  published for informational purposes.
+RFC stream.  The RFC Editor has chosen to publish this document at
+its discretion and makes no statement about its value for
+implementation or deployment.  Documents approved for publication by
+the RFC Editor are not candidates for any level of Internet Standard;
+see Section 2 of [[RFC7841|RFC 7841]].
-  This is a contribution to the RFC Series, independently of any other
+Information about the current status of this document, any errata,
-  RFC stream.  The RFC Editor has chosen to publish this document at
+and how to provide feedback on it may be obtained at
-  its discretion and makes no statement about its value for
+https://www.rfc-editor.org/info/rfc8755.
-  implementation or deployment.  Documents approved for publication by
-  the RFC Editor are not candidates for any level of Internet Standard;
-  see Section 2 of RFC 7841.
-  Information about the current status of this document, any errata,
+'''Copyright Notice'''
-  and how to provide feedback on it may be obtained at
-  https://www.rfc-editor.org/info/rfc8755.
-Copyright Notice
+Copyright (c) 2020 IETF Trust and the persons identified as the
+document authors.  All rights reserved.
-  Copyright (c) 2020 IETF Trust and the persons identified as the
+This document is subject to [[BCP78|BCP 78]] and the IETF Trust's Legal
-  document authors.  All rights reserved.
+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.
-  This document is subject to BCP 78 and the IETF Trust's Legal
+.  Introduction
-  Provisions Relating to IETF Documents
+.1.  Terminology
-  (https://trustee.ietf.org/license-info) in effect on the date of
+.  The Commercial National Security Algorithm Suite
-  publication of this document.  Please review these documents
+.  Requirements and Assumptions
-  carefully, as they describe your rights and restrictions with respect
+.  SHA-384 Message Digest Algorithm
-  to this document.
+.  Digital Signature
+.1.  ECDSA Signature
+.2.  RSA Signature
+.  Key Establishment
+.1.  Elliptic Curve Key Agreement
+.2.  RSA Key Transport
+.  Content Encryption
+.1.  AES-GCM Content Encryption
+.2.  AES-CBC Content Encryption
+.  Security Considerations
+.  IANA Considerations
+. References
+.1.  Normative References
+.2.  Informative References
+Author's Address
-Table of Contents
+== Introduction ==
-.  Introduction
+This document specifies the conventions for using the United States
-.1.  Terminology
+National Security Agency's Commercial National Security Algorithm
-.  The Commercial National Security Algorithm Suite
+(CNSA) Suite algorithms [CNSA] in Secure/Multipurpose Internet Mail
-.  Requirements and Assumptions
+Extensions (S/MIME) [[RFC8551]].  It applies to the capabilities,
-.  SHA-384 Message Digest Algorithm
+configuration, and operation of all components of US National
-.  Digital Signature
+Security Systems that employ S/MIME messaging.  US National Security
-.1.  ECDSA Signature
+Systems are described in NIST Special Publication 800-59 [SP80059].
-.2.  RSA Signature
+It is also appropriate for all other US Government systems that
-.  Key Establishment
+process high-value information.  It is made publicly available for
-.1.  Elliptic Curve Key Agreement
+use by developers and operators of these and any other system
-.2.  RSA Key Transport
+deployments.
-.  Content Encryption
-.1.  AES-GCM Content Encryption
-.2.  AES-CBC Content Encryption
-.  Security Considerations
-.  IANA Considerations
-. References
-.1.  Normative References
-.2.  Informative References
-  Author's Address
-.  Introduction
+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 specifies the conventions for using the United States
+This document does not define any new cryptographic algorithm suites;
-  National Security Agency's Commercial National Security Algorithm
+instead, it defines a CNSA-compliant profile of S/MIME.  Since many
-  (CNSA) Suite algorithms [CNSA] in Secure/Multipurpose Internet Mail
+of the CNSA Suite algorithms enjoy uses in other environments as
-  Extensions (S/MIME) [RFC8551].  It applies to the capabilities,
+well, the majority of the conventions needed for these algorithms are
-  configuration, and operation of all components of US National
+already specified in other documents.  This document references the
-  Security Systems that employ S/MIME messaging.  US National Security
+source of these conventions, with some relevant details repeated to
-  Systems are described in NIST Special Publication 800-59 [SP80059].
+aid developers that choose to support the CNSA Suite.  Where details
-  It is also appropriate for all other US Government systems that
+have been repeated, the cited documents are authoritative.
-  process high-value information.  It is made publicly available for
-  use by developers and operators of these and any other system
-  deployments.
-  S/MIME makes use of the Cryptographic Message Syntax (CMS) [RFC5652]
+=== Terminology ===
-  [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 suites;
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-  instead, it defines a CNSA-compliant profile of S/MIME.  Since many
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
-  of the CNSA Suite algorithms enjoy uses in other environments as
+"OPTIONAL" in this document are to be interpreted as described in
-  well, the majority of the conventions needed for these algorithms are
+[[BCP14|BCP 14]] [[RFC2119]] [[RFC8174]] when, and only when, they appear in all
-  already specified in other documents.  This document references the
+capitals, as shown here.
-  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.
-.1.  Terminology
+== The Commercial National Security Algorithm Suite ==
-  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+The National Security Agency (NSA) profiles commercial cryptographic
-  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+algorithms and protocols as part of its mission to support secure,
-  "OPTIONAL" in this document are to be interpreted as described in
+interoperable communications for US Government National Security
-  BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+Systems.  To this end, it publishes guidance both to assist with the
-  capitals, as shown here.
+US Government transition to new algorithms and to provide vendors --
+and the Internet community in general -- with information concerning
+their proper use and configuration.
-.  The Commercial National Security Algorithm Suite
+Recently, cryptographic transition plans have become overshadowed by
+the prospect of the development of a cryptographically relevant
+quantum computer.  The NSA has established the Commercial National
+Security Algorithm (CNSA) Suite to provide vendors and IT users near-
+term flexibility in meeting their cybersecurity interoperability
+requirements.  The purpose behind this flexibility is to avoid having
+vendors and customers make two major transitions in a relatively
+short timeframe, as we anticipate a need to shift to quantum-
+resistant cryptography in the near future.
-  The National Security Agency (NSA) profiles commercial cryptographic
+The NSA is authoring a set of RFCs, including this one, to provide
-  algorithms and protocols as part of its mission to support secure,
+updated guidance concerning the use of certain commonly available
-  interoperable communications for US Government National Security
+commercial algorithms in IETF protocols.  These RFCs can be used in
-  Systems.  To this end, it publishes guidance both to assist with the
+conjunction with other RFCs and cryptographic guidance (e.g., NIST
-  US Government transition to new algorithms and to provide vendors --
+Special Publications) to properly protect Internet traffic and data-
-  and the Internet community in general -- with information concerning
+at-rest for US Government National Security Systems.
-  their proper use and configuration.
-  Recently, cryptographic transition plans have become overshadowed by
+== Requirements and Assumptions ==
-  the prospect of the development of a cryptographically relevant
-  quantum computer.  The NSA has established the Commercial National
-  Security Algorithm (CNSA) Suite to provide vendors and IT users near-
-  term flexibility in meeting their cybersecurity interoperability
-  requirements.  The purpose behind this flexibility is to avoid having
-  vendors and customers make two major transitions in a relatively
-  short timeframe, as we anticipate a need to shift to quantum-
-  resistant cryptography in the near future.
-  The NSA is authoring a set of RFCs, including this one, to provide
+CMS values are generated using ASN.1 [X208], the Basic Encoding Rules
-  updated guidance concerning the use of certain commonly available
+(BER) [X209], and the Distinguished Encoding Rules (DER) [X509].
-  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.
-.  Requirements and Assumptions
+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:
-   CMS values are generated using ASN.1 [X208], the Basic Encoding Rules
++----------+-----------+-----------+---------------+
-  (BER) [X209], and the Distinguished Encoding Rules (DER) [X509].
+| Curve   | NIST Name | SECG Name | OID [FIPS186] |
++==========+===========+===========+===============+
+| nistp384 | P-384    | secp384r1 | 1.3.132.0.34  |
++----------+-----------+-----------+---------------+
-  The elliptic curve used in the CNSA Suite is specified in [FIPS186]
+                      Table 1
-  and appears in the literature under two different names.  For the
-  sake of clarity, we list both names below:
-  +----------+-----------+-----------+---------------+
+For CNSA Suite applications, public key certificates used to verify
-  | Curve    | NIST Name | SECG Name | OID [FIPS186] |
+S/MIME signatures MUST be compliant with the CNSA Suite Certificate
-  +==========+===========+===========+===============+
+and Certificate Revocation List (CRL) profile specified in [[RFC8603]].
-  | nistp384 | P-384    | secp384r1 | 1.3.132.0.34  |
-  +----------+-----------+-----------+---------------+
-                        Table 1
+Within the CMS signed-data content type, signature algorithm
+identifiers are located in the signatureAlgorithm field of SignerInfo
+structures contained within the SignedData.  In addition, signature
+algorithm identifiers are located in the SignerInfo
+signatureAlgorithm field of countersignature attributes.  Specific
+requirements for digital signatures are given in Section 5; compliant
+implementations MUST consider signatures not meeting these
+requirements as invalid.
-  For CNSA Suite applications, public key certificates used to verify
+Implementations based on Elliptic Curve Cryptography (ECC) also
-  S/MIME signatures MUST be compliant with the CNSA Suite Certificate
+require specification of schemes for key derivation and key wrap.
-  and Certificate Revocation List (CRL) profile specified in [RFC8603].
+Requirements for these schemes are in Sections 6.1.1 and 6.1.2,
+respectively.
-  Within the CMS signed-data content type, signature algorithm
+RSA key pairs (public, private) are identified by the modulus size
-  identifiers are located in the signatureAlgorithm field of SignerInfo
+expressed in bits; RSA-3072 and RSA-4096 are computed using moduli of
-  structures contained within the SignedData.  In addition, signature
+bits and 4096 bits, respectively.
-  algorithm identifiers are located in the SignerInfo
-  signatureAlgorithm field of countersignature attributes.  Specific
-  requirements for digital signatures are given in Section 5; compliant
-  implementations MUST consider signatures not meeting these
-  requirements as invalid.
-  Implementations based on Elliptic Curve Cryptography (ECC) also
+RSA signature key pairs used in CNSA Suite-compliant implementations
-  require specification of schemes for key derivation and key wrap.
+are either RSA-3072 or RSA-4096.  The RSA exponent e MUST satisfy
-  Requirements for these schemes are in Sections 6.1.1 and 6.1.2,
+^(16) < e < 2^(256) and be odd per [FIPS186].
-  respectively.
-  RSA key pairs (public, private) are identified by the modulus size
+It is recognized that, while the vast majority of RSA signatures are
-  expressed in bits; RSA-3072 and RSA-4096 are computed using moduli of
+currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred
-bits and 4096 bits, respectively.
+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
+scheme.  Where use of RSASSA-PSS is indicated in this document, the
+parameters in Section 5.2.2 apply.
-  RSA signature key pairs used in CNSA Suite-compliant implementations
+This document assumes that the required trust anchors have been
-  are either RSA-3072 or RSA-4096.  The RSA exponent e MUST satisfy
+securely provisioned to the client.
-^(16) < e < 2^(256) and be odd per [FIPS186].
-  It is recognized that, while the vast majority of RSA signatures are
+All implementations use SHA-384 for hashing and either AES-CBC or
-  currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred
+AES-GCM for encryption, the requirements for which are given in
-  RSA signature scheme for new applications is RSASSA-PSS.  CNSA Suite-
+Section 4 and Section 7, respectively.
-  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
-  scheme.  Where use of RSASSA-PSS is indicated in this document, the
-  parameters in Section 5.2.2 apply.
-  This document assumes that the required trust anchors have been
+== SHA-384 Message Digest Algorithm ==
-  securely provisioned to the client.
-  All implementations use SHA-384 for hashing and either AES-CBC or
+SHA-384 is the sole CNSA Suite message digest algorithm.  [[RFC5754]]
-  AES-GCM for encryption, the requirements for which are given in
+specifies the conventions for using SHA-384 with the Cryptographic
-  Section 4 and Section 7, respectively.
+Message Syntax (CMS).  CNSA Suite-compliant S/MIME implementations
+MUST follow the conventions in [[RFC5754]].
-.  SHA-384 Message Digest Algorithm
+Within the CMS signed-data content type, message digest algorithm
+identifiers are located in the SignedData digestAlgorithms field and
+the SignerInfo digestAlgorithm field.
-  SHA-384 is the sole CNSA Suite message digest algorithm.  [RFC5754]
+The SHA-384 message digest algorithm is defined in FIPS Pub 180
-  specifies the conventions for using SHA-384 with the Cryptographic
+[FIPS180].  The algorithm identifier for SHA-384 is defined in
-  Message Syntax (CMS).  CNSA Suite-compliant S/MIME implementations
+[[RFC5754]] as follows:
-  MUST follow the conventions in [RFC5754].
-  Within the CMS signed-data content type, message digest algorithm
+      id-sha384  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
-  identifiers are located in the SignedData digestAlgorithms field and
+          country(16) us(840) organization(1) gov(101) csor(3)
-  the SignerInfo digestAlgorithm field.
+          nistalgorithm(4) hashalgs(2) 2 }
-  The SHA-384 message digest algorithm is defined in FIPS Pub 180
+For SHA-384, the AlgorithmIdentifier parameters field is OPTIONAL,
-  [FIPS180].  The algorithm identifier for SHA-384 is defined in
+and if present, the parameters field MUST contain a NULL.  As
-  [RFC5754] as follows:
+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.
-        id-sha384  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
+== Digital Signature ==
-            country(16) us(840) organization(1) gov(101) csor(3)
-            nistalgorithm(4) hashalgs(2) 2 }
-  For SHA-384, the AlgorithmIdentifier parameters field is OPTIONAL,
+=== ECDSA Signature ===
-  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.
-.  Digital 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]].
-.1.  ECDSA Signature
+[[RFC5480]] defines the signature algorithm identifier used in CMS for
+ECDSA with SHA-384 as follows:
-  The Elliptic Curve Digital Signature Algorithm (ECDSA) is the CNSA
+      ecdsa-with-SHA384  OBJECT IDENTIFIER  ::=  { iso(1)
-  Suite digital signature algorithm based on ECC.  [RFC5753] specifies
+        member-body(2) us(840) ansi-X9-62(10045) signatures(4)
-  the conventions for using ECDSA with the Cryptographic Message Syntax
+        ecdsa-with-sha2(3) 3 }
-  (CMS).  CNSA Suite-compliant S/MIME implementations MUST follow the
-  conventions in [RFC5753].
-  [RFC5480] defines the signature algorithm identifier used in CMS for
+When the ecdsa-with-SHA384 algorithm identifier is used, the
-  ECDSA with SHA-384 as follows:
+AlgorithmIdentifier parameters field MUST be absent.
-        ecdsa-with-SHA384  OBJECT IDENTIFIER  ::=  { iso(1)
+When signing, the ECDSA algorithm generates two values, commonly
-            member-body(2) us(840) ansi-X9-62(10045) signatures(4)
+called r and s.  These two values MUST be encoded using the ECDSA-
-            ecdsa-with-sha2(3) 3 }
+Sig-Value type specified in [[RFC5480]]:
-  When the ecdsa-with-SHA384 algorithm identifier is used, the
+      ECDSA-Sig-Value  ::=  SEQUENCE {
-  AlgorithmIdentifier parameters field MUST be absent.
+        r  INTEGER,
+        s  INTEGER }
-  When signing, the ECDSA algorithm generates two values, commonly
+=== RSA Signature ===
-  called r and s.  These two values MUST be encoded using the ECDSA-
-  Sig-Value type specified in [RFC5480]:
-        ECDSA-Sig-Value  ::=  SEQUENCE {
+The RSA signature generation process and the encoding of the result
-            r  INTEGER,
+is either RSASSA-PKCS1-v1_5 or RSA-PSS, as described in detail in
-            s  INTEGER }
+PKCS #1 version 2.2 [[RFC8017]].
-.2.  RSA Signature
+==== RSA-PKCS1-v1_5 ====
-  The RSA signature generation process and the encoding of the result
+[[RFC5754]] defines the signature algorithm identifier used in CMS for
-  is either RSASSA-PKCS1-v1_5 or RSA-PSS, as described in detail in
+an RSA signature with SHA-384 as follows:
-  PKCS #1 version 2.2 [RFC8017].
-.2.1.  RSA-PKCS1-v1_5
+      sha384WithRSAEncryption  OBJECT IDENTIFIER  ::= { iso(1)
+        member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 }
-  [RFC5754] defines the signature algorithm identifier used in CMS for
+When the sha384WithRSAEncryption algorithm identifier is used, the
-  an RSA signature with SHA-384 as follows:
+parameters MUST be NULL.  Implementations MUST accept the parameters
+being absent as well as present.
-        sha384WithRSAEncryption  OBJECT IDENTIFIER  ::= { iso(1)
+==== RSA-PSS ====
-          member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 }
-  When the sha384WithRSAEncryption algorithm identifier is used, the
+[[RFC4056]] defines the signature algorithm identifier used in CMS for
-  parameters MUST be NULL.  Implementations MUST accept the parameters
+an RSA-PSS signature as follows (presented here in expanded form):
-  being absent as well as present.
-.2.2.  RSA-PSS
+      RSASSA-PSS  OBJECT IDENTIFIER  ::= { iso(1)
+        member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 }
-  [RFC4056] defines the signature algorithm identifier used in CMS for
+The parameters field of an AlgorithmIdentifier that identifies
-  an RSA-PSS signature as follows (presented here in expanded form):
+RSASSA-PSS is defined in [[RFC4055]] as follows:
-        RSASSA-PSS  OBJECT IDENTIFIER  ::= { iso(1)
+      RSASSA-PSS-params  ::=  SEQUENCE  {
-          member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 }
+          hashAlgorithm      [0] HashAlgorithm DEFAULT
+                                    sha1Identifier,
+          maskGenAlgorithm  [1] MaskGenAlgorithm DEFAULT
+                                    mgf1SHA1Identifier,
+          saltLength        [2] INTEGER DEFAULT 20,
+          trailerField      [3] INTEGER DEFAULT 1  }
-  The parameters field of an AlgorithmIdentifier that identifies
+The AlgorithmIdentifier parameters field MUST contain RSASSA-PSS-
-  RSASSA-PSS is defined in [RFC4055] as follows:
+params with the following values:
-          RSASSA-PSS-params  ::=  SEQUENCE  {
+*  The hash algorithm MUST be id-sha384 as defined in [[RFC8017]];
-            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-
+*  The mask generation function MUST use the algorithm identifier
-   params with the following values:
+   mfg1SHA384Identifier as defined in [[RFC4055]];
-  *  The hash algorithm MUST be id-sha384 as defined in [RFC8017];
+*  The salt length MUST be 48 octets (the same length as the SHA-384
+  output); and
-  *  The mask generation function MUST use the algorithm identifier
+*  The trailerField MUST have value 1.
-      mfg1SHA384Identifier as defined in [RFC4055];
-  *  The salt length MUST be 48 octets (the same length as the SHA-384
+== Key Establishment ==
-      output); and
-  *  The trailerField MUST have value 1.
+=== Elliptic Curve Key Agreement ===
-.  Key Establishment
+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]].
-.1.  Elliptic Curve Key Agreement
+When a key agreement algorithm is used, the following steps are
+performed:
-  Elliptic Curve Diffie-Hellman (ECDH) is the CNSA Suite key agreement
+.  A content-encryption key (CEK) for a particular content-
-  algorithm.  Since S/MIME is used in store-and-forward communications,
+    encryption algorithm is generated at random.
-  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
+.  The recipient's public key and sender's private key are used with
-  performed:
+    a key agreement scheme to generate a shared secret (Z).
-.  A content-encryption key (CEK) for a particular content-
+.  The shared secret is used with a key derivation function (KDF) to
-      encryption algorithm is generated at random.
+    produce a key-encryption key (KEK).
-.  The recipient's public key and sender's private key are used with
+.  The KEK is used with a key wrap algorithm to encrypt the CEK.
-      a key agreement scheme to generate a shared secret (Z).
-.  The shared secret is used with a key derivation function (KDF) to
+Key derivation is discussed in Section 6.1.1.  Key wrapping is
-      produce a key-encryption key (KEK).
+discussed in Section 6.1.2.
-.  The KEK is used with a key wrap algorithm to encrypt the CEK.
+Section 3.1 of [[RFC5753]] specifies the conventions for using ECDH
+with the CMS.  CNSA Suite-compliant S/MIME implementations MUST
+follow these conventions.
-  Key derivation is discussed in Section 6.1.1.  Key wrapping is
+Within the CMS enveloped-data and authenticated-enveloped-data
-  discussed in Section 6.1.2.
+content types, key agreement algorithm identifiers are located in the
+EnvelopedData RecipientInfos KeyAgreeRecipientInfo
+keyEncryptionAlgorithm field.
-  Section 3.1 of [RFC5753] specifies the conventions for using ECDH
+The keyEncryptionAlgorithm field comprises two fields, an algorithm
-  with the CMS.  CNSA Suite-compliant S/MIME implementations MUST
+field and a parameter field.  The algorithm field MUST identify
-  follow these conventions.
+dhSinglePass-stdDH-sha384kdf-scheme.  The algorithm identifier for
+the dhSinglePass-stdDH-sha384kdf-scheme, repeated from Section 7.1.4
+of [[RFC5753]], is (presented here in expanded form):
-  Within the CMS enveloped-data and authenticated-enveloped-data
+      dhSinglePass-stdDH-sha384kdf-scheme  OBJECT IDENTIFIER  ::=
-  content types, key agreement algorithm identifiers are located in the
+          { iso(1) identified-organization(3) certicom(132)
-  EnvelopedData RecipientInfos KeyAgreeRecipientInfo
+            schemes(1) 11 2 }
-  keyEncryptionAlgorithm field.
-  The keyEncryptionAlgorithm field comprises two fields, an algorithm
+The keyEncryptionAlgorithm parameter field MUST be constructed as
-  field and a parameter field.  The algorithm field MUST identify
+described in Section 6.1.2.
-  dhSinglePass-stdDH-sha384kdf-scheme.  The algorithm identifier for
-  the dhSinglePass-stdDH-sha384kdf-scheme, repeated from Section 7.1.4
-  of [RFC5753], is (presented here in expanded form):
-        dhSinglePass-stdDH-sha384kdf-scheme  OBJECT IDENTIFIER  ::=
+==== Key Derivation Functions ====
-            { iso(1) identified-organization(3) certicom(132)
-              schemes(1) 11 2 }
-  The keyEncryptionAlgorithm parameter field MUST be constructed as
+KDFs based on SHA-384 are used to derive a pairwise key-encryption
-  described in Section 6.1.2.
+key from the shared secret produced by ephemeral-static ECDH.
+Sections 7.1.8 and 7.2 in [[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.
-.1.1.  Key Derivation Functions
+As specified in Section 7.1.8 of [[RFC5753]], the ANSI-X9.63-KDF
+described in Section 3.6.1 of [SEC1] and based on SHA-384 MUST be
+used.
-  KDFs based on SHA-384 are used to derive a pairwise key-encryption
+As specified in Section 7.2 of [[RFC5753]], when using ECDH with the
-  key from the shared secret produced by ephemeral-static ECDH.
+CMS enveloped-data or authenticated-enveloped-data content type, the
-  Sections 7.1.8 and 7.2 in [RFC5753] specify the CMS conventions for
+derivation of key-encryption keys makes use of the ECC-CMS-SharedInfo
-  using a KDF with the shared secret generated during ephemeral-static
+type:
-  ECDH.  CNSA Suite-compliant S/MIME implementations MUST follow these
-  conventions.
-  As specified in Section 7.1.8 of [RFC5753], the ANSI-X9.63-KDF
+      ECC-CMS-SharedInfo  ::=  SEQUENCE {
-  described in Section 3.6.1 of [SEC1] and based on SHA-384 MUST be
+        keyInfo      AlgorithmIdentifier,
-  used.
+        entityUInfo  [0] EXPLICIT OCTET STRING OPTIONAL,
+        suppPubInfo  [2] EXPLICIT OCTET STRING }
-  As specified in Section 7.2 of [RFC5753], when using ECDH with the
+In the CNSA Suite for S/MIME, the fields of ECC-CMS-SharedInfo are
-  CMS enveloped-data or authenticated-enveloped-data content type, the
+used as follows:
-  derivation of key-encryption keys makes use of the ECC-CMS-SharedInfo
-  type:
-        ECC-CMS-SharedInfo  ::=  SEQUENCE {
+*  keyInfo contains the object identifier of the key-encryption
-            keyInfo     AlgorithmIdentifier,
+  algorithm used to wrap the content-encryption key.  If AES-256 Key
-            entityUInfo  [0] EXPLICIT OCTET STRING OPTIONAL,
+  Wrap is used, then the keyInfo will contain id-aes256-wrap-pad,
-            suppPubInfo  [2] EXPLICIT OCTET STRING }
+  and the parameters will be absent.
-   In the CNSA Suite for S/MIME, the fields of ECC-CMS-SharedInfo are
+*  entityUInfo optionally contains a random value provided by the
-   used as follows:
+  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.
-  *  keyInfo contains the object identifier of the key-encryption
+*  suppPubInfo contains the length of the generated key-encryption
-      algorithm used to wrap the content-encryption key.  If AES-256 Key
+  key in bits, represented as a 32-bit unsigned number, as described
-      Wrap is used, then the keyInfo will contain id-aes256-wrap-pad,
+  in [[RFC2631]].  When a 256-bit AES key is used, the length MUST be
-      and the parameters will be absent.
+x00000100.
-  *  entityUInfo optionally contains a random value provided by the
+ECC-CMS-SharedInfo is DER encoded and is used as input to the key
-      message originator.  If user keying material (ukm) is included in
+derivation function, as specified in Section 3.6.1 of [SEC1].  Note
-      the KeyAgreeRecipientInfo, then the entityUInfo MUST be present,
+that ECC-CMS-SharedInfo differs from the OtherInfo specified in
-      and it MUST contain the ukm value.  If the ukm is not present,
+[[RFC2631]].  Here, a counter value is not included in the keyInfo
-      then the entityUInfo MUST be absent.
+field because the KDF specified in [SEC1] ensures that sufficient
+keying data is provided.
-  *  suppPubInfo contains the length of the generated key-encryption
+The KDF specified in Section 3.6.1 of [SEC1] describes how to
-      key in bits, represented as a 32-bit unsigned number, as described
+generate an essentially arbitrary amount of keying material from a
-      in [RFC2631].  When a 256-bit AES key is used, the length MUST be
+shared secret, Z, produced by ephemeral-static ECDH.  To generate an
-x00000100.
+L-bit key-encryption key (KEK), blocks of key material (KM) are
+computed by incrementing Counter appropriately until enough material
+has been generated:
-  ECC-CMS-SharedInfo is DER encoded and is used as input to the key
+      KM(Counter) = Hash ( Z || Counter || ECC-CMS-SharedInfo )
-  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
+The KM blocks are concatenated left to right as they are generated,
-  generate an essentially arbitrary amount of keying material from a
+and the first (leftmost) L bits are used as the KEK:
-  shared secret, Z, produced by ephemeral-static ECDH.  To generate an
-  L-bit key-encryption key (KEK), blocks of key material (KM) are
-  computed by incrementing Counter appropriately until enough material
-  has been generated:
-        KM(Counter) = Hash ( Z || Counter || ECC-CMS-SharedInfo )
+      KEK = the leftmost L bits of
+              [KM ( counter=1 ) || KM ( counter=2 ) ...]
-  The KM blocks are concatenated left to right as they are generated,
+In the CNSA Suite for S/MIME, the elements of the KDF are defined as
-  and the first (leftmost) L bits are used as the KEK:
+follows:
-        KEK = the leftmost L bits of
+*  Hash is a one-way hash function.  The SHA-384 hash MUST be used.
-                  [KM ( counter=1 ) || KM ( counter=2 ) ...]
-   In the CNSA Suite for S/MIME, the elements of the KDF are defined as
+*  Z is the shared secret value generated during ephemeral-static
-   follows:
+   ECDH.  Z MUST be exactly 384 bits, i.e., leading zero bits MUST be
+   preserved.
-  *  Hash is a one-way hash function.  The SHA-384 hash MUST be used.
+*  Counter is a 32-bit unsigned number represented in network byte
+  order.  Its initial value MUST be 0x00000001 for any key
+  derivation operation.
-  *  Z is the shared secret value generated during ephemeral-static
+*  ECC-CMS-SharedInfo is composed as described above.  It MUST be DER
-      ECDH.  Z MUST be exactly 384 bits, i.e., leading zero bits MUST be
+  encoded.
-      preserved.
-  *  Counter is a 32-bit unsigned number represented in network byte
+In the CNSA Suite for S/MIME, exactly one iteration is needed; the
-      order.  Its initial value MUST be 0x00000001 for any key
+Counter is not incremented.  The key-encryption key (KEK) MUST be the
-      derivation operation.
+first (leftmost) 256 bits of the SHA-384 output value:
-  *  ECC-CMS-SharedInfo is composed as described above.  It MUST be DER
+      KEK = the leftmost 256 bits of
-      encoded.
+              SHA-384 ( Z || 0x00000001 || ECC-CMS-SharedInfo )
-  In the CNSA Suite for S/MIME, exactly one iteration is needed; the
+Note that the only source of secret entropy in this computation is Z.
-  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
+==== AES Key Wrap ====
-                  SHA-384 ( Z || 0x00000001 || ECC-CMS-SharedInfo )
-  Note that the only source of secret entropy in this computation is Z.
+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.
-.1.2.  AES Key Wrap
+Within the CMS enveloped-data content type, key wrap algorithm
+identifiers are located in the KeyWrapAlgorithm parameters within the
+EnvelopedData RecipientInfos KeyAgreeRecipientInfo
+keyEncryptionAlgorithm field.
-  The AES Key Wrap with Padding key-encryption algorithm, as specified
+The KeyWrapAlgorithm MUST be id-aes256-wrap-pad.  The required
-  in [RFC5649] and [SP80038F], is used to encrypt the content-
+algorithm identifier, specified in [[RFC5649]], is:
-  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
+      id-aes256-wrap-pad  OBJECT IDENTIFIER ::=  { joint-iso-itu-t(2)
-  identifiers are located in the KeyWrapAlgorithm parameters within the
+        country(16) us(840) organization(1) gov(101) csor(3)
-  EnvelopedData RecipientInfos KeyAgreeRecipientInfo
+        nistAlgorithm(4) aes(1) 48 }
-  keyEncryptionAlgorithm field.
-  The KeyWrapAlgorithm MUST be id-aes256-wrap-pad.  The required
+=== RSA Key Transport ===
-  algorithm identifier, specified in [RFC5649], is:
-        id-aes256-wrap-pad  OBJECT IDENTIFIER ::=  { joint-iso-itu-t(2)
+RSA encryption (RSA) is the CNSA Suite key transport algorithm.  The
-            country(16) us(840) organization(1) gov(101) csor(3)
+RSA key transport algorithm is the RSA encryption scheme defined in
-            nistAlgorithm(4) aes(1) 48 }
+[[RFC8017]], where the message to be encrypted is the content-
+encryption key.
-.2.  RSA Key Transport
+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.
-  RSA encryption (RSA) is the CNSA Suite key transport algorithm.  The
+==== RSAES-PKCS1-v1_5 ====
-  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
+Section 4.2 of [[RFC3370]] specifies the conventions for using RSAES-
-  public key is represented by an X.509 certificate.  The certificate
+PKCS1-v1_5 with the CMS.  S/MIME implementations employing this form
-  used to obtain the recipient's public key MUST be compliant with
+of key transport MUST follow these conventions.
-  [RFC8603].  These certificates are suitable for use with either
-  RSAES-OAEP or RSAES-PKCS1-v1_5.
-.2.1.  RSAES-PKCS1-v1_5
+Within the CMS enveloped-data and authenticated-enveloped-data
+content types, key transport algorithm identifiers are located in the
+EnvelopedData RecipientInfos KeyTransRecipientInfo
+keyEncryptionAlgorithm field.
-  Section 4.2 of [RFC3370] specifies the conventions for using RSAES-
+The algorithm identifier for RSA (PKCS #1 v1.5) is:
-  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
+      rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
-  content types, key transport algorithm identifiers are located in the
+          us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
-  EnvelopedData RecipientInfos KeyTransRecipientInfo
-  keyEncryptionAlgorithm field.
-  The algorithm identifier for RSA (PKCS #1 v1.5) is:
+The AlgorithmIdentifier parameters field MUST be present, and the
+parameters field MUST contain NULL.
-        rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+==== RSAES-OAEP ====
-            us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
-  The AlgorithmIdentifier parameters field MUST be present, and the
+[[RFC3560]] specifies the conventions for using RSAES-OAEP with the
-  parameters field MUST contain NULL.
+CMS.  CNSA Suite-compliant S/MIME implementations employing this form
+of key transport MUST follow these conventions.
-.2.2.  RSAES-OAEP
+Within the CMS enveloped-data and authenticated-enveloped-data
+content types, key transport algorithm identifiers are located in the
+EnvelopedData RecipientInfos KeyTransRecipientInfo
+keyEncryptionAlgorithm field.
-  [RFC3560] specifies the conventions for using RSAES-OAEP with the
+The algorithm identifier for RSA (OAEP) is:
-  CMS.  CNSA Suite-compliant S/MIME implementations employing this form
-  of key transport MUST follow these conventions.
-  Within the CMS enveloped-data and authenticated-enveloped-data
+      id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { iso(1) member-body(2)
-  content types, key transport algorithm identifiers are located in the
+          us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }
-  EnvelopedData RecipientInfos KeyTransRecipientInfo
-  keyEncryptionAlgorithm field.
-  The algorithm identifier for RSA (OAEP) is:
+The parameters field of an AlgorithmIdentifier that identifies RSAES-
+OAEP is defined in [[RFC4055]] as follows:
-        id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { iso(1) member-body(2)
+      RSAES-OAEP-params  ::=  SEQUENCE  {
-            us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }
+          hashFunc          [0] AlgorithmIdentifier DEFAULT
+                                  sha1Identifier,
+          maskGenFunc      [1] AlgorithmIdentifier DEFAULT
+                                  mgf1SHA1Identifier,
+          pSourceFunc      [2] AlgorithmIdentifier DEFAULT
+                                  pSpecifiedEmptyIdentifier  }
-  The parameters field of an AlgorithmIdentifier that identifies RSAES-
+      pSpecifiedEmptyIdentifier  AlgorithmIdentifier  ::=
-  OAEP is defined in [RFC4055] as follows:
+                            { id-pSpecified, nullOctetString }
-          RSAES-OAEP-params  ::=  SEQUENCE  {
+      nullOctetString  OCTET STRING (SIZE (0))  ::=  { ''H }
-            hashFunc          [0] AlgorithmIdentifier DEFAULT
-                                      sha1Identifier,
-            maskGenFunc      [1] AlgorithmIdentifier DEFAULT
-                                      mgf1SHA1Identifier,
-            pSourceFunc      [2] AlgorithmIdentifier DEFAULT
-                                      pSpecifiedEmptyIdentifier  }
-          pSpecifiedEmptyIdentifier  AlgorithmIdentifier  ::=
+The AlgorithmIdentifier parameters field MUST be present, and the
-                              { id-pSpecified, nullOctetString }
+parameters field MUST contain RSAES-OAEP-params with values as
+follows:
-          nullOctetString  OCTET STRING (SIZE (0))  ::=  { ''H }
+*  The hashFunc algorithm must be id-sha384 as defined in [[RFC8017]];
-  The AlgorithmIdentifier parameters field MUST be present, and the
+*  The mask generation function must use the algorithm identifier
-   parameters field MUST contain RSAES-OAEP-params with values as
+   mfg1SHA384Identifier as defined in [[RFC4055]];
-  follows:
-  *  The hashFunc algorithm must be id-sha384 as defined in [RFC8017];
+*  The pSourceFunc field must be absent.
-  *  The mask generation function must use the algorithm identifier
+The SMIMECapabilities signed attribute is used to specify a partial
-      mfg1SHA384Identifier as defined in [RFC4055];
+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.
-  *  The pSourceFunc field must be absent.
+== Content Encryption ==
-  The SMIMECapabilities signed attribute is used to specify a partial
+AES-GCM is the preferred mode for CNSA Suite applications, as
-  list of algorithms that the software announcing the SMIMECapabilities
+described in the Security Considerations (Section 8).  AES-CBC is
-  can support.  If the SMIMECapabilities signed attribute is included
+acceptable where AES-GCM is not yet available.
-  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.
-.  Content Encryption
+=== AES-GCM Content Encryption ===
-  AES-GCM is the preferred mode for CNSA Suite applications, as
+CNSA Suite-compliant S/MIME implementations using the authenticated-
-  described in the Security Considerations (Section 8).  AES-CBC is
+enveloped-data content type [[RFC5083]] MUST use AES [FIPS197] in
-  acceptable where AES-GCM is not yet available.
+Galois Counter Mode (GCM) [SP80038D] as the content-authenticated
+encryption algorithm and MUST follow the conventions for using AES-
+GCM with the CMS defined in [[RFC5084]].
-.1.  AES-GCM Content Encryption
+Within the CMS authenticated-enveloped-data content type, content-
+authenticated encryption algorithm identifiers are located in the
+AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm
+field.  The content-authenticated encryption algorithm is used to
+encipher the content located in the AuthEnvelopedData
+EncryptedContentInfo encryptedContent field.
-  CNSA Suite-compliant S/MIME implementations using the authenticated-
+The AES-GCM content-authenticated encryption algorithm is described
-  enveloped-data content type [RFC5083] MUST use AES [FIPS197] in
+in [FIPS197] and [SP80038D].  The algorithm identifier for AES-256 in
-  Galois Counter Mode (GCM) [SP80038D] as the content-authenticated
+GCM mode is:
-  encryption algorithm and MUST follow the conventions for using AES-
-  GCM with the CMS defined in [RFC5084].
-  Within the CMS authenticated-enveloped-data content type, content-
+        id-aes256-GCM  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
-  authenticated encryption algorithm identifiers are located in the
+            country(16) us(840) organization(1) gov(101) csor(3)
-  AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm
+            nistAlgorithm(4) aes(1) 46 }
-  field.  The content-authenticated encryption algorithm is used to
-  encipher the content located in the AuthEnvelopedData
-  EncryptedContentInfo encryptedContent field.
-  The AES-GCM content-authenticated encryption algorithm is described
+The AlgorithmIdentifier parameters field MUST be present, and the
-  in [FIPS197] and [SP80038D].  The algorithm identifier for AES-256 in
+parameters field must contain GCMParameters:
-  GCM mode is:
-            id-aes256-GCM  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
+      GCMParameters ::= SEQUENCE {
-              country(16) us(840) organization(1) gov(101) csor(3)
+        aes-nonce        OCTET STRING,
-              nistAlgorithm(4) aes(1) 46 }
+        aes-ICVlen      AES-GCM-ICVlen DEFAULT 12 }
-  The AlgorithmIdentifier parameters field MUST be present, and the
+The authentication tag length (aes-ICVlen) SHALL be 16 (indicating a
-  parameters field must contain GCMParameters:
+tag length of 128 bits).
-        GCMParameters ::= SEQUENCE {
+The initialization vector (aes-nonce) MUST be generated in accordance
-          aes-nonce       OCTET STRING,
+with Section 8.2 of [SP80038D].  AES-GCM loses security
-          aes-ICVlen      AES-GCM-ICVlen DEFAULT 12 }
+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.
-  The authentication tag length (aes-ICVlen) SHALL be 16 (indicating a
+=== AES-CBC Content Encryption ===
-  tag length of 128 bits).
-  The initialization vector (aes-nonce) MUST be generated in accordance
+CNSA Suite-compliant S/MIME implementations using the enveloped-data
-  with Section 8.2 of [SP80038D].  AES-GCM loses security
+content type MUST use AES-256 [FIPS197] in Cipher Block Chaining
-  catastrophically if a nonce is reused with a given key on more than
+(CBC) mode [SP80038A] as the content-encryption algorithm and MUST
-  one distinct set of input data.  Therefore, a fresh content-
+follow the conventions for using AES with the CMS defined in
-  authenticated encryption key MUST be generated for each message.
+[[RFC3565]].
-.2.  AES-CBC Content Encryption
+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.
-  CNSA Suite-compliant S/MIME implementations using the enveloped-data
+The AES-CBC content-encryption algorithm is described in [FIPS197]
-  content type MUST use AES-256 [FIPS197] in Cipher Block Chaining
+and [SP80038A].  The algorithm identifier for AES-256 in CBC mode is:
-  (CBC) mode [SP80038A] as the content-encryption algorithm and MUST
-  follow the conventions for using AES with the CMS defined in
-  [RFC3565].
-  Within the CMS enveloped-data content type, content-encryption
+      id-aes256-CBC  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
-  algorithm identifiers are located in the EnvelopedData
+        country(16) us(840) organization(1) gov(101) csor(3)
-  EncryptedContentInfo contentEncryptionAlgorithm field.  The content-
+        nistAlgorithm(4) aes(1) 42 }
-  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]
+The AlgorithmIdentifier parameters field MUST be present, and the
-  and [SP80038A].  The algorithm identifier for AES-256 in CBC mode is:
+parameters field must contain AES-IV:
-        id-aes256-CBC  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
+      AES-IV  ::=  OCTET STRING (SIZE(16))
-            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
+The 16-octet initialization vector is generated at random by the
-  originator.  See [RFC4086] for guidance on generation of random
+originator.  See [[RFC4086]] for guidance on generation of random
-  values.
+values.
-.  Security Considerations
+== Security Considerations ==
-  This document specifies the conventions for using the NSA's CNSA
+This document specifies the conventions for using the NSA's CNSA
-  Suite algorithms in S/MIME.  All of the algorithms and algorithm
+Suite algorithms in S/MIME.  All of the algorithms and algorithm
-  identifiers have been specified in previous documents.
+identifiers have been specified in previous documents.
-  See [RFC4086] for guidance on generation of random values.
+See [[RFC4086]] for guidance on generation of random values.
-  The security considerations in [RFC5652] discuss the CMS as a method
+The security considerations in [[RFC5652]] discuss the CMS as a method
-  for digitally signing data and encrypting data.
+for digitally signing data and encrypting data.
-  The security considerations in [RFC3370] discuss cryptographic
+The security considerations in [[RFC3370]] discuss cryptographic
-  algorithm implementation concerns in the context of the CMS.
+algorithm implementation concerns in the context of the CMS.
-  The security considerations in [RFC5753] discuss the use of elliptic
+The security considerations in [[RFC5753]] discuss the use of elliptic
-  curve cryptography (ECC) in the CMS.
+curve cryptography (ECC) in the CMS.
-  The security considerations in [RFC3565] discuss the use of AES in
+The security considerations in [[RFC3565]] discuss the use of AES in
-  the CMS.
+the CMS.
-  The security considerations in [RFC8551] apply to this profile,
+The security considerations in [[RFC8551]] apply to this profile,
-  particularly the recommendation to use authenticated encryption modes
+particularly the recommendation to use authenticated encryption modes
-  (i.e., use authenticated-enveloped-data with AES-GCM rather than
+(i.e., use authenticated-enveloped-data with AES-GCM rather than
-  enveloped-data with AES-CBC).
+enveloped-data with AES-CBC).
-.  IANA Considerations
+== IANA Considerations ==
-  This document has no IANA actions.
+This document has no IANA actions.
 .  References
@@ Line 659: / Line 654: @@
 .1.  Normative References
-  [CNSA]    Committee for National Security Systems, "Use of Public
+[CNSA]    Committee for National Security Systems, "Use of Public
-              Standards for Secure Information Sharing", CNSS Policy 15,
+          Standards for Secure Information Sharing", CNSS Policy 15,
-              October 2016,
+          October 2016,
-              <https://www.cnss.gov/CNSS/Issuances/Policies.cfm>.
+          <https://www.cnss.gov/CNSS/Issuances/Policies.cfm>.
-  [FIPS180]  National Institute of Standards and Technology, "Secure
+[FIPS180]  National Institute of Standards and Technology, "Secure
-              Hash Standard (SHS)", Federal Information Processing
+          Hash Standard (SHS)", Federal Information Processing
-              Standard 180-4, August 2015,
+          Standard 180-4, August 2015,
-              <https://csrc.nist.gov/publications/detail/fips/180/4/
+          <https://csrc.nist.gov/publications/detail/fips/180/4/
-              final>.
+          final>.
-  [FIPS186]  National Institute of Standards and Technology, "Digital
+[FIPS186]  National Institute of Standards and Technology, "Digital
-              Signature Standard (DSS)", DOI 10.6028/NIST.FIPS.186-4,
+          Signature Standard (DSS)", DOI 10.6028/NIST.FIPS.186-4,
-              FIPS PUB 186-4, July 2013,
+          FIPS PUB 186-4, July 2013,
-              <https://csrc.nist.gov/publications/detail/fips/186/4/
+          <https://csrc.nist.gov/publications/detail/fips/186/4/
-              final>.
+          final>.
-  [FIPS197]  National Institute of Standards and Technology, "Advanced
+[FIPS197]  National Institute of Standards and Technology, "Advanced
-              Encryption Standard (AES)", DOI 10.6028/NIST.FIPS.197,
+          Encryption Standard (AES)", DOI 10.6028/NIST.FIPS.197,
-              FIPS PUB 197, November 2001,
+          FIPS PUB 197, November 2001,
-              <https://csrc.nist.gov/publications/detail/fips/197/
+          <https://csrc.nist.gov/publications/detail/fips/197/
-              final>.
+          final>.
-  [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+[[RFC2119]]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119,
+          Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]],
-              DOI 10.17487/RFC2119, March 1997,
+          DOI 10.17487/RFC2119, March 1997,
-              <https://www.rfc-editor.org/info/rfc2119>.
+          <https://www.rfc-editor.org/info/rfc2119>.
-  [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
+[[RFC2631]]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
-              RFC 2631, DOI 10.17487/RFC2631, June 1999,
+          [[RFC2631|RFC 2631]], DOI 10.17487/RFC2631, June 1999,
-              <https://www.rfc-editor.org/info/rfc2631>.
+          <https://www.rfc-editor.org/info/rfc2631>.
-  [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
+[[RFC3370]]  Housley, R., "Cryptographic Message Syntax (CMS)
-              Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002,
+          Algorithms", [[RFC3370|RFC 3370]], DOI 10.17487/RFC3370, August 2002,
-              <https://www.rfc-editor.org/info/rfc3370>.
+          <https://www.rfc-editor.org/info/rfc3370>.
-  [RFC3560]  Housley, R., "Use of the RSAES-OAEP Key Transport
+[[RFC3560]]  Housley, R., "Use of the RSAES-OAEP Key Transport
-              Algorithm in Cryptographic Message Syntax (CMS)",
+          Algorithm in Cryptographic Message Syntax (CMS)",
-              RFC 3560, DOI 10.17487/RFC3560, July 2003,
+          [[RFC3560|RFC 3560]], DOI 10.17487/RFC3560, July 2003,
-              <https://www.rfc-editor.org/info/rfc3560>.
+          <https://www.rfc-editor.org/info/rfc3560>.
-  [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
+[[RFC3565]]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
-              Encryption Algorithm in Cryptographic Message Syntax
+          Encryption Algorithm in Cryptographic Message Syntax
-              (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,
+          (CMS)", [[RFC3565|RFC 3565]], DOI 10.17487/RFC3565, July 2003,
-              <https://www.rfc-editor.org/info/rfc3565>.
+          <https://www.rfc-editor.org/info/rfc3565>.
-  [RFC4055]  Schaad, J., Kaliski, B., and R. Housley, "Additional
+[[RFC4055]]  Schaad, J., Kaliski, B., and R. Housley, "Additional
-              Algorithms and Identifiers for RSA Cryptography for use in
+          Algorithms and Identifiers for RSA Cryptography for use in
-              the Internet X.509 Public Key Infrastructure Certificate
+          the Internet X.509 Public Key Infrastructure Certificate
-              and Certificate Revocation List (CRL) Profile", RFC 4055,
+          and Certificate Revocation List (CRL) Profile", [[RFC4055|RFC 4055]],
-              DOI 10.17487/RFC4055, June 2005,
+          DOI 10.17487/RFC4055, June 2005,
-              <https://www.rfc-editor.org/info/rfc4055>.
+          <https://www.rfc-editor.org/info/rfc4055>.
-  [RFC4056]  Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in
+[[RFC4056]]  Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in
-              Cryptographic Message Syntax (CMS)", RFC 4056,
+          Cryptographic Message Syntax (CMS)", [[RFC4056|RFC 4056]],
-              DOI 10.17487/RFC4056, June 2005,
+          DOI 10.17487/RFC4056, June 2005,
-              <https://www.rfc-editor.org/info/rfc4056>.
+          <https://www.rfc-editor.org/info/rfc4056>.
-  [RFC5083]  Housley, R., "Cryptographic Message Syntax (CMS)
+[[RFC5083]]  Housley, R., "Cryptographic Message Syntax (CMS)
-              Authenticated-Enveloped-Data Content Type", RFC 5083,
+          Authenticated-Enveloped-Data Content Type", [[RFC5083|RFC 5083]],
-              DOI 10.17487/RFC5083, November 2007,
+          DOI 10.17487/RFC5083, November 2007,
-              <https://www.rfc-editor.org/info/rfc5083>.
+          <https://www.rfc-editor.org/info/rfc5083>.
-  [RFC5084]  Housley, R., "Using AES-CCM and AES-GCM Authenticated
+[[RFC5084]]  Housley, R., "Using AES-CCM and AES-GCM Authenticated
-              Encryption in the Cryptographic Message Syntax (CMS)",
+          Encryption in the Cryptographic Message Syntax (CMS)",
-              RFC 5084, DOI 10.17487/RFC5084, November 2007,
+          [[RFC5084|RFC 5084]], DOI 10.17487/RFC5084, November 2007,
-              <https://www.rfc-editor.org/info/rfc5084>.
+          <https://www.rfc-editor.org/info/rfc5084>.
-  [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
+[[RFC5480]]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
-              "Elliptic Curve Cryptography Subject Public Key
+          "Elliptic Curve Cryptography Subject Public Key
-              Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
+          Information", [[RFC5480|RFC 5480]], DOI 10.17487/RFC5480, March 2009,
-              <https://www.rfc-editor.org/info/rfc5480>.
+          <https://www.rfc-editor.org/info/rfc5480>.
-  [RFC5649]  Housley, R. and M. Dworkin, "Advanced Encryption Standard
+[[RFC5649]]  Housley, R. and M. Dworkin, "Advanced Encryption Standard
-              (AES) Key Wrap with Padding Algorithm", RFC 5649,
+          (AES) Key Wrap with Padding Algorithm", [[RFC5649|RFC 5649]],
-              DOI 10.17487/RFC5649, September 2009,
+          DOI 10.17487/RFC5649, September 2009,
-              <https://www.rfc-editor.org/info/rfc5649>.
+          <https://www.rfc-editor.org/info/rfc5649>.
-  [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+[[RFC5652]]  Housley, R., "Cryptographic Message Syntax (CMS)", [[STD70|STD 70]],
-              RFC 5652, DOI 10.17487/RFC5652, September 2009,
+          [[RFC5652|RFC 5652]], DOI 10.17487/RFC5652, September 2009,
-              <https://www.rfc-editor.org/info/rfc5652>.
+          <https://www.rfc-editor.org/info/rfc5652>.
-  [RFC5753]  Turner, S. and D. Brown, "Use of Elliptic Curve
+[[RFC5753]]  Turner, S. and D. Brown, "Use of Elliptic Curve
-              Cryptography (ECC) Algorithms in Cryptographic Message
+          Cryptography (ECC) Algorithms in Cryptographic Message
-              Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January
+          Syntax (CMS)", [[RFC5753|RFC 5753]], DOI 10.17487/RFC5753, January
 , <https://www.rfc-editor.org/info/rfc5753>.
-  [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic
+[[RFC5754]]  Turner, S., "Using SHA2 Algorithms with Cryptographic
-              Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
+          Message Syntax", [[RFC5754|RFC 5754]], DOI 10.17487/RFC5754, January
 , <https://www.rfc-editor.org/info/rfc5754>.
-  [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
+[[RFC8017]]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
-              "PKCS #1: RSA Cryptography Specifications Version 2.2",
+          "PKCS #1: RSA Cryptography Specifications Version 2.2",
-              RFC 8017, DOI 10.17487/RFC8017, November 2016,
+          [[RFC8017|RFC 8017]], DOI 10.17487/RFC8017, November 2016,
-              <https://www.rfc-editor.org/info/rfc8017>.
+          <https://www.rfc-editor.org/info/rfc8017>.
-  [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+[[RFC8174]]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
-Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+Key Words", [[BCP14|BCP 14]], [[RFC8174|RFC 8174]], DOI 10.17487/RFC8174,
-              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+          May 2017, <https://www.rfc-editor.org/info/rfc8174>.
-  [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
+[[RFC8551]]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
-              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
+          Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
-              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
+          Message Specification", [[RFC8551|RFC 8551]], DOI 10.17487/RFC8551,
-              April 2019, <https://www.rfc-editor.org/info/rfc8551>.
+          April 2019, <https://www.rfc-editor.org/info/rfc8551>.
-  [RFC8603]  Jenkins, M. and L. Zieglar, "Commercial National Security
+[[RFC8603]]  Jenkins, M. and L. Zieglar, "Commercial National Security
-              Algorithm (CNSA) Suite Certificate and Certificate
+          Algorithm (CNSA) Suite Certificate and Certificate
-              Revocation List (CRL) Profile", RFC 8603,
+          Revocation List (CRL) Profile", [[RFC8603|RFC 8603]],
-              DOI 10.17487/RFC8603, May 2019,
+          DOI 10.17487/RFC8603, May 2019,
-              <https://www.rfc-editor.org/info/rfc8603>.
+          <https://www.rfc-editor.org/info/rfc8603>.
-  [SEC1]    Standards for Efficient Cryptography Group, "SEC1:
+[SEC1]    Standards for Efficient Cryptography Group, "SEC1:
-              Elliptic Curve Cryptography", May 2009,
+          Elliptic Curve Cryptography", May 2009,
-              <https://www.secg.org/sec1-v2.pdf>.
+          <https://www.secg.org/sec1-v2.pdf>.
-  [SP80038A] Dworkin, M., "Recommendation for Block Cipher Modes of
+[SP80038A] Dworkin, M., "Recommendation for Block Cipher Modes of
-              Operation: Methods and Techniques",
+          Operation: Methods and Techniques",
-              DOI 10.6028/NIST.SP.800-38A, Special Publication 800-38A,
+          DOI 10.6028/NIST.SP.800-38A, Special Publication 800-38A,
-              December 2001, <https://csrc.nist.gov/publications/detail/
+          December 2001, <https://csrc.nist.gov/publications/detail/
-              sp/800-38a/final>.
+          sp/800-38a/final>.
-  [SP80038D] Dworkin, M., "Recommendation for Block Cipher Modes of
+[SP80038D] Dworkin, M., "Recommendation for Block Cipher Modes of
-              Operation: Galois/Counter Mode (GCM) and GMAC",
+          Operation: Galois/Counter Mode (GCM) and GMAC",
-              DOI 10.6028/NIST.SP.800-38D, Special Publication 800-38D,
+          DOI 10.6028/NIST.SP.800-38D, Special Publication 800-38D,
-              November 2007, <https://csrc.nist.gov/publications/detail/
+          November 2007, <https://csrc.nist.gov/publications/detail/
-              sp/800-38d/final>.
+          sp/800-38d/final>.
-  [SP80038F] Dworkin, M., "Recommendation for Block Cipher Modes of
+[SP80038F] Dworkin, M., "Recommendation for Block Cipher Modes of
-              Operation: Methods for Key Wrapping",
+          Operation: Methods for Key Wrapping",
-              DOI 10.6028/NIST.SP.800-38F, Special Publication 800-38F,
+          DOI 10.6028/NIST.SP.800-38F, Special Publication 800-38F,
-              December 2012, <https://csrc.nist.gov/publications/detail/
+          December 2012, <https://csrc.nist.gov/publications/detail/
-              sp/800-38f/final>.
+          sp/800-38f/final>.
-  [X208]    CCITT, "Specification of Abstract Syntax Notation One
+[X208]    CCITT, "Specification of Abstract Syntax Notation One
-              (ASN.1)", CCITT Recommendation X.208, 1988,
+          (ASN.1)", CCITT Recommendation X.208, 1988,
-              <https://www.itu.int/rec/T-REC-X.208-198811-W/en>.
+          <https://www.itu.int/rec/T-REC-X.208-198811-W/en>.
-  [X209]    CCITT, "Specification of Basic Encoding Rules for Abstract
+[X209]    CCITT, "Specification of Basic Encoding Rules for Abstract
-              Syntax Notation One (ASN.1)", CCITT Recommendation X.209,
+          Syntax Notation One (ASN.1)", CCITT Recommendation X.209,
 , <https://www.itu.int/rec/T-REC-X.209-198811-W/en>.
-  [X509]    CCITT, "The Directory - Authentication Framework", CCITT
+[X509]    CCITT, "The Directory - Authentication Framework", CCITT
-              Recommendation X.509, 1988,
+          Recommendation X.509, 1988,
-              <https://www.itu.int/rec/T-REC-X.509-198811-S>.
+          <https://www.itu.int/rec/T-REC-X.509-198811-S>.
 .2.  Informative References
-  [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
+[[RFC4086]]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
-              "Randomness Requirements for Security", BCP 106, RFC 4086,
+          "Randomness Requirements for Security", [[BCP106|BCP 106]], [[RFC4086|RFC 4086]],
-              DOI 10.17487/RFC4086, June 2005,
+          DOI 10.17487/RFC4086, June 2005,
-              <https://www.rfc-editor.org/info/rfc4086>.
+          <https://www.rfc-editor.org/info/rfc4086>.
-  [SP80059]  Barker, W., "Guideline for Identifying an Information
+[SP80059]  Barker, W., "Guideline for Identifying an Information
-              System as a National Security System",
+          System as a National Security System",
-              DOI 10.6028/NIST.SP.800-59, Special Publication 800-59,
+          DOI 10.6028/NIST.SP.800-59, Special Publication 800-59,
-              August 2003, <https://csrc.nist.gov/publications/detail/
+          August 2003, <https://csrc.nist.gov/publications/detail/
-              sp/800-59/final>.
+          sp/800-59/final>.
 Author's Address
-  Michael Jenkins
+Michael Jenkins
-  National Security Agency
+National Security Agency
+Email: [email protected]
-  Email: [email protected]
+[[Category:Informational]]

Anonymous

Search

Difference between revisions of "RFC8755"

Latest revision as of 10:47, 30 October 2020

Contents

Introduction

Terminology

The Commercial National Security Algorithm Suite

Requirements and Assumptions

SHA-384 Message Digest Algorithm

Digital Signature

ECDSA Signature

RSA Signature

RSA-PKCS1-v1_5

RSA-PSS

Key Establishment

Elliptic Curve Key Agreement

Key Derivation Functions

AES Key Wrap

RSA Key Transport

RSAES-PKCS1-v1_5

RSAES-OAEP

Content Encryption

AES-GCM Content Encryption

AES-CBC Content Encryption

Security Considerations

IANA Considerations

Navigation

Wiki tools

Page tools

Categories