idnits 2.17.1 draft-housley-smime-suite-b-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 694. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 707. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 390 -- Looks like a reference, but probably isn't: '2' on line 391 == Unused Reference: 'ECDSA' is defined on line 550, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'AESWRAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECDSA' ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 3278 (ref. 'CMSECC') (Obsoleted by RFC 5753) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1363' -- Possible downref: Non-RFC (?) normative reference: ref. 'MODES' ** Obsolete normative reference: RFC 3851 (ref. 'MSG') (Obsoleted by RFC 5751) ** Obsolete normative reference: RFC 3280 (ref. 'PKIX1') (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' ** Downref: Normative reference to an Informational RFC: RFC 3394 (ref. 'SH') -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA2' -- Obsolete informational reference (is this intentional?): RFC 4634 (ref. 'EH') (Obsoleted by RFC 6234) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT R. Housley 3 Vigil Security 4 Expires December 2007 J. Solinas 5 June 2007 NSA 7 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than a "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 This document specifies the conventions for using the United States 36 National Security Agency's Suite B algorithms in Secure/Multipurpose 37 Internet Mail Extensions (S/MIME) as specified in RFC 3851. 39 1. Introduction 41 This document specifies the conventions for using the United States 42 National Security Agency's Suite B algorithms [SuiteB] in 43 Secure/Multipurpose Internet Mail Extensions (S/MIME) [MSG]. S/MIME 44 makes use of the Cryptographic Message Syntax (CMS) [CMS]. In 45 particular, the signed-data and the enveloped-data content types are 46 used. 48 Since many of the Suite B algorithms enjoy uses in other environments 49 as well, the majority of the conventions needed for the Suite B 50 algorithms are already specified in other documents. This document 51 references the source of these conventions, and the relevant details 52 are repeated to aid developers that choose to support Suite B. In a 53 few cases, additional algorithm identifiers are needed, and they are 54 provided in this document. 56 1.1. Terminology 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [STDWORDS]. 62 1.2. ASN.1 64 CMS values are generated using ASN.1 [X.208-88], using the Basic 65 Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules 66 (DER) [X.509-88]. 68 1.3. Suite B Security Levels 70 Suite B offers two security levels: Level 1 and Level 2. Security 71 Level 2 offers greater cryptographic strength by using longer keys. 73 For S/MIME signed messages, Suite B follows the direction set by RFC 74 3278 [CMSECC], but some additional algorithm identifiers are 75 assigned. Suite B uses these algorithms: 77 Security Level 1 Security Level 2 78 ---------------- ---------------- 79 Message Digest: SHA-256 SHA-384 80 Signature: ECDSA with P-256 ECDSA with P-384 82 For S/MIME encrypted messages, Suite B follows the direction set by 83 RFC 3278 [CMSECC] and follows the conventions set by RFC 3565 84 [CMSAES]. Again, additional algorithm identifiers are assigned. 85 Suite B uses these algorithms: 87 Security Level 1 Security Level 2 88 ---------------- ---------------- 89 Key Agreement: ECDH with P-256 ECDH with P-384 90 Key Derivation: SHA-256 SHA-384 91 Key Wrap: AES-128 Key Wrap AES-256 Key Wrap 92 Content Encryption: AES-128 CBC AES-256 CBC 94 2. SHA-256 and SHA-256 Message Digest Algorithms 96 This section specifies the conventions employed by implementations 97 that support SHA-256 or SHA-384 [SHA2]. In Suite B Security Level 1, 98 the SHA-256 message digest algorithm MUST be used. In Suite B 99 Security Level 2, SHA-384 MUST be used. 101 Within the CMS signed-data content type, message digest algorithm 102 identifiers are located in the SignedData digestAlgorithms field and 103 the SignerInfo digestAlgorithm field. Also, message digest values 104 are located in the Message Digest authenticated attribute. In 105 addition, message digest values are input to signature algorithms. 107 The SHA-256 and SHA-384 message digest algorithms are defined in FIPS 108 Pub 180-2 [SHA2, EH]. The algorithm identifier for SHA-256 is: 110 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 111 country(16) us(840) organization(1) gov(101) csor(3) 112 nistalgorithm(4) hashalgs(2) 1 } 114 The algorithm identifier for SHA-384 is: 116 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 117 country(16) us(840) organization(1) gov(101) csor(3) 118 nistalgorithm(4) hashalgs(2) 2 } 120 There are two possible encodings for the AlgorithmIdentifier 121 parameters field. The two alternatives arise from the fact that when 122 the 1988 syntax for AlgorithmIdentifier was translated into the 1997 123 syntax the OPTIONAL associated with the AlgorithmIdentifier 124 parameters got lost. Later the OPTIONAL was recovered via a defect 125 report, but by then many people thought that algorithm parameters 126 were mandatory. Because of this history some implementations encode 127 parameters as a NULL element and others omit them entirely. The 128 correct encoding for the SHA-256 and SHA-384 message digest 129 algorithms is to omit the parameters field; however, to ensure 130 compatibility, implementations ought to also handle a SHA-256 and 131 SHA-384 AlgorithmIdentifier parameters field which contains a NULL. 133 For both SHA-256 and SHA-384, the AlgorithmIdentifier parameters 134 field is OPTIONAL, and if present, the parameters field MUST contain 135 a NULL. Implementations MUST accept SHA-256 and SHA-384 136 AlgorithmIdentifiers with absent parameters. Implementations MUST 137 accept SHA-256 and SHA-384 AlgorithmIdentifiers with NULL parameters. 138 Implementations SHOULD generate SHA-256 and SHA-384 139 AlgorithmIdentifiers with absent parameters. 141 3. ECDSA Signature Algorithm 143 This section specifies the conventions employed by implementations 144 that support ECDSA. The direction set by RFC 3278 [CMSECC] is 145 followed, but additional message digest algorithms and additional 146 elliptic curves are employed. In Suite B Security Level 1, ECDSA 147 MUST be used with the SHA-256 message digest algorithm and the P-256 148 elliptic curve. In Suite B Security Level 2, ECDSA MUST be used with 149 the SHA-384 message digest algorithm and the P-384 elliptic curve. 150 The P-256 and P-384 elliptic curves are specified in [DSS]. 152 Within the CMS signed-data content type, signature algorithm 153 identifiers are located in the SignerInfo signatureAlgorithm field of 154 SignedData. In addition, signature algorithm identifiers are located 155 in the SignerInfo signatureAlgorithm field of countersignature 156 attributes. 158 Within the CMS signed-data content type, signature values are located 159 in the SignerInfo signature field of SignedData. In addition, 160 signature values are located in the SignerInfo signature field of 161 countersignature attributes. 163 As specified in RFC 3279 [PKIX1ALG], ECDSA and ECDH use the same 164 algorithm identifier for subject public keys in certificates, and it 165 is repeated here: 167 id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2) 168 us(840) ansi-x9-62(10045) keyType(2) 1 } 170 This object identifier is used in public key certificates for both 171 ECDSA signature keys and ECDH encryption keys. The intended 172 application for the key may be indicated in the key usage field (see 173 RFC 3280 [PKIX1]). The use of separate keys for signature and 174 encryption purposes is RECOMMENDED; however, the use of a single key 175 for both signature and encryption purposes is not forbidden. 177 As specified in RFC 3279 [PKIX1ALG], ECDSA and ECDH use the same 178 encoding for subject public keys in certificates, and it is repeated 179 here: 181 ECPoint ::= OCTET STRING 183 The elliptic curve public key (an OCTET STRING) is mapped to a 184 subject public key (a BIT STRING) as follows: the most significant 185 bit of the OCTET STRING becomes the most significant bit of the BIT 186 STRING, and the least significant bit of the OCTET STRING becomes 187 the least significant bit of the BIT STRING. Note that this octet 188 string may represent an elliptic curve point in compressed or 189 uncompressed form. Implementations that support elliptic curves 190 according to this specification MUST support the uncompressed form 191 and MAY support the compressed form. 193 ECDSA and ECDH require use of certain parameters with the public key. 194 The parameters may be inherited from the certificate issuer, 195 implicitly included through reference to a named curve, or explicitly 196 included in the certificate. As specified in RFC 3279 [PKIX1ALG], 197 the parameter structure is: 199 EcpkParameters ::= CHOICE { 200 ecParameters ECParameters, 201 namedCurve OBJECT IDENTIFIER, 202 implicitlyCA NULL } 204 In Suite B, the namedCurve CHOICE MUST be used. The object 205 identifier for P-256 is: 207 ansip256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 208 us(840) ansi-x9-62(10045) curves(3) prime(1) 7 } 210 The object identifier for P-384 is: 212 secp384r1 OBJECT IDENTIFIER ::= { iso(1) 213 identified-organization(3) certicom(132) curve(0) 34 } 215 The algorithm identifier used in CMS for ECDSA with SHA-256 signature 216 values is: 218 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 219 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 } 221 The algorithm identifier used in CMS for ECDSA with SHA-384 signature 222 values is: 224 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 225 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 3 } 227 When either the ecdsa-with-SHA256 or the ecdsa-with-SHA384 algorithm 228 identifier is used, the AlgorithmIdentifier parameters field MUST be 229 absent. 231 When signing, the ECDSA algorithm generates two values, commonly 232 called r and s. To transfer these two values as one signature, they 233 MUST be encoded using the Ecdsa-Sig-Value type specified in RFC 3279 234 [PKIX1ALG]: 236 Ecdsa-Sig-Value ::= SEQUENCE { 237 r INTEGER, 238 s INTEGER } 240 4. Key Management 242 CMS accommodates the following general key management techniques: key 243 agreement, key transport, previously distributed symmetric key- 244 encryption keys, and passwords. In Suite B, ephemeral-static key 245 agreement MUST be used as described in Section 4.1. 247 When a key agreement algorithm is used, a key-encryption algorithm is 248 also needed. In Suite B, the AES key Wrap as specified in RFC 3394 249 [AESWRAP, SH] MUST be used as the key-encryption algorithm. AES Key 250 Wrap is discussed further in Section 4.2. The key-encryption key 251 used with the AES Key Wrap algorithm is obtained from a key 252 derivation function (KDF). In Suite B, there are two KDFs, one based 253 on SHA-256 and one based on SHA-384. These KDFs are discussed 254 further in Section 4.3. 256 4.1. ECDH Key Agreement Algorithm 258 This section specifies the conventions employed by implementations 259 that support ECDH. The direction set by RFC 3278 [CMSECC] is 260 followed, but additional key derivation functions and key wrap 261 algorithms are employed. S/MIME is used in store-and-forward 262 communications, which means that ephemeral-static ECDH is always 263 employed. This means that the message originator uses an ephemeral 264 ECDH key and that the message recipient uses a static ECDH key, which 265 is obtained from an X.509 certificate. In Suite B Security Level 1, 266 ephemeral-static ECDH MUST be used with the SHA-256 KDF, AES-128 key 267 wrap, and the P-256 elliptic curve. In Suite B Security Level 2, 268 ephemeral-static ECDH MUST be used with the SHA-384 KDF, AES-256 key 269 wrap, and the P-384 elliptic curve. 271 Within the CMS enveloped-data content type, key agreement algorithm 272 identifiers are located in the EnvelopedData RecipientInfos 273 KeyAgreeRecipientInfo keyEncryptionAlgorithm field. 275 As specified in RFC 3279 [PKIX1ALG], ECDSA and ECDH use the same 276 conventions for carrying a subject public key in a certificate. 277 These conventions are discussed in Section 3. 279 Ephemeral-static ECDH key agreement is defined in [SEC1] and 280 [IEEE1363]. When using ephemeral-static ECDH, the EnvelopedData 281 RecipientInfos keyAgreeRecipientInfo field is used as follows: 283 version MUST be 3. 285 originator MUST be the originatorKey alternative. The 286 originatorKey algorithm field MUST contain the id-ecPublicKey 287 object identifier (see Section 3) with NULL parameters. The 288 originatorKey publicKey field MUST contain the message 289 originator's ephemeral public key, which is a DER-encoded ECPoint 290 (see Section 3). The ECPoint SHOULD be represented in 291 uncompressed form. 293 ukm can be present or absent. However, message originators SHOULD 294 include the ukm. As specified in RFC 3852 [CMS], implementations 295 MUST support ukm message recipient processing, so interoperability 296 is not a concern if the ukm is present or absent. When present, 297 the ukm is used to ensure that a different key-encryption key is 298 generated, even when the ephemeral private key is improperly used 299 more than once. See [RANDOM] for guidance on generation of random 300 values. 302 keyEncryptionAlgorithm MUST be one of the two algorithm 303 identifiers listed below, and the algorithm identifier parameter 304 field MUST be present and identify the key wrap algorithm. The 305 key wrap algorithm denotes the symmetric encryption algorithm used 306 to encrypt the content-encryption key with the pairwise key- 307 encryption key generated using the ephemeral-static ECDH key 308 agreement algorithm (see Section 4.3). In Suite B Security Level 309 1, the keyEncryptionAlgorithm MUST be dhSinglePass-stdDH- 310 sha256kdf-scheme, and the keyEncryptionAlgorithm parameter MUST be 311 a KeyWrapAlgorithm containing id-aes128-wrap (see Section 4.2). 312 In Suite B Security Level 2, the keyEncryptionAlgorithm MUST be 313 dhSinglePass-stdDH-sha384kdf-scheme, and the 314 keyEncryptionAlgorithm parameter MUST be a KeyWrapAlgorithm 315 containing id-aes256-wrap (see Section 4.2). The algorithm 316 identifier for dhSinglePass-stdDH-sha256kdf-scheme and 317 dhSinglePass-stdDH-sha384kdf-scheme are: 319 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= 320 { iso(1) identified-organization(3) certicom(132) 321 schemes(1) 11 1 } 323 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= 324 { iso(1) identified-organization(3) certicom(132) 325 schemes(1) 11 2 } 327 Both of these algorithm identifiers use KeyWrapAlgorithm as the 328 type for their parameter: 330 KeyWrapAlgorithm ::= AlgorithmIdentifier 332 recipientEncryptedKeys contains an identifier and an encrypted key 333 for each recipient. The RecipientEncryptedKey 334 KeyAgreeRecipientIdentifier MUST contain either the 335 issuerAndSerialNumber identifying the recipient's certificate or 336 the RecipientKeyIdentifier containing the subject key identifier 337 from the recipient's certificate. In both cases, the recipient's 338 certificate contains the recipient's static ECDH public key. 339 RecipientEncryptedKey EncryptedKey MUST contain the content- 340 encryption key encrypted with the ephemeral-static ECDH generated 341 pairwise key-encryption key using the algorithm specified by the 342 KeyWrapAlgorithm (see section 4.3). 344 4.2. AES Key Wrap 346 CMS offers support for symmetric key-encryption key management; 347 however, it is not used in Suite B. Rather, the AES Key Wrap key- 348 encryption algorithm, as specified in RFC 3394 [AESWRAP, SH], is used 349 to encrypt the content-encryption key with a pairwise key-encryption 350 key that is generated using ephemeral-static ECDH. In Suite B 351 Security Level 1, AES-128 Key Wrap MUST be used as the key-encryption 352 algorithm. In Suite B Security Level 2, AES-256 Key Wrap MUST be 353 used as the key-encryption algorithm. 355 Within the CMS enveloped-data content type, wrapped content- 356 encryption keys are located in the EnvelopedData RecipientInfos 357 KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field, and 358 key wrap algorithm identifiers are located in the KeyWrapAlgorithm 359 parameters within the EnvelopedData RecipientInfos 360 KeyAgreeRecipientInfo keyEncryptionAlgorithm field. 362 The algorithm identifiers for AES Key Wrap are specified in RFC 3394 363 [SH], and the ones needed for Suite B are repeated here: 365 id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 366 country(16) us(840) organization(1) gov(101) csor(3) 367 nistAlgorithm(4) aes(1) 5 } 369 id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 370 country(16) us(840) organization(1) gov(101) csor(3) 371 nistAlgorithm(4) aes(1) 45 } 373 4.3. Key Derivation Functions 375 CMS offers support for deriving symmetric key-encryption keys from 376 passwords; however, password-based key management is not used in 377 Suite B. Rather, KDFs based on SHA-256 and SHA-384 are used to 378 derive a pairwise key-encryption key from the shared secret produced 379 by ephemeral-static ECDH. In Suite B Security Level 1, the KDF based 380 on SHA-256 MUST be used. In Suite B Security Level 2, KDF based on 381 SHA-384 MUST be used. 383 As specified in Section 8.2 of RFC 3278 [CMSECC], using ECDH with the 384 CMS enveloped-data content type, the derivation of key-encryption 385 keys makes use of the ECC-CMS-SharedInfo type, which is repeated 386 here: 388 ECC-CMS-SharedInfo ::= SEQUENCE { 389 keyInfo AlgorithmIdentifier, 390 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 391 suppPubInfo [2] EXPLICIT OCTET STRING } 393 In Suite B, the fields of ECC-CMS-SharedInfo are used as follows: 395 keyInfo contains the object identifier of the key-encryption 396 algorithm that will be used to wrap the content-encryption key and 397 NULL parameters. In Suite B Security Level 1, AES-128 Key Wrap 398 MUST be used, resulting in {id-aes128-wrap, NULL}. In Suite B 399 Security Level 2, AES-256 Key Wrap MUST be used, resulting in 400 {id-aes256-wrap, NULL}. 402 entityUInfo optionally contains a random value provided by the 403 message originator. If the ukm is present, then the entityUInfo 404 MUST be present, and it MUST contain the ukm value. If the ukm is 405 not present, then the entityUInfo MUST be absent. 407 suppPubInfo contains the length of the generated key-encryption 408 key, in bits, represented as a 32 bit unsigned number, as 409 described in RFC 2631 [CMSDH]. In Suite B Security Level 1, a 410 128-bit AES key MUST be used, resulting in 0x00000080. In Suite B 411 Security Level 2, a 256-bit AES key MUST be used, resulting in 412 0x00000100. 414 ECC-CMS-SharedInfo is DER-encoded and used as input to the key 415 derivation function, as specified in Section 3.6.1 of [SEC1]. Note 416 that ECC-CMS-SharedInfo differs from the OtherInfo specified in 417 [CMSDH]. Here, a counter value is not included in the keyInfo field 418 because the KDF specified in [SEC1] ensures that sufficient keying 419 data is provided. 421 The KDF specified in [SEC1] provides an algorithm for generating an 422 essentially arbitrary amount of keying material from the shared 423 secret produced by ephemeral-static ECDH, which is called Z for the 424 remainder of this discussion. The KDF can be summarized as: 426 KM = Hash ( Z || Counter || ECC-CMS-SharedInfo ) 428 To generate a key-encryption key, one or more KM blocks are 429 generated, incrementing Counter appropriately, until enough material 430 has been generated. The KM blocks are concatenated left to right: 432 KEK = KM ( counter=1 ) || KM ( counter=2 ) ... 434 The elements of the KDF are used as follows: 436 Hash is the one-way hash function, and it is either SHA-256 or 437 SHA-384 [SHA2]. In Suite B Security Level 1, the SHA-256 MUST be 438 used. In Suite B Security Level 2, SHA-384 MUST be used. 440 Z is the shared secret value generated by ephemeral-static ECDH. 441 Leading zero bits MUST be preserved. In Suite B Security Level 1, 442 Z MUST be exactly 256 bits. In Suite B Security Level 2, Z MUST 443 be exactly 384 bits. 445 Counter is a 32 bit unsigned number, represented in network byte 446 order. Its initial value MUST be 0x00000001 for any key 447 derivation operation. In Suite B Security Level 1 and Security 448 Level 2, exactly one iteration is needed; the Counter is not 449 incremented. 451 ECC-CMS-SharedInfo is composed as described above. It MUST be DER 452 encoded. 454 To generate a key-encryption key, one KM block is generated, with a 455 Counter value of 0x00000001: 457 KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo ) 459 In Suite B Security Level 1, the key-encryption key MUST be the most 460 significant 128 bits of the SHA-256 output value. In Suite B 461 Security Level 2, the key-encryption key MUST be the most significant 462 256 bits of the SHA-384 output value. 464 Note that the only source of secret entropy in this computation is Z. 465 The effective key space of the key-encryption key is limited by the 466 size of Z, in addition to any security level considerations imposed 467 by the elliptic curve that is used. However, if entityUInfo is 468 different for each message, a different key-encryption key will be 469 generated for each message. 471 5. AES CBC Content Encryption 473 This section specifies the conventions employed by implementations 474 that support content encryption using AES [AES] in Cipher Block 475 Chaining (CBC) mode [MODES]. The conventions in RFC 3565 [CMSAES] 476 are followed. In Suite B Security Level 1, the AES-128 in CBC mode 477 MUST be used for content encryption. In Suite B Security Level 2, 478 AES-256 in CBC mode MUST be used. 480 Within the CMS enveloped-data content type, content encryption 481 algorithm identifiers are located in the EnvelopedData 482 EncryptedContentInfo contentEncryptionAlgorithm field. The content 483 encryption algorithm is used to encipher the content located in the 484 EnvelopedData EncryptedContentInfo encryptedContent field. 486 The AES CBC content-encryption algorithm is described in [AES] and 487 [MODES]. The algorithm identifier for AES-128 in CBC mode is: 489 id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 490 country(16) us(840) organization(1) gov(101) csor(3) 491 nistAlgorithm(4) aes(1) 2 } 493 The algorithm identifier for AES-256 in CBC mode is: 495 id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 496 country(16) us(840) organization(1) gov(101) csor(3) 497 nistAlgorithm(4) aes(1) 42 } 499 The AlgorithmIdentifier parameters field MUST be present, and the 500 parameters field must contain AES-IV: 502 AES-IV ::= OCTET STRING (SIZE(16)) 504 The 16 octet initialization vector is generated at random by the 505 originator. See [RANDOM] for guidance on generation of random 506 values. 508 6. Security Considerations 510 This document specifies the conventions for using the NSA's Suite B 511 algorithms in S/MIME. All of the algorithms have been specified in 512 previous documents, although a few new algorithm identifiers have 513 been assigned. 515 Two levels of security may be achieved using this specification. 516 Users must consider their risk environment to determine which level 517 is appropriate for their own use. 519 For signed and encrypted messages, Suite B provides a consistent 520 level of security for confidentiality and integrity of the message 521 content. 523 The security considerations in RFC 3852 [CMS] discuss the CMS as a 524 method for digitally signing data and encrypting data. 526 The security considerations in RFC 3370 [CMSALG] discuss 527 cryptographic algorithm implementation concerns in the context of the 528 CMS. 530 The security considerations in RFC 3278 [CMSECC] discuss the use of 531 elliptic curve cryptography (ECC) in the CMS. 533 The security considerations in RFC 3565 [CMSAES] discuss the use of 534 AES in the CMS. 536 7. References 538 7.1. Normative References 540 [AES] National Institute of Standards and Technology, "Advanced 541 Encryption Standard (AES)", FIPS PUB 197, November 2001. 543 [AESWRAP] National Institute of Standards and Technology, "AES Key 544 Wrap Specification", 17 November 2001. [See 545 http://csrc.nist.gov/encryption/kms/key-wrap.pdf] 547 [DSS] National Institute of Standards and Technology, "Digital 548 Signature Standard (DSS)", FIPS PUB 186-2, January 2000. 550 [ECDSA] American National Standards Institute, "Public Key 551 Cryptography For The Financial Services Industry: The 552 Elliptic Curve Digital Signature Algorithm (ECDSA)", 553 ANSI X9.62-1998, 1999. 555 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 556 RFC 3852, July 2004. 558 [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard 559 (AES) Encryption Algorithm in Cryptographic Message 560 Syntax (CMS)", RFC 3565, July 2003. 562 [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) 563 Algorithms", RFC 3370, August 2002. 565 [CMSDH] Rescorla, E., "Diffie-Hellman Key Agreement Method", 566 RFC 2631, June 1999. 568 [CMSECC] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of 569 Elliptic Curve Cryptography (ECC) Algorithms in 570 Cryptographic Message Syntax (CMS)", RFC 3278, 571 April 2002. 573 [IEEE1363] Institute of Electrical and Electronics Engineers, 574 "Standard Specifications for Public Key Cryptography", 575 IEEE Std 1363, 2000. 577 [MODES] National Institute of Standards and Technology, "DES 578 Modes of Operation", FIPS Pub 81, 2 December 1980. 580 [MSG] Ramsdell, B., "Secure/Multipurpose Internet Mail 581 Extensions (S/MIME) Version 3.1 Message Specification", 582 RFC 3851, July 2004. 584 [PKIX1] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 585 X.509 Public Key Infrastructure Certificate and 586 Certificate Revocation List (CRL) Profile", RFC 3280, 587 April 2002. 589 [PKIX1ALG] Polk, W., Housley, R., and L. Bassham, "Algorithms and 590 Identifiers for the Internet X.509 Public Key 591 Infrastructure Certificate and Certificate Revocation 592 List (CRL) Profile", RFC 3279, April 2002. 594 [SEC1] Standards for Efficient Cryptography Group, "Elliptic 595 Curve Cryptography", 2000. [See http://www.secg.org/ 596 collateral/sec1.pdf.] 598 [SH] Schaad, J., and R. Housley, "Advanced Encryption Standard 599 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 601 [SHA2] National Institute of Standards and Technology, "Secure 602 Hash Standard", FIPS 180-2, 1 August 2002. 604 [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 [X.208-88] CCITT. Recommendation X.208: Specification of Abstract 608 Syntax Notation One (ASN.1). 1988. 610 [X.209-88] CCITT. Recommendation X.209: Specification of Basic 611 Encoding Rules for Abstract Syntax Notation One (ASN.1). 612 1988. 614 [X.509-88] CCITT. Recommendation X.509: The Directory - 615 Authentication Framework. 1988. 617 7.2. Informative References 619 [EH] Eastlake, D., and T. Hansen, "US Secure Hash Algorithms 620 (SHA and HMAC-SHA)", RFC 4634, July 2006. 622 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 623 Requirements for Security", RFC 4086, June 2005. 625 [SuiteB] National Security Agency, "Fact Sheet NSA Suite B 626 Cryptography", July 2005. [See http://www.nsa.gov/ia/ 627 industry/crypto_Suite_b.cfm?MenuID=10.2.7) 629 8. IANA Considerations 631 None. 633 {{{ RFC Editor: Please remove this section prior to publication. }}} 635 Authors' Addresses 637 Russell Housley 638 Vigil Security, LLC 639 918 Spring Knoll Drive 640 Herndon, VA 20170 641 USA 643 EMail: housley(at)vigilsec.com 645 Jerome A. Solinas 646 National Information Assurance Laboratory 647 National Security Agency 648 9800 Savage Road 649 Fort George G. Meade, MD 20755 650 USA 652 Email: jasolin(at)orion.ncsc.mil 654 Copyright and IPR Statements 656 Copyright (C) The IETF Trust (2007). 658 This document is subject to the rights, licenses and restrictions 659 contained in BCP 78, and except as set forth therein, the authors 660 retain all their rights. 662 This document and translations of it may be copied and furnished to 663 others, and derivative works that comment on or otherwise explain it 664 or assist in its implementation may be prepared, copied, published 665 and distributed, in whole or in part, without restriction of any 666 kind, provided that the above copyright notice and this paragraph are 667 included on all such copies and derivative works. However, this 668 document itself may not be modified in any way, such as by removing 669 the copyright notice or references to the Internet Society or other 670 Internet organizations, except as needed for the purpose of 671 developing Internet standards in which case the procedures for 672 copyrights defined in the Internet Standards process must be 673 followed, or as required to translate it into languages other than 674 English. 676 The limited permissions granted above are perpetual and will not be 677 revoked by the Internet Society or its successors or assigns. 679 This document and the information contained herein are provided on an 680 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 681 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 682 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 683 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 684 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 685 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 687 The IETF takes no position regarding the validity or scope of any 688 Intellectual Property Rights or other rights that might be claimed to 689 pertain to the implementation or use of the technology described in 690 this document or the extent to which any license under such rights 691 might or might not be available; nor does it represent that it has 692 made any independent effort to identify any such rights. Information 693 on the procedures with respect to rights in RFC documents can be 694 found in BCP 78 and BCP 79. 696 Copies of IPR disclosures made to the IETF Secretariat and any 697 assurances of licenses to be made available, or the result of an 698 attempt made to obtain a general license or permission for the use of 699 such proprietary rights by implementers or users of this 700 specification can be obtained from the IETF on-line IPR repository at 701 http://www.ietf.org/ipr. 703 The IETF invites any interested party to bring to its attention any 704 copyrights, patents or patent applications, or other proprietary 705 rights that may cover technology that may be required to implement 706 this standard. Please address the information to the IETF at 707 ietf-ipr@ietf.org.