summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6318.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6318.txt')
-rw-r--r--doc/rfc/rfc6318.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc6318.txt b/doc/rfc/rfc6318.txt
new file mode 100644
index 0000000..7308189
--- /dev/null
+++ b/doc/rfc/rfc6318.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Housley
+Request for Comments: 6318 Vigil Security
+Obsoletes: 5008 J. Solinas
+Category: Informational National Security Agency
+ISSN: 2070-1721 June 2011
+
+
+ Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)
+
+Abstract
+
+ This document specifies the conventions for using the United States
+ National Security Agency's Suite B algorithms in Secure/Multipurpose
+ Internet Mail Extensions (S/MIME) as specified in RFC 5751. This
+ document obsoletes RFC 5008.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6318.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley & Solinas Informational [Page 1]
+
+RFC 6318 Suite B in S/MIME June 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 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
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Terminology ................................................4
+ 1.2. ASN.1 ......................................................4
+ 1.3. Suite B Security Levels ....................................4
+ 2. SHA-256 and SHA-384 Message Digest Algorithms ...................5
+ 3. ECDSA Signature Algorithm .......................................6
+ 4. Key Management ..................................................7
+ 4.1. ECDH Key Agreement Algorithm ...............................7
+ 4.2. AES Key Wrap ...............................................8
+ 4.3. Key Derivation Functions ...................................9
+ 5. AES CBC Content Encryption .....................................11
+ 6. Security Considerations ........................................12
+ 7. References .....................................................13
+ 7.1. Normative References ......................................13
+ 7.2. Informative References ....................................14
+
+
+
+
+
+
+
+Housley & Solinas Informational [Page 2]
+
+RFC 6318 Suite B in S/MIME June 2011
+
+
+1. Introduction
+
+ The Fact Sheet on National Security Agency (NSA) Suite B Cryptography
+ [NSA] states:
+
+ A Cryptographic Interoperability Strategy (CIS) was developed to
+ find ways to increase assured rapid sharing of information both
+ within the U.S. and between the U.S. and her partners through the
+ use of a common suite of public standards, protocols, algorithms
+ and modes referred to as the "Secure Sharing Suite" or S.3. The
+ implementation of CIS will facilitate the development of a broader
+ range of secure cryptographic products which will be available to
+ a wide customer base. The use of selected public cryptographic
+ standards and protocols and Suite B is the core of CIS.
+
+ In 2005, NSA announced Suite B Cryptography which built upon the
+ National Policy on the use of the Advanced Encryption Standard
+ (AES) to Protect National Security Systems and National Security
+ Information. In addition to the AES algorithm, Suite B includes
+ cryptographic algorithms for key exchanges, digital signatures and
+ hashing. Suite B cryptography has been selected from cryptography
+ that has been approved by NIST for use by the U.S. Government and
+ specified in NIST standards or recommendations.
+
+ This document specifies the conventions for using the United States
+ National Security Agency's Suite B algorithms [NSA] in
+ Secure/Multipurpose Internet Mail Extensions (S/MIME) [MSG]. S/MIME
+ makes use of the Cryptographic Message Syntax (CMS) [CMS]. In
+ particular, the signed-data and the enveloped-data content types are
+ used. This document only addresses Suite B compliance for S/MIME.
+ Other applications of CMS are outside the scope of this document.
+
+ Since many of the Suite B algorithms enjoy uses in other environments
+ as well, the majority of the conventions needed for the Suite B
+ 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 Suite B.
+
+ This specification obsoletes RFC 5008 [SUITEBSMIME]. The primary
+ reason for the publication of this document is to allow greater
+ flexibility in the use of the Suite B Security Levels as discussed in
+ Section 1.3. It also removes some duplication between this document
+ and referenced RFCs.
+
+
+
+
+
+
+
+
+Housley & Solinas Informational [Page 3]
+
+RFC 6318 Suite B in S/MIME June 2011
+
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [STDWORDS].
+
+1.2. ASN.1
+
+ CMS values are generated using ASN.1 [X.208-88], the Basic Encoding
+ Rules (BER) [X.209-88], and the Distinguished Encoding Rules (DER)
+ [X.509-88].
+
+1.3. Suite B Security Levels
+
+ Suite B offers two suites of algorithms for key agreement, key
+ derivation, key wrap and content encryption, and two possible
+ combinations of hash and signing algorithm. Suite B algorithms are
+ defined to support two minimum levels of cryptographic security: 128
+ and 192 bits.
+
+ For S/MIME signed messages, Suite B follows the direction set by
+ RFC 5753 [CMSECC] and RFC 5754 [SHA2]. Suite B uses these
+ combinations of message digest (hash) and signature functions (Sig
+ Sets):
+
+ Sig Set 1 Sig Set 2
+ ---------------- ----------------
+ Message Digest: SHA-256 SHA-384
+ Signature: ECDSA with P-256 ECDSA with P-384
+
+ For S/MIME encrypted messages, Suite B follows the direction set by
+ RFC 5753 [CMSECC] and follows the conventions set by RFC 3565
+ [CMSAES].
+
+ Suite B uses these key establishment (KE) algorithms (KE Sets):
+
+ KE Set 1 KE Set 2
+ ---------------- ----------------
+ Key Agreement: ECDH with P-256 ECDH with P-384
+ Key Derivation: SHA-256 SHA-384
+ Key Wrap: AES-128 Key Wrap AES-256 Key Wrap
+ Content Encryption: AES-128 CBC AES-256 CBC
+
+
+
+
+
+
+
+
+
+Housley & Solinas Informational [Page 4]
+
+RFC 6318 Suite B in S/MIME June 2011
+
+
+ The two elliptic curves used in Suite B are specified in [DSS], and
+ each appear in the literature under two different names. For the
+ sake of clarity, we list both names below:
+
+ Curve NIST Name SECG Name OID [DSS]
+ ---------------------------------------------------------
+ nistp256 P-256 secp256r1 1.2.840.10045.3.1.7
+ nistp384 P-384 secp384r1 1.3.132.0.34
+
+ If configured at a minimum level of security of 128 bits, a Suite B
+ compliant S/MIME system performing encryption MUST use either KE
+ Set 1 or KE Set 2, with KE Set 1 being the preferred suite. A
+ digital signature, if applied, MUST use either Sig Set 1 or Sig Set
+ 2, independent of the encryption choice.
+
+ A recipient in an S/MIME system configured at a minimum level of
+ security of 128 bits MUST be able to verify digital signatures from
+ Sig Set 1 and SHOULD be able to verify digital signatures from Sig
+ Set 2.
+
+ Note that for S/MIME systems configured at a minimum level of
+ security of 128 bits, the algorithm set used for a signed-data
+ content type is independent of the algorithm set used for an
+ enveloped-data content type.
+
+ If configured at a minimum level of security of 192 bits, a Suite B
+ compliant S/MIME system performing encryption MUST use KE Set 2. A
+ digital signature, if applied, MUST use Sig Set 2.
+
+ A recipient in an S/MIME system configured at a minimum level of
+ security of 192 bits MUST be able to verify digital signatures from
+ Sig Set 2.
+
+2. SHA-256 and SHA-384 Message Digest Algorithms
+
+ SHA-256 and SHA-384 are the Suite B message digest algorithms.
+ RFC 5754 [SHA2] specifies the conventions for using SHA-256 and
+ SHA-384 with the Cryptographic Message Syntax (CMS). Suite B
+ compliant S/MIME implementations MUST follow the conventions in
+ RFC 5754. Relevant details are repeated below.
+
+ 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-256 and SHA-384 message digest algorithms are defined in FIPS
+ Pub 180-3 [SHA2FIPS]. The algorithm identifiers for SHA-256 and
+ SHA-384 are defined in [SHA2] and are repeated here:
+
+
+
+Housley & Solinas Informational [Page 5]
+
+RFC 6318 Suite B in S/MIME June 2011
+
+
+ id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
+ country(16) us(840) organization(1) gov(101) csor(3)
+ nistalgorithm(4) hashalgs(2) 1 }
+
+ 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 both SHA-256 and SHA-384, the AlgorithmIdentifier parameters
+ field is OPTIONAL, and if present, the parameters field MUST contain
+ a NULL. Implementations MUST accept SHA-256 and SHA-384
+ AlgorithmIdentifiers with absent parameters. Implementations MUST
+ accept SHA-256 and SHA-384 AlgorithmIdentifiers with NULL parameters.
+ As specified in RFC 5754 [SHA2], implementations MUST generate
+ SHA-256 and SHA-384 AlgorithmIdentifiers with absent parameters.
+
+3. ECDSA Signature Algorithm
+
+ In Suite B, public key certificates used to verify S/MIME signatures
+ MUST be compliant with the Suite B Certificate Profile specified in
+ RFC 5759 [SUITEBCERT].
+
+ The Elliptic Curve Digital Signature Algorithm (ECDSA) is the Suite B
+ digital signature algorithm. RFC 5753 [CMSECC] specifies the
+ conventions for using ECDSA with the Cryptographic Message Syntax
+ (CMS). Suite B compliant S/MIME implementations MUST follow the
+ conventions in RFC 5753. Relevant details are repeated below.
+
+ Within the CMS signed-data content type, signature algorithm
+ identifiers are located in the SignerInfo signatureAlgorithm field of
+ SignedData. In addition, signature algorithm identifiers are located
+ in the SignerInfo signatureAlgorithm field of countersignature
+ attributes.
+
+ RFC 5480 [PKI-ALG] defines the signature algorithm identifiers used
+ in CMS for ECDSA with SHA-256 and ECDSA with SHA-384. The
+ identifiers are repeated here:
+
+ ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+ us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 }
+
+ ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+ us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 3 }
+
+ When either the ecdsa-with-SHA256 or the ecdsa-with-SHA384 algorithm
+ identifier is used, the AlgorithmIdentifier parameters field MUST be
+ absent.
+
+
+
+
+Housley & Solinas Informational [Page 6]
+
+RFC 6318 Suite B in S/MIME June 2011
+
+
+ When signing, the ECDSA algorithm generates two values, commonly
+ called r and s. To transfer these two values as one signature, they
+ MUST be encoded using the ECDSA-Sig-Value type specified in RFC 5480
+ [PKI-ALG]:
+
+ ECDSA-Sig-Value ::= SEQUENCE {
+ r INTEGER,
+ s INTEGER }
+
+4. Key Management
+
+ CMS accommodates the following general key management techniques: key
+ agreement, key transport, previously distributed symmetric key-
+ encryption keys, and passwords. In Suite B for S/MIME, ephemeral-
+ static key agreement MUST be used as described in Section 4.1.
+
+ When a key agreement algorithm is used, a key-encryption algorithm is
+ also needed. In Suite B for S/MIME, the Advanced Encryption Standard
+ (AES) Key Wrap, as specified in RFC 3394 [SH] and [AESWRAP], MUST be
+ used as the key-encryption algorithm. AES Key Wrap is discussed
+ further in Section 4.2. The key-encryption key used with the AES Key
+ Wrap algorithm is obtained from a key derivation function (KDF). In
+ Suite B for S/MIME, there are two KDFs -- one based on SHA-256 and
+ one based on SHA-384. These KDFs are discussed further in
+ Section 4.3.
+
+4.1. ECDH Key Agreement Algorithm
+
+ Elliptic Curve Diffie-Hellman (ECDH) is the Suite B key agreement
+ algorithm.
+
+ S/MIME is used in store-and-forward communications, which means that
+ 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 represented by an X.509 certificate. In Suite B, the certificate
+ used to obtain the recipient's public key MUST be compliant with the
+ Suite B Certificate Profile specified in RFC 5759 [SUITEBCERT].
+
+ Section 3.1 of RFC 5753 [CMSECC] specifies the conventions for using
+ ECDH with the CMS. Suite B compliant S/MIME implementations MUST
+ follow these conventions. Relevant details are repeated below.
+
+ Within the CMS enveloped-data content type, key agreement algorithm
+ identifiers are located in the EnvelopedData RecipientInfos
+ KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
+
+
+
+
+
+Housley & Solinas Informational [Page 7]
+
+RFC 6318 Suite B in S/MIME June 2011
+
+
+ keyEncryptionAlgorithm MUST be one of the two algorithm identifiers
+ listed below, and the algorithm identifier parameter field MUST be
+ present and identify the key wrap algorithm. The key wrap algorithm
+ denotes the symmetric encryption algorithm used to encrypt the
+ content-encryption key with the pairwise key-encryption key generated
+ using the ephemeral-static ECDH key agreement algorithm (see
+ Section 4.3).
+
+ When implementing KE Set 1, the keyEncryptionAlgorithm MUST be
+ dhSinglePass-stdDH-sha256kdf-scheme, and the keyEncryptionAlgorithm
+ parameter MUST be a KeyWrapAlgorithm containing id-aes128-wrap (see
+ Section 4.2). When implementing KE Set 2, the keyEncryptionAlgorithm
+ MUST be dhSinglePass-stdDH-sha384kdf-scheme, and the
+ keyEncryptionAlgorithm parameter MUST be a KeyWrapAlgorithm
+ containing id-aes256-wrap.
+
+ The algorithm identifiers for dhSinglePass-stdDH-sha256kdf-scheme and
+ dhSinglePass-stdDH-sha384kdf-scheme, repeated from Section 7.1.4 of
+ [CMSECC], are:
+
+ dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::=
+ { iso(1) identified-organization(3) certicom(132)
+ schemes(1) 11 1 }
+
+ dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::=
+ { iso(1) identified-organization(3) certicom(132)
+ schemes(1) 11 2 }
+
+ Both of these algorithm identifiers use KeyWrapAlgorithm as the type
+ for their parameter:
+
+ KeyWrapAlgorithm ::= AlgorithmIdentifier
+
+4.2. AES Key Wrap
+
+ The AES Key Wrap key-encryption algorithm, as specified in RFC 3394
+ [SH] and [AESWRAP], is used to encrypt the content-encryption key
+ with a pairwise key-encryption key that is generated using ephemeral-
+ static ECDH. Section 8 of RFC 5753 [CMSECC] specifies the
+ conventions for using AES Key Wrap with the pairwise key generated
+ with ephemeral-static ECDH with the CMS. Suite B compliant S/MIME
+ implementations MUST follow these conventions. Relevant details are
+ repeated below.
+
+ When implementing KE Set 1, the KeyWrapAlgorithm MUST be
+ id-aes128-wrap. When implementing KE Set 2, the KeyWrapAlgorithm
+ MUST be id-aes256-wrap.
+
+
+
+
+Housley & Solinas Informational [Page 8]
+
+RFC 6318 Suite B in S/MIME June 2011
+
+
+ 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 algorithm identifiers for AES Key Wrap are specified in RFC 3394
+ [SH], and the ones needed for Suite B compliant S/MIME
+ implementations are repeated here:
+
+ id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
+ country(16) us(840) organization(1) gov(101) csor(3)
+ nistAlgorithm(4) aes(1) 5 }
+
+ id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
+ country(16) us(840) organization(1) gov(101) csor(3)
+ nistAlgorithm(4) aes(1) 45 }
+
+4.3. Key Derivation Functions
+
+ KDFs based on SHA-256 and SHA-384 are used to derive a pairwise key-
+ encryption key from the shared secret produced by ephemeral-static
+ ECDH. Sections 7.1.8 and 7.2 of RFC 5753 [CMSECC] specify the
+ conventions for using the KDF with the shared secret generated with
+ ephemeral-static ECDH with the CMS. Suite B compliant S/MIME
+ implementations MUST follow these conventions. Relevant details are
+ repeated below.
+
+ When implementing KE Set 1, the KDF based on SHA-256 MUST be used.
+ When implementing KE Set 2, the KDF based on SHA-384 MUST be used.
+
+ As specified in Section 7.2 of RFC 5753 [CMSECC], using ECDH with the
+ CMS enveloped-data content type, the derivation of key-encryption
+ keys makes use of the ECC-CMS-SharedInfo type, which is repeated
+ here:
+
+ ECC-CMS-SharedInfo ::= SEQUENCE {
+ keyInfo AlgorithmIdentifier,
+ entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
+ suppPubInfo [2] EXPLICIT OCTET STRING }
+
+
+
+
+
+
+
+
+
+
+
+
+Housley & Solinas Informational [Page 9]
+
+RFC 6318 Suite B in S/MIME June 2011
+
+
+ In Suite B 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. In Suite B
+ for S/MIME, if the AES-128 Key Wrap is used, then the keyInfo
+ will contain id-aes128-wrap, and the parameters will be absent.
+ In Suite B for S/MIME, if AES-256 Key Wrap is used, then the
+ keyInfo will contain id-aes256-wrap, and the parameters will be
+ absent.
+
+ entityUInfo optionally contains a random value provided by the
+ message originator. If the user keying material (ukm) is
+ present, 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 RFC 2631 [CMSDH]. When a 128-bit AES key is used,
+ the length MUST be 0x00000080. When a 256-bit AES key is used,
+ the length MUST be 0x00000100.
+
+ ECC-CMS-SharedInfo is DER encoded and used as input to the key
+ derivation function, as specified in Section 3.6.1 of [SEC1]. Note
+ that ECC-CMS-SharedInfo differs from the OtherInfo specified in
+ [CMSDH]. 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 [SEC1] provides an algorithm for generating an
+ essentially arbitrary amount of keying material (KM) from the shared
+ secret produced by ephemeral-static ECDH, which is called Z for the
+ remainder of this discussion. The KDF can be summarized as:
+
+ KM = Hash ( Z || Counter || ECC-CMS-SharedInfo )
+
+ To generate a key-encryption key (KEK), one or more KM blocks are
+ generated, incrementing Counter appropriately, until enough material
+ has been generated. The KM blocks are concatenated left to right:
+
+ KEK = KM ( counter=1 ) || KM ( counter=2 ) ...
+
+ The elements of the KDF are used as follows:
+
+ Hash is the one-way hash function. If KE Set 1 is used, the
+ SHA-256 hash MUST be used. If KE Set 2 is used, the SHA-384
+ hash MUST be used.
+
+
+
+Housley & Solinas Informational [Page 10]
+
+RFC 6318 Suite B in S/MIME June 2011
+
+
+ Z is the shared secret value generated by ephemeral-static ECDH.
+ Leading zero bits MUST be preserved. In Suite B for S/MIME, if
+ KE Set 1 is used, Z MUST be exactly 256 bits. In Suite B for
+ S/MIME, if KE Set 2 is used, Z MUST be exactly 384 bits.
+
+ Counter is a 32-bit unsigned number, represented in network byte
+ order. Its initial value MUST be 0x00000001 for any key
+ derivation operation. In Suite B for S/MIME, with both KE
+ Set 1 and KE Set 2, exactly one iteration is needed; the
+ Counter is not incremented.
+
+ ECC-CMS-SharedInfo is composed as described above. It MUST be DER
+ encoded.
+
+ To generate a key-encryption key, one KM block is generated, with a
+ Counter value of 0x00000001:
+
+ KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo )
+
+ In Suite B for S/MIME, when KE Set 1 is used, the key-encryption key
+ MUST be the most significant 128 bits of the SHA-256 output value.
+ In Suite B for S/MIME, when KE Set 2 is used, the key-encryption key
+ MUST be the most significant 256 bits of the SHA-384 output value.
+
+ Note that the only source of secret entropy in this computation is Z.
+ The effective key space of the key-encryption key is limited by the
+ size of Z, in addition to any security level considerations imposed
+ by the elliptic curve that is used. However, if entityUInfo is
+ different for each message, a different key-encryption key will be
+ generated for each message.
+
+5. AES CBC Content Encryption
+
+ AES [AES] in Cipher Block Chaining (CBC) mode [MODES] is the Suite B
+ for S/MIME content-encryption algorithm. RFC 3565 [CMSAES] specifies
+ the conventions for using AES with the CMS. Suite B compliant S/MIME
+ implementations MUST follow these conventions. Relevant details are
+ repeated below.
+
+ In Suite B for S/MIME, if KE Set 1 is used, AES-128 in CBC mode MUST
+ be used for content encryption. In Suite B for S/MIME, if KE Set 2
+ is used, AES-256 in CBC mode MUST be used.
+
+ 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.
+
+
+
+Housley & Solinas Informational [Page 11]
+
+RFC 6318 Suite B in S/MIME June 2011
+
+
+ The AES CBC content-encryption algorithm is described in [AES] and
+ [MODES]. The algorithm identifier for AES-128 in CBC mode is:
+
+ id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
+ country(16) us(840) organization(1) gov(101) csor(3)
+ nistAlgorithm(4) aes(1) 2 }
+
+ 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 [RANDOM] for guidance on generation of random
+ values.
+
+6. Security Considerations
+
+ This document specifies the conventions for using the NSA's Suite B
+ algorithms in S/MIME. All of the algorithms and algorithm
+ identifiers have been specified in previous documents.
+
+ Two minimum levels of security may be achieved using this
+ specification. Users must consider their risk environment to
+ determine which level is appropriate for their own use.
+
+ See [RANDOM] for guidance on generation of random values.
+
+ The security considerations in RFC 5652 [CMS] discuss the CMS as a
+ method for digitally signing data and encrypting data.
+
+ The security considerations in RFC 3370 [CMSALG] discuss
+ cryptographic algorithm implementation concerns in the context of the
+ CMS.
+
+ The security considerations in RFC 5753 [CMSECC] discuss the use of
+ elliptic curve cryptography (ECC) in the CMS.
+
+ The security considerations in RFC 3565 [CMSAES] discuss the use of
+ AES in the CMS.
+
+
+
+
+
+Housley & Solinas Informational [Page 12]
+
+RFC 6318 Suite B in S/MIME June 2011
+
+
+7. References
+
+7.1. Normative References
+
+ [AES] National Institute of Standards and Technology, "Advanced
+ Encryption Standard (AES)", FIPS PUB 197, November 2001.
+
+ [AESWRAP] National Institute of Standards and Technology, "AES Key
+ Wrap Specification", November 2001.
+
+ [DSS] National Institute of Standards and Technology, "Digital
+ Signature Standard (DSS)", FIPS PUB 186-3, June 2009.
+
+ [CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
+ STD 70, RFC 5652, September 2009.
+
+ [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard
+ (AES) Encryption Algorithm in Cryptographic Message
+ Syntax (CMS)", RFC 3565, July 2003.
+
+ [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
+ Algorithms", RFC 3370, August 2002.
+
+ [CMSDH] Rescorla, E., "Diffie-Hellman Key Agreement Method",
+ RFC 2631, June 1999.
+
+ [CMSECC] Turner, S. and D. Brown, "Use of Elliptic Curve
+ Cryptography (ECC) Algorithms in Cryptographic Message
+ Syntax (CMS)", RFC 5753, January 2010.
+
+ [MODES] National Institute of Standards and Technology, "DES
+ Modes of Operation", FIPS Pub 81, December 1980.
+
+ [MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
+ Mail Extensions (S/MIME) Version 3.2 Message
+ Specification", RFC 5751, January 2010.
+
+ [PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
+ "Elliptic Curve Cryptography Subject Public Key
+ Information", RFC 5480, March 2009.
+
+ [SEC1] Standards for Efficient Cryptography Group, "SEC 1:
+ Elliptic Curve Cryptography", September 2000.
+ <http://www.secg.org/collateral/sec1_final.pdf>.
+
+ [SH] Schaad, J. and R. Housley, "Advanced Encryption Standard
+ (AES) Key Wrap Algorithm", RFC 3394, September 2002.
+
+
+
+
+Housley & Solinas Informational [Page 13]
+
+RFC 6318 Suite B in S/MIME June 2011
+
+
+ [SHA2] Turner, S., "Using SHA2 Algorithms with Cryptographic
+ Message Syntax", RFC 5754, January 2010.
+
+ [SHA2FIPS] National Institute of Standards and Technology, "Secure
+ Hash Standard (SHS)", FIPS 180-3, October 2008.
+
+ [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [SUITEBCERT]
+ Solinas, J. and L. Zieglar, "Suite B Certificate and
+ Certificate Revocation List (CRL) Profile", RFC 5759,
+ January 2010.
+
+ [SUITEBSMIME]
+ Housley, R. and J. Solinas, "Suite B in
+ Secure/Multipurpose Internet Mail Extensions (S/MIME)",
+ RFC 5008, September 2007.
+
+ [X.208-88] CCITT. Recommendation X.208: Specification of Abstract
+ Syntax Notation One (ASN.1). 1988.
+
+ [X.209-88] CCITT. Recommendation X.209: Specification of Basic
+ Encoding Rules for Abstract Syntax Notation One (ASN.1).
+ 1988.
+
+ [X.509-88] CCITT. Recommendation X.509: The Directory -
+ Authentication Framework. 1988.
+
+7.2. Informative References
+
+ [RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker,
+ "Randomness Requirements for Security", BCP 106,
+ RFC 4086, June 2005.
+
+ [NSA] U.S. National Security Agency, "Fact Sheet NSA Suite B
+ Cryptography", January 2009.
+ <http://www.nsa.gov/ia/programs/suiteb_cryptography>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley & Solinas Informational [Page 14]
+
+RFC 6318 Suite B in S/MIME June 2011
+
+
+Authors' Addresses
+
+ Russell Housley
+ Vigil Security, LLC
+ 918 Spring Knoll Drive
+ Herndon, VA 20170
+ USA
+
+ EMail: housley@vigilsec.com
+
+
+ Jerome A. Solinas
+ National Information Assurance Laboratory
+ National Security Agency
+ 9800 Savage Road
+ Fort George G. Meade, MD 20755
+ USA
+
+ EMail: jasolin@orion.ncsc.mil
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley & Solinas Informational [Page 15]
+