< draft-housley-rfc5008bis-00.txt   draft-housley-rfc5008bis-01.txt >
Internet-Draft R. Housley Internet-Draft R. Housley
Obsoletes: 5008 (if approved) Vigil Security Obsoletes: 5008 (if approved) Vigil Security
Intended Status: Informational J. Solinas Intended Status: Informational J. Solinas
National Security Agency National Security Agency
Expires: August 14, 2011 February 10, 2011 Expires: October 27, 2011 April 25, 2011
Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)
draft-housley-rfc5008bis-00 draft-housley-rfc5008bis-01
Abstract Abstract
This document specifies the conventions for using the United States This document specifies the conventions for using the United States
National Security Agency's Suite B algorithms in Secure/Multipurpose National Security Agency's Suite B algorithms in Secure/Multipurpose
Internet Mail Extensions (S/MIME) as specified in RFC 5751. Internet Mail Extensions (S/MIME) as specified in RFC 5751. This
document obsoletes RFC 5008.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 2, line 30 skipping to change at page 2, line 30
1.1. Terminology ............................................. 4 1.1. Terminology ............................................. 4
1.2. ASN.1 ................................................... 4 1.2. ASN.1 ................................................... 4
1.3. Suite B Security Levels ................................. 4 1.3. Suite B Security Levels ................................. 4
2. SHA-256 and SHA-384 Message Digest Algorithms ................. 5 2. SHA-256 and SHA-384 Message Digest Algorithms ................. 5
3. ECDSA Signature Algorithm .................................... 6 3. ECDSA Signature Algorithm .................................... 6
4. Key Management ................................................ 7 4. Key Management ................................................ 7
4.1. ECDH Key Agreement Algorithm ............................ 7 4.1. ECDH Key Agreement Algorithm ............................ 7
4.2. AES Key Wrap ............................................ 8 4.2. AES Key Wrap ............................................ 8
4.3. Key Derivation Functions ................................ 9 4.3. Key Derivation Functions ................................ 9
5. AES CBC Content Encryption ................................... 11 5. AES CBC Content Encryption ................................... 11
6. IANA Considerations .......................................... 12 6. IANA Considerations .......................................... 11
7. Security Considerations ...................................... 12 7. Security Considerations ...................................... 12
8. References .................................................... 12 8. References .................................................... 12
8.1. Normative References ................................... 12 8.1. Normative References ................................... 12
8.2. Informative References ................................. 14 8.2. Informative References ................................. 14
Authors' Addresses ............................................... 14 Authors' Addresses ............................................... 14
1. Introduction 1. Introduction
The Fact Sheet on National Security Agency (NSA) Suite B Cryptography The Fact Sheet on National Security Agency (NSA) Suite B Cryptography
[NSA] states: [NSA] states:
skipping to change at page 4, line 38 skipping to change at page 4, line 38
Sig Set 1 Sig Set 2 Sig Set 1 Sig Set 2
---------------- ---------------- ---------------- ----------------
Message Digest: SHA-256 SHA-384 Message Digest: SHA-256 SHA-384
Signature: ECDSA with P-256 ECDSA with P-384 Signature: ECDSA with P-256 ECDSA with P-384
For S/MIME encrypted messages, Suite B follows the direction set by For S/MIME encrypted messages, Suite B follows the direction set by
RFC 5753 [CMSECC] and follows the conventions set by RFC 3565 RFC 5753 [CMSECC] and follows the conventions set by RFC 3565
[CMSAES]. [CMSAES].
Suite B uses these algorithms (KE Sets): Suite B uses these key establishment (KE) algorithms (KE Sets):
KE Set 1 KE Set 2 KE Set 1 KE Set 2
---------------- ---------------- ---------------- ----------------
Key Agreement: ECDH with P-256 ECDH with P-384 Key Agreement: ECDH with P-256 ECDH with P-384
Key Derivation: SHA-256 SHA-384 Key Derivation: SHA-256 SHA-384
Key Wrap: AES-128 Key Wrap AES-256 Key Wrap Key Wrap: AES-128 Key Wrap AES-256 Key Wrap
Content Encryption: AES-128 CBC AES-256 CBC Content Encryption: AES-128 CBC AES-256 CBC
The two elliptic curves used in Suite B are specified in [DSS] and The two elliptic curves used in Suite B are specified in [DSS] and
each appear in the literature under two different names. For sake of each appear in the literature under two different names. For sake of
skipping to change at page 6, line 19 skipping to change at page 6, line 19
For both SHA-256 and SHA-384, the AlgorithmIdentifier parameters For both SHA-256 and SHA-384, the AlgorithmIdentifier parameters
field is OPTIONAL, and if present, the parameters field MUST contain field is OPTIONAL, and if present, the parameters field MUST contain
a NULL. Implementations MUST accept SHA-256 and SHA-384 a NULL. Implementations MUST accept SHA-256 and SHA-384
AlgorithmIdentifiers with absent parameters. Implementations MUST AlgorithmIdentifiers with absent parameters. Implementations MUST
accept SHA-256 and SHA-384 AlgorithmIdentifiers with NULL parameters. accept SHA-256 and SHA-384 AlgorithmIdentifiers with NULL parameters.
As specified in RFC 5754 [SHA2], implementations MUST generate As specified in RFC 5754 [SHA2], implementations MUST generate
SHA-256 and SHA-384 AlgorithmIdentifiers with absent parameters. SHA-256 and SHA-384 AlgorithmIdentifiers with absent parameters.
3. ECDSA Signature Algorithm 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 The Elliptic Curve Digital Signature Algorithm (ECDSA) is the Suite B
digital signature algorithm. RFC 5753 [CMSECC] specifies the digital signature algorithm. RFC 5753 [CMSECC] specifies the
conventions for using ECDSA with the Cryptographic Message Syntax conventions for using ECDSA with the Cryptographic Message Syntax
(CMS). Suite B compliant S/MIME implementations MUST follow the (CMS). Suite B compliant S/MIME implementations MUST follow the
conventions in RFC 5753 along with the following guidance. conventions in RFC 5753. Relevant details are repeated below.
Within the CMS signed-data content type, signature algorithm Within the CMS signed-data content type, signature algorithm
identifiers are located in the SignerInfo signatureAlgorithm field of identifiers are located in the SignerInfo signatureAlgorithm field of
SignedData. In addition, signature algorithm identifiers are located SignedData. In addition, signature algorithm identifiers are located
in the SignerInfo signatureAlgorithm field of countersignature in the SignerInfo signatureAlgorithm field of countersignature
attributes. attributes.
RFC 5480 [PKI-ALG] defines the signature algorithm identifiers used RFC 5480 [PKI-ALG] defines the signature algorithm identifiers used
in CMS for ECDSA with SHA-256 and ECDSA with SHA-384. The in CMS for ECDSA with SHA-256 and ECDSA with SHA-384. The
identifiers are repeated here: identifiers are repeated here:
skipping to change at page 6, line 46 skipping to change at page 6, line 50
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 } us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 }
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 3 } 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 When either the ecdsa-with-SHA256 or the ecdsa-with-SHA384 algorithm
identifier is used, the AlgorithmIdentifier parameters field MUST be identifier is used, the AlgorithmIdentifier parameters field MUST be
absent. absent.
When signing, the ECDSA algorithm generates two values, commonly When signing, the ECDSA algorithm generates two values, commonly
called r and s. To transfer these two values as one signature, they called r and s. To transfer these two values as one signature,
MUST be encoded using the ECDSA-Sig-Value type specified in RFC 5480 they MUST be encoded using the ECDSA-Sig-Value type specified in RFC
[PKI-ALG]: 5480 [PKI-ALG]:
ECDSA-Sig-Value ::= SEQUENCE { ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER, r INTEGER,
s INTEGER } s INTEGER }
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].
4. Key Management 4. Key Management
CMS accommodates the following general key management techniques: key CMS accommodates the following general key management techniques: key
agreement, key transport, previously distributed symmetric key- agreement, key transport, previously distributed symmetric key-
encryption keys, and passwords. In Suite B for S/MIME, ephemeral- encryption keys, and passwords. In Suite B for S/MIME, ephemeral-
static key agreement MUST be used as described in Section 4.1. static key agreement MUST be used as described in Section 4.1.
When a key agreement algorithm is used, a key-encryption algorithm is When a key agreement algorithm is used, a key-encryption algorithm is
also needed. In Suite B for S/MIME, the Advanced Encryption Standard also needed. In Suite B for S/MIME, the Advanced Encryption Standard
(AES) Key Wrap, as specified in RFC 3394 [AESWRAP, SH], MUST be used (AES) Key Wrap, as specified in RFC 3394 [AESWRAP, SH], MUST be used
as the key-encryption algorithm. AES Key Wrap is discussed further 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 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 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 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. on SHA-384. These KDFs are discussed further in Section 4.3.
4.1. ECDH Key Agreement Algorithm 4.1. ECDH Key Agreement Algorithm
Elliptic Curve Diffie-Hellman (ECDH) is the Suite B key agreement Elliptic Curve Diffie-Hellman (ECDH) is the Suite B key agreement
algorithm. Section 3.1 of RFC 5753 [CMSECC] specifies the algorithm.
conventions for using ECDH with the Cryptographic Message Syntax
(CMS). Suite B compliant S/MIME implementations MUST follow these
conventions as well as the additional guidance in this section.
S/MIME is used in store-and-forward communications, which means that S/MIME is used in store-and-forward communications, which means that
ephemeral-static ECDH is always employed. This means that the ephemeral-static ECDH is always employed. This means that the
message originator possesses an ephemeral ECDH key and that the message originator possesses an ephemeral ECDH key pair and that the
message recipient possesses a static ECDH key pair whose public key message recipient possesses a static ECDH key pair whose public key
is represented by an X.509 certificate. In Suite B, the certificate 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 used to obtain the recipient's public key MUST be compliant with the
Suite B Certificate Profile specified in RFC 5759 [SUITEBCERT]. 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 Within the CMS enveloped-data content type, key agreement algorithm
identifiers are located in the EnvelopedData RecipientInfos identifiers are located in the EnvelopedData RecipientInfos
KeyAgreeRecipientInfo keyEncryptionAlgorithm field. KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
keyEncryptionAlgorithm MUST be one of the two algorithm identifiers keyEncryptionAlgorithm MUST be one of the two algorithm identifiers
listed below, and the algorithm identifier parameter field MUST be listed below, and the algorithm identifier parameter field MUST be
present and identify the key wrap algorithm. The key wrap algorithm present and identify the key wrap algorithm. The key wrap algorithm
denotes the symmetric encryption algorithm used to encrypt the denotes the symmetric encryption algorithm used to encrypt the
content-encryption key with the pairwise key-encryption key generated content-encryption key with the pairwise key-encryption key generated
using the ephemeral-static ECDH key agreement algorithm (see Section using the ephemeral-static ECDH key agreement algorithm (see Section
skipping to change at page 8, line 32 skipping to change at page 8, line 36
{ iso(1) identified-organization(3) certicom(132) { iso(1) identified-organization(3) certicom(132)
schemes(1) 11 2 } schemes(1) 11 2 }
Both of these algorithm identifiers use KeyWrapAlgorithm as the type Both of these algorithm identifiers use KeyWrapAlgorithm as the type
for their parameter: for their parameter:
KeyWrapAlgorithm ::= AlgorithmIdentifier KeyWrapAlgorithm ::= AlgorithmIdentifier
4.2. AES Key Wrap 4.2. AES Key Wrap
CMS offers support for symmetric key-encryption key management; The AES Key Wrap key-encryption algorithm, as specified in RFC 3394
however, it is not used in Suite B for S/MIME. Rather, the AES Key [AESWRAP, SH], is used to encrypt the content-encryption key with a
Wrap key-encryption algorithm, as specified in RFC 3394 [AESWRAP, pairwise key-encryption key that is generated using ephemeral-static
SH], is used to encrypt the content-encryption key with a pairwise ECDH. Section 8 of RFC 5753 [CMSECC] specifies the conventions for
key-encryption key that is generated using ephemeral-static ECDH. using AES Key Wrap with the pairwise key generated with epheneral-
When implementing KE Set 1, the KeyWrapAlgorithm MUST be id- static ECDH with the CMS. Suite B compliant S/MIME implementations
aes128-wrap. When implementing KE Set 2, the KeyWrapAlgorithm MUST MUST follow these conventions. Relevant details are repeated below.
be id-aes256-wrap.
When implementing KE Set 1, the KeyWrapAlgorithm MUST be
id-aes128-wrap. When implementing KE Set 2, the KeyWrapAlgorithm
MUST be id-aes256-wrap.
Within the CMS enveloped-data content type, key wrap algorithm Within the CMS enveloped-data content type, key wrap algorithm
identifiers are located in the KeyWrapAlgorithm parameters within the identifiers are located in the KeyWrapAlgorithm parameters within the
EnvelopedData RecipientInfos KeyAgreeRecipientInfo EnvelopedData RecipientInfos KeyAgreeRecipientInfo
keyEncryptionAlgorithm field. keyEncryptionAlgorithm field.
The algorithm identifiers for AES Key Wrap are specified in RFC 3394 The algorithm identifiers for AES Key Wrap are specified in RFC 3394
[SH], and the ones needed for Suite B compliant S/MIME [SH], and the ones needed for Suite B compliant S/MIME
implementations are repeated here: implementations are repeated here:
id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 5 } nistAlgorithm(4) aes(1) 5 }
id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 45 } nistAlgorithm(4) aes(1) 45 }
4.3. Key Derivation Functions 4.3. Key Derivation Functions
CMS offers support for deriving symmetric key-encryption keys from KDFs based on SHA-256 and SHA-384 are used to derive a pairwise key-
passwords; however, password-based key management is not used in encryption key from the shared secret produced by ephemeral-static
Suite B for S/MIME. Rather, KDFs based on SHA-256 and SHA-384 are ECDH. Sections 7.1.8 and 7.2 of RFC 5753 [CMSECC] specify the
used to derive a pairwise key-encryption key from the shared secret conventions for using the KDF with the shared secret generated with
produced by ephemeral-static ECDH. When implementing KE Set 1, the ephemeral-static ECDH with the CMS. Suite B compliant S/MIME
KDF based on SHA-256 MUST be used. When implementing KE Set 2, the implementations MUST follow these conventions. Relevant details are
KDF based on SHA-384 MUST be used. 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 As specified in Section 7.2 of RFC 5753 [CMSECC], using ECDH with the
CMS enveloped-data content type, the derivation of key- encryption CMS enveloped-data content type, the derivation of key-encryption
keys makes use of the ECC-CMS-SharedInfo type, which is repeated keys makes use of the ECC-CMS-SharedInfo type, which is repeated
here: here:
ECC-CMS-SharedInfo ::= SEQUENCE { ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier, keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING } suppPubInfo [2] EXPLICIT OCTET STRING }
In Suite B for S/MIME, the fields of ECC-CMS-SharedInfo are used as In Suite B for S/MIME, the fields of ECC-CMS-SharedInfo are used as
follows: follows:
skipping to change at page 11, line 15 skipping to change at page 11, line 24
Note that the only source of secret entropy in this computation is Z. 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 The effective key space of the key-encryption key is limited by the
size of Z, in addition to any security level considerations imposed size of Z, in addition to any security level considerations imposed
by the elliptic curve that is used. However, if entityUInfo is by the elliptic curve that is used. However, if entityUInfo is
different for each message, a different key-encryption key will be different for each message, a different key-encryption key will be
generated for each message. generated for each message.
5. AES CBC Content Encryption 5. AES CBC Content Encryption
This section specifies the conventions employed by implementations AES [AES] in Cipher Block Chaining (CBC) mode [MODES] is the Suite B
that support content encryption using AES [AES] in Cipher Block for S/MIME content-encryption algorithm. RFC 3565 [CMSAES] specifies
Chaining (CBC) mode [MODES]. The conventions in RFC 3565 [CMSAES] the conventions for using AES with the CMS. Suite B compliant S/MIME
are followed. In Suite B for S/MIME, if KE Set 1 is used, AES-128 in implementations MUST follow these conventions. Relevant details are
CBC mode MUST be used for content encryption. In Suite B for S/MIME, repeated below.
if KE Set 2 is used, AES-256 in CBC mode MUST be used.
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 Within the CMS enveloped-data content type, content encryption
algorithm identifiers are located in the EnvelopedData algorithm identifiers are located in the EnvelopedData
EncryptedContentInfo contentEncryptionAlgorithm field. The content EncryptedContentInfo contentEncryptionAlgorithm field. The content
encryption algorithm is used to encipher the content located in the encryption algorithm is used to encipher the content located in the
EnvelopedData EncryptedContentInfo encryptedContent field. EnvelopedData EncryptedContentInfo encryptedContent field.
The AES CBC content-encryption algorithm is described in [AES] and The AES CBC content-encryption algorithm is described in [AES] and
[MODES]. The algorithm identifier for AES-128 in CBC mode is: [MODES]. The algorithm identifier for AES-128 in CBC mode is:
 End of changes. 16 change blocks. 
40 lines changed or deleted 51 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/