idnits 2.17.1 draft-ietf-smime-sha2-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3370, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3370, updated by this document, for RFC5378 checks: 2001-04-25) -- 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.) -- The document date (December 20, 2008) is 5577 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-pkix-sha2-dsa-ecdsa-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) ** Downref: Normative reference to an Informational RFC: RFC 3874 == Outdated reference: A later version (-11) exists of draft-ietf-smime-3851bis-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' -- Obsolete informational reference (is this intentional?): RFC 3278 (Obsoleted by RFC 5753) -- Obsolete informational reference (is this intentional?): RFC 4634 (Obsoleted by RFC 6234) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME WG Sean Turner, IECA 2 Internet Draft December 20, 2008 3 Intended Status: Standard Track 4 Updates: 3370 (once approved) 5 Expires: June 20, 2009 7 Using SHA2 Algorithms with Cryptographic Message Syntax 8 draft-ietf-smime-sha2-10.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on June 20, 2008. 33 Copyright Notice 35 Copyright (c) 2008 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This document describes the conventions for using the Secure Hash 48 Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, 49 SHA-512) with the Cryptographic Message Syntax (CMS). It also 50 describes the conventions for using these algorithms with CMS and the 51 Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and 52 Elliptic Curve DSA (ECDSA) signature algorithms. Further, it 53 provides SMIMECapabilities attribute values for each algorithm. 55 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in [RFC2119]. 61 Table of Contents 63 1. Introduction...................................................2 64 2. Message Digest Algorithms......................................3 65 2.1. SHA-224...................................................4 66 2.2. SHA-256...................................................5 67 2.3. SHA-384...................................................5 68 2.4. SHA-512...................................................5 69 3. Signature Algorithms...........................................6 70 3.1. DSA.......................................................6 71 3.2. RSA.......................................................7 72 3.3. ECDSA.....................................................8 73 4. Security Considerations........................................9 74 5. IANA Considerations............................................9 75 6. References....................................................10 76 6.1. Normative References.....................................10 77 6.2. Informative References...................................11 79 1. Introduction 81 This document specifies the algorithm identifiers and specifies 82 parameters for the message digest algorithms SHA-224, SHA-256, SHA- 83 384, and SHA-512 for use with the Cryptographic Message Syntax (CMS) 84 [RFC3852]. The message digest algorithms are defined in [SHS] and 85 reference code is provided in [RFC4634]. 87 This document also specifies the algorithm identifiers and parameters 88 for use of SHA-224, SHA-256, SHA-384, and SHA-512 with DSA [DSS], RSA 89 (RSASSA-PKCS1-v1_5) [RFC3447], and ECDSA [DSS]. 91 This document does not define new identifiers; they are taken from 92 [RFC3874], [RFC4055], and [ECCADD]. Additionally, the parameters 93 follow the conventions specified therein. Therefore, there is no 94 Abstract Syntax Notation One (ASN.1) module included in this 95 document. 97 Note that [RFC4231] specifies the conventions for the message 98 authentication code (MAC) algorithms: HMAC with SHA-224, HMAC with 99 SHA-256, HMAC with SHA-384, and HMAC with SHA-512. 101 In CMS, the various algorithm identifiers use the AlgorithmIdentifier 102 syntax, which is included here for convenience: 104 AlgorithmIdentifier ::= SEQUENCE { 105 algorithm OBJECT IDENTIFIER, 106 parameters ANY DEFINED BY algorithm OPTIONAL } 108 This document also specifies the SMIMECapabilities attribute values 109 [RFCTBD] for each algorithm. The values provided are for the 110 SMIMECapability field, which is included here for convenience: 112 SMIMECapability ::= SEQUENCE { 113 capabilityID OBJECT IDENTIFIER, 114 parameters ANY DEFINED BY capabilityID OPTIONAL } 116 2. Message Digest Algorithms 118 Digest algorithm identifiers are located in the SignedData 119 digestAlgorithms field, the SignerInfo digestAlgorithm field, the 120 DigestedData digestAlgorithm field, and the AuthenticatedData 121 digestAlgorithm field. The object identifiers are taken from 122 [RFC4055]. 124 Digest values are located in the DigestedData digest field and the 125 Message Digest authenticated attribute. In addition, digest values 126 are input to signature algorithms. 128 The digest algorithm identifiers use the AlgorithmIdentifier syntax 129 elaborated upon in Section 1. 131 The algorithm field and SMIMECapabilities attribute are discussed in 132 Sections 2.1-2.4 for each message digest algorithm. Section 3 133 provides some signatures that use SHA2 algorithms. Consult the 134 signature algorithm definitions for the procedures to compute the 135 digest values (i.e., DigestInfo). 137 The AlgorithmIdentifier parameters field is OPTIONAL. 138 Implementations MUST accept SHA2 AlgorithmIdentifiers with absent 139 parameters. Implementations MUST accept SHA2 AlgorithmIdentifiers 140 with NULL parameters. Implementations MUST generate SHA2 141 AlgorithmIdentifiers with absent parameters. 143 NOTE: There are two possible encodings for the AlgorithmIdentifier 144 parameters field associated with these object identifiers. The two 145 alternatives arise from the loss of the OPTIONAL associated with the 146 algorithm identifier parameters when the 1988 syntax for 147 AlgorithmIdentifier was translated into the 1997 syntax. Later the 148 OPTIONAL was recovered via a defect report, but by then many people 149 thought that algorithm parameters were mandatory. Because of this 150 history some implementations encode parameters as a NULL element 151 while others omit them entirely. The correct encoding is to omit the 152 parameters field; however, when some uses of these algorithms were 153 defined, it was done using the NULL parameters rather than absent 154 parameters. For example, PKCS#1 [RFC3447] requires that the padding 155 used for RSA signatures (EMSA-PKCS1-v1_5) MUST use SHA2 156 AlgorithmIdentifiers with NULL parameters (to clarify, the 157 requirement "MUST generate SHA2 AlgorithmIdentifiers with absent 158 parameters" in the previous paragraph does not apply to this 159 padding). 161 2.1. SHA-224 163 The SHA-224 message digest algorithm is defined in [SHS]. The 164 algorithm identifier for SHA-224 is: 166 id-sha224 OBJECT IDENTIFIER ::= { 167 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 168 csor(3) nistalgorithm(4) hashalgs(2) 4 } 170 The parameters are as specified in Section 2. 172 The SMIMECapabilities attribute value indicates support for SHA-224 173 in a SEQUENCE with the capabilityID field containing the object 174 identifier id-sha224 with absent parameters. The DER encoding for 175 this SMIMECapability is: 177 id-sha224: 30 0b 06 09 60 86 48 01 65 03 04 02 04 179 2.2. SHA-256 181 The SHA-256 message digest algorithm is defined in [SHS]. The 182 algorithm identifier for SHA-256 is: 184 id-sha256 OBJECT IDENTIFIER ::= { 185 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 186 csor(3) nistalgorithm(4) hashalgs(2) 1 } 188 The parameters are as specified in Section 2. 190 The SMIMECapabilities attribute value indicates support for SHA-256 191 in a SEQUENCE with the capabilityID field containing the object 192 identifier id-sha256 with absent parameters. The DER encoding for 193 this SMIMECapability value is: 195 id-sha256: 30 0b 06 09 60 86 48 01 65 03 04 02 01 197 2.3. SHA-384 199 The SHA-384 message digest algorithm is defined in [SHS]. The 200 algorithm identifier for SHA-384 is: 202 id-sha384 OBJECT IDENTIFIER ::= { 203 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 204 csor(3) nistalgorithm(4) hashalgs(2) 2 } 206 The parameters are as specified in Section 2. 208 The SMIMECapabilities attribute value indicates support for SHA-384 209 in a SEQUENCE with the capabilityID field containing the object 210 identifier id-sha384 with absent parameters. The DER encoding for 211 this SMIMECapability value is: 213 id-sha384: 30 0b 06 09 60 86 48 01 65 03 04 02 02 215 2.4. SHA-512 217 The SHA-512 message digest algorithm is defined in [SHS]. The 218 algorithm identifier for SHA-512 is: 220 id-sha512 OBJECT IDENTIFIER ::= { 221 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 222 csor(3) nistalgorithm(4) hashalgs(2) 3 } 224 The parameters are as specified in Section 2. 226 The SMIMECapabilities attribute value indicates support for SHA-384 227 in a SEQUENCE with the capabilityID field containing the object 228 identifier id-sha384 with absent parameters. The DER encoding for 229 this SMIMECapability value is: 231 id-sha512: 30 0b 06 09 60 86 48 01 65 03 04 02 03 233 3. Signature Algorithms 235 This section specifies the conventions employed by CMS 236 implementations that support DSA, RSA, and ECDSA with SHA2 237 algorithms. 239 Signature algorithm identifiers are located in the SignerInfo 240 signatureAlgorithm field of SignedData. Also, signature algorithm 241 identifiers are located in the SignerInfo signatureAlgorithm field of 242 countersignature attributes. 244 Signature values are located in the SignerInfo signature field of 245 SignedData. Also, signature values are located in the SignerInfo 246 signature field of countersignature attributes. 248 3.1. DSA 250 [RFC3370] section 3.1 specifies the conventions for DSA with SHA-1 251 public key algorithm identifiers, parameters, public keys, and 252 signature values. DSA with SHA2 algorithms uses the same conventions 253 for these public key algorithm identifiers, parameters, public keys, 254 and signature values. DSA MAY be used with SHA-224 and SHA-256. The 255 object identifiers are taken from [ECCADD]. 257 DSA has not been specified with SHA-384 and SHA-512. SHA-384 and 258 SHA-512 are not supported because the maximum bit length of p 259 (specified as L) is 3072 for DSA. For consistent cryptographic 260 strength, SHA-384 would be used with DSA where L is 7680, and SHA-512 261 would be used with DSA where L is 15360. 263 The algorithm identifier for DSA with SHA-224 signature values is: 265 id-dsa-with-sha224 OBJECT IDENTIFIER ::= { 266 joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) 267 csor(3) algorithms(4) id-dsa-with-sha2(3) 1 } 269 The algorithm identifier for DSA with SHA-256 signature values is: 271 id-dsa-with-sha256 OBJECT IDENTIFIER ::= { 272 joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) 273 csor(3) algorithms(4) id-dsa-with-sha2(3) 2 } 275 When either of these algorithm identifiers is used, the 276 AlgorithmIdentifier parameters field MUST be absent. 278 The SMIMECapabilities attribute value indicates support for one of 279 the DSA signature algorithms in a SEQUENCE with the capabilityID 280 field containing the object identifier id-dsa-with-sha* (where * is 281 224 or 256) with absent parameters. The DER encoding for these 282 SMIMECapability values are: 284 id-dsa-with-sha224: 30 0b 06 09 60 86 48 01 65 03 04 03 01 286 id-dsa-with-sha256: 30 0b 06 09 60 86 48 01 65 03 04 03 02 288 3.2. RSA 290 [RFC3370] section 3.2 specifies the conventions for RSA with SHA-1 291 (RSASSA-PKCS1-v1_5) public key algorithm identifiers, parameters, 292 public keys, and signature values. RSA with SHA2 algorithms uses the 293 same conventions for these public key algorithm identifiers, 294 parameters, public keys, and signature values. RSA (RSASSA-PKCS1- 295 v1_5) [RFC3447] MAY be used with SHA-224, SHA-256, SHA-384, or SHA- 296 512. The object identifiers are taken from [RFC4055]. 298 The object identifier for RSA with SHA-224 signature values is: 300 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 301 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } 303 The object identifier for RSA with SHA-256 signature values is: 305 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 306 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } 308 The object identifier for RSA with SHA-384 signature values is: 310 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 311 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } 313 The object identifier for RSA with SHA-512 signature values is: 315 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 316 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } 318 When any of these four object identifiers appears within an 319 AlgorithmIdentifier, the parameters MUST be NULL. Implementations 320 MUST accept the parameters being absent as well as present. 322 The SMIMECapabilities attribute value indicates support for one of 323 the DSA signature algorithms in a SEQUENCE with the capabilityID 324 field containing the object identifier sha*WithRSAEncryption (where * 325 is 224, 256, 384, or 512) with NULL parameters. The DER encoding for 326 these SMIMECapability values are: 328 sha224WithRSAEncryption: 30 0d 06 08 2a 86 48 86 f7 0d 01 01 14 329 05 00 331 sha256WithRSAEncryption: 30 0d 06 08 2a 86 48 86 f7 0d 01 01 11 332 05 00 334 sha384WithRSAEncryption: 30 0d 06 08 2a 86 48 86 f7 0d 01 01 12 335 05 00 337 sha512WithRSAEncryption: 30 0d 06 08 2a 86 48 86 f7 0d 01 01 13 338 05 00 340 3.3. ECDSA 342 [RFC3278] section 2.1 specifies the conventions for ECDSA with SHA-1 343 public key algorithm identifiers, parameters, public keys, and 344 signature values. ECDSA with SHA2 algorithms uses the same 345 conventions for these public key algorithm identifiers, parameters, 346 public keys, and signature values, except that the digestAlgorithm 347 MUST include the corresponding message digest algorithm identifier, 348 and not the sha-1 object identifier. ECDSA MAY be used with SHA-224, 349 SHA-256, SHA-384, or SHA-512. The object identifiers are taken from 350 [ECCADD]. 352 The algorithm identifier for ECDSA with SHA-224 signature values is: 354 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 355 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } 357 The algorithm identifier for ECDSA with SHA-256 signature values is: 359 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 360 us(840)ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 362 The algorithm identifier for ECDSA with SHA-384 signature values is: 364 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 365 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 367 The algorithm identifier for ECDSA with SHA-512 signature values is: 369 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 370 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 372 When any of these four object identifiers appears within an 373 AlgorithmIdentifier, the parameters filed MUST be absent. That is, 374 the AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OID 375 ecdsa-with-SHA224, ecdsa-with-SHA256, 376 ecdsa-with-SHA384 or ecdsa-with-SHA512. 378 The SMIMECapabilities attribute value indicates support for one of 379 the ECDSA signature algorithms in a SEQUENCE with the capabilityID 380 field containing the object identifier ecdsa-with-SHA1* (where * is 381 224, 256, 384, or 512) with absent parameters. The DER encoding for 382 these SMIMECapability values are: 384 ecdsa-with-SHA224: 30 0a 06 08 2a 86 48 ce 3d 04 03 01 386 ecdsa-with-SHA256: 30 0a 06 08 2a 86 48 ce 3d 04 03 02 388 ecdsa-with-SHA384: 30 0a 06 08 2a 86 48 ce 3d 04 03 03 390 ecdsa-with-SHA512: 30 0a 06 08 2a 86 48 ce 3d 04 03 04 392 4. Security Considerations 394 The security considerations in [RFC3370], [RFC3874], [RFC4055], and 395 [ECCADD] apply. No new security considerations are introduced as a 396 result of this specification. 398 5. IANA Considerations 400 None: All identifiers are already registered. Please remove this 401 section prior to publication as an RFC. 403 6. References 405 6.1. Normative References 407 [ECCADD] Dang, S., Santesson, S., Moriarty, K., and Brown, 408 "Internet X.509 Public Key Infrastructure: Additional 409 Algorithms and Identifiers for DSA and ECDSA", draft- 410 ietf-pkix-sha2-dsa-ecdsa-05.txt (work-in-progress). 412 [DSS] National Institute of Standards and Technology (NIST), 413 FIPS Publication 186-3: Digital Signature Standard, 414 (draft) November 2008. 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119. March 1997. 419 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 420 Algorithms", RFC 3370, August 2002. 422 [RFC3447] Kaliski, B. and J. Jonsson "Public-Key Cryptography 423 Standards (PKCS) #1: RSA Cryptography Specifications 424 Version 2.1", RFC 3447, February 2003. 426 [RFC3852] Housley, R., "The Cryptographic Message Syntax (CMS)", 427 RFC 3852. July 2004. 429 [RFC3874] Housley, R., "A 224-bit One Way Hash Function: SHA-224", 430 RFC 3874. September 2004. 432 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 433 Algorithms and Identifiers for RSA Cryptography for use 434 in the Internet Public Key Infrastructure Certificate and 435 Certificate Revocation List (CRL) Profile", RFC 4055. 436 June 2005. 438 [RFCTBD] Ramsdell, B., and S. Turner, "S/MIME Version 3.2 Message 439 Specification", draft-ietf-smime-3851bis-08.txt, work-in- 440 progress. 442 //* RFC EDITOR: Note replace the above TBD with the RFC # for draft- 443 ietf-smime-3851bis-08.txt. *// 445 [SHS] National Institute of Standards and Technology (NIST), 446 FIPS Publication 180-3: Secure Hash Standard, October 447 2008. 449 6.2. Informative References 451 [RFC3278] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of 452 Elliptic Curve Cryptography (ECC) Algorithms in 453 Cryptographic Message Syntax (CMS)", RFC 3278, April 454 2002. 456 [RFC4231] Nystrom, A. "Identifiers and Test Vectors for HMAC-SHA- 457 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 458 RFC4231. December 2005. 460 [RFC4634] Eastlake, D., and T. Hansen, "US Secure Hash Algorithms 461 (SHA and HMAC-SHA)", RFC 4634, July 2006. 463 Author's Addresses 465 Sean Turner 467 IECA, Inc. 468 3057 Nutley Street, Suite 106 469 Fairfax, VA 22031 470 USA 472 EMail: turners@ieca.com