Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail ExtensionsNational Security Agencymjjenki@nsa.gov
Security
Internet Engineering Task ForceNSACNSANSSsmimeThe 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
.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() 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.
Table of Contents
. Introduction
. Terminology
. The Commercial National Security Algorithm Suite
. Requirements and Assumptions
. SHA-384 Message Digest Algorithm
. Digital Signature
. ECDSA Signature
. RSA Signature
. Key Establishment
. Elliptic Curve Key Agreement
. RSA Key Transport
. Content Encryption
. AES-GCM Content Encryption
. AES-CBC Content Encryption
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Author's Address
IntroductionThis document specifies the conventions for using the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) . 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.
S/MIME makes use of the Cryptographic Message Syntax (CMS) . 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
when, and only when, they appear in all capitals, as shown here.
The Commercial National Security Algorithm SuiteThe 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 AssumptionsCMS values are generated using ASN.1 , the Basic Encoding Rules (BER) , and the Distinguished Encoding Rules (DER) .
The elliptic curve used in the CNSA Suite is specified in and appears in the literature under two different names. For the sake of clarity, we list both names below:
Curve
NIST Name
SECG Name
OID [FIPS186]
nistp384
P-384
secp384r1
1.3.132.0.34
For CNSA Suite applications, public key certificates used to verify S/MIME signatures MUST be compliant with the CNSA Suite Certificate and Certificate Revocation List (CRL) profile specified in .
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 ; 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 and , 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 216 < e < 2256 and be odd per .
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 , 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 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 and , respectively.
SHA-384 Message Digest AlgorithmSHA-384 is the sole CNSA Suite message digest algorithm. specifies the conventions for using SHA-384 with the Cryptographic Message Syntax (CMS). CNSA Suite-compliant S/MIME implementations MUST follow the conventions in .
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 . The algorithm identifier for SHA-384 is defined in 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 , implementations MUST generate SHA-384 AlgorithmIdentifiers with absent parameters. Implementations MUST accept SHA-384 AlgorithmIdentifiers with absent parameters or with NULL parameters.
Digital SignatureECDSA SignatureThe Elliptic Curve Digital Signature Algorithm (ECDSA) is the CNSA Suite digital signature algorithm based on ECC. specifies the conventions for using ECDSA with the Cryptographic Message Syntax (CMS). CNSA Suite-compliant S/MIME implementations MUST follow the conventions in .
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 :
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
RSA SignatureThe 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 .
RSA-PKCS1-v1_5 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 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 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 ;
The mask generation function MUST use the algorithm identifier mfg1SHA384Identifier as defined in ;
The salt length MUST be 48 octets (the same length as the SHA-384 output); and
The trailerField MUST have value 1.
Key EstablishmentElliptic Curve Key AgreementElliptic 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 .
When a key agreement algorithm is used, the following steps are performed:
A content-encryption key (CEK) for a particular content-encryption algorithm is generated at random.
The recipient's public key and sender's private key are used with a key agreement scheme to generate a shared secret (Z).
The shared secret is used with a key derivation function (KDF) to produce a key-encryption key (KEK).
The KEK is used with a key wrap algorithm to encrypt the CEK.
Key derivation is discussed in . Key wrapping is discussed in .
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 , 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 .
Key Derivation FunctionsKDFs based on SHA-384 are used to derive a pairwise
key-encryption key from the shared secret produced by
ephemeral-static ECDH. Sections and in 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 , the ANSI-X9.63-KDF described in Section 3.6.1 of and based on SHA-384 MUST be used.
As specified in , 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 . 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 . Note that ECC-CMS-SharedInfo differs from the OtherInfo specified in . Here, a counter value is not included in the keyInfo field because the KDF specified in ensures that sufficient keying data is provided.
The KDF specified in Section 3.6.1 of 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 WrapThe AES Key Wrap with Padding key-encryption algorithm, as specified in and , is used to encrypt the content-encryption key with a pairwise key-encryption key that is generated using ephemeral-static ECDH. 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 , 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 TransportRSA encryption (RSA) is the CNSA Suite key transport algorithm. The RSA key transport algorithm is the RSA encryption scheme defined in , 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 . These certificates are suitable for use with either RSAES-OAEP or RSAES-PKCS1-v1_5.
RSAES-PKCS1-v1_5 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 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 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 ;
The mask generation function must use the algorithm identifier mfg1SHA384Identifier as defined in ;
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 , with the sequence representing the rSAES-OAEP-SHA384-Identifier.
Content EncryptionAES-GCM is the preferred mode for CNSA Suite applications, as described in the Security Considerations. AES-CBC is acceptable where AES-GCM is not yet available.
AES-GCM Content EncryptionCNSA Suite-compliant S/MIME implementations using the
authenticated-enveloped-data content type MUST use AES in Galois Counter Mode (GCM) as the content-authenticated encryption algorithm and MUST follow the conventions for using AES-GCM with the CMS defined in .
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 and . 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 . 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 EncryptionCNSA Suite-compliant S/MIME implementations using the
enveloped-data content type MUST use AES-256 in Cipher Block Chaining (CBC)
mode as the content-encryption algorithm and MUST follow the conventions for using AES with the CMS defined in .
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 and . 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 for guidance on generation of random values.
Security ConsiderationsThis 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 for guidance on generation of random values.
The security considerations in discuss the CMS as a method for digitally signing data and encrypting data.
The security considerations in discuss cryptographic algorithm implementation concerns in the context of the CMS.
The security considerations in discuss the use of elliptic curve cryptography (ECC) in the CMS.
The security considerations in discuss the use of AES in the CMS.
The security considerations in 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 ConsiderationsThis document has no IANA actions.
ReferencesNormative ReferencesUse of Public Standards for Secure Information SharingCommittee for National Security SystemsSecure Hash Standard (SHS)National Institute of Standards and TechnologyDigital Signature Standard (DSS)National Institute of Standards and TechnologyAdvanced Encryption Standard (AES)National Institute of Standards and TechnologyKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Diffie-Hellman Key Agreement MethodThis document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. [STANDARDS-TRACK]Cryptographic Message Syntax (CMS) AlgorithmsUse of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS). The CMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients. [STANDARDS-TRACK]Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. [STANDARDS-TRACK]Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)This document specifies the conventions for using the RSASSA-PSS (RSA Probabilistic Signature Scheme) digital signature algorithm with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content TypeThis document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS-TRACK]Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)This document specifies the conventions for using the AES-CCM and the AES-GCM authenticated encryption algorithms with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. [STANDARDS-TRACK]Elliptic Curve Cryptography Subject Public Key InformationThis document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK]Advanced Encryption Standard (AES) Key Wrap with Padding AlgorithmThis document specifies a padding convention for use with the AES Key Wrap algorithm specified in RFC 3394. This convention eliminates the requirement that the length of the key to be wrapped be a multiple of 64 bits, allowing a key of any practical length to be wrapped. This memo provides information for the Internet community.Cryptographic Message Syntax (CMS)This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)This document describes how to use Elliptic Curve Cryptography (ECC) public key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180-3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC 4231 for message authentication code standards. This document obsoletes RFC 3278. This document is not an Internet Standards Track specification; it is published for informational purposes.Using SHA2 Algorithms with Cryptographic Message SyntaxThis document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK]PKCS #1: RSA Cryptography Specifications Version 2.2This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.This document also obsoletes RFC 3447.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message SpecificationThis document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751.Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) ProfileThis document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. 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.SEC1: Elliptic Curve CryptographyStandards for Efficient Cryptography GroupRecommendation for Block Cipher Modes of Operation: Methods and TechniquesRecommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMACRecommendation for Block Cipher Modes of Operation: Methods for Key WrappingSpecification of Abstract Syntax Notation One (ASN.1)CCITTSpecification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)CCITTThe Directory - Authentication FrameworkCCITTInformative ReferencesRandomness Requirements for SecuritySecurity systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Guideline for Identifying an Information System as a National Security SystemAuthor's AddressNational Security Agencymjjenki@nsa.gov