idnits 2.17.1 draft-ietf-smime-sha2-06.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 410. 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 : ---------------------------------------------------------------------------- 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.) -- The document date (September 10, 2008) is 5699 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ECCADD' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' ** Obsolete normative reference: RFC 2313 (Obsoleted by RFC 2437) ** Obsolete normative reference: RFC 3278 (Obsoleted by RFC 5753) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) ** Downref: Normative reference to an Informational RFC: RFC 3874 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' -- Obsolete informational reference (is this intentional?): RFC 4634 (Obsoleted by RFC 6234) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 11 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 September 10, 2008 3 Intended Status: Standard Track 4 Expires: March 10, 2009 6 Using SHA2 Algorithms with Cryptographic Message Syntax 7 draft-ietf-smime-sha2-06.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on March 10, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 This document describes the conventions for using the Secure Hash 41 Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, 42 SHA-512) with the Cryptographic Message Syntax (CMS). It also 43 describes the conventions for using these algorithms with CMS and the 44 Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and 45 Elliptic Curve DSA (ECDSA) signature algorithms. 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in [RFC2119]. 53 Table of Contents 55 1. Introduction...................................................2 56 2. Message Digest Algorithms......................................3 57 2.1. SHA-224...................................................4 58 2.2. SHA-256...................................................4 59 2.3. SHA-384...................................................4 60 2.4. SHA-512...................................................4 61 3. Signature Algorithms...........................................5 62 3.1. DSA.......................................................5 63 3.2. RSA.......................................................6 64 3.3. ECDSA.....................................................6 65 4. Security Considerations........................................7 66 5. IANA Considerations............................................7 67 6. References.....................................................7 68 6.1. Normative References......................................7 69 6.2. Informative References....................................8 71 1. Introduction 73 This document specifies the algorithm identifiers and specifies 74 parameters for the message digest algorithms SHA-224, SHA-256, SHA- 75 384, and SHA-512 for use with the Cryptographic Message Syntax (CMS) 76 [RFC3852]. The message digest algorithms are defined in [SHS] and 77 reference code is provided in [RFC4634]. 79 This document also specifies the algorithm identifiers and parameters 80 for use of SHA-224, SHA-256, SHA-384, and SHA-512 with DSA [DSS], RSA 81 [RFC2313], and ECDSA [X9.62]. 83 This document does not define new identifiers; they are taken from 84 [RFC3874], [RFC4055], [ECCADD], and [RFC3278]. Additionally, the 85 parameters follow the conventions specified therein. Therefore, 86 there is no Abstract Syntax Notation One (ASN.1) module included in 87 this document. 89 Note that [RFC4231] specifies the conventions for the message 90 authentication code (MAC) algorithms: HMAC with SHA-224, HMAC with 91 SHA-256, HMAC with SHA-384, and HMAC with SHA-512. 93 In CMS, the various algorithm identifiers use the AlgorithmIdentifier 94 syntax, which is included here for convenience: 96 AlgorithmIdentifier ::= SEQUENCE { 97 algorithm OBJECT IDENTIFIER, 98 parameters ANY DEFINED BY algorithm OPTIONAL } 100 2. Message Digest Algorithms 102 Digest algorithm identifiers are located in the SignedData 103 digestAlgorithms field, the SignerInfo digestAlgorithm field, the 104 DigestedData digestAlgorithm field, and the AuthenticatedData 105 digestAlgorithm field. 107 Digest values are located in the DigestedData digest field and the 108 Message Digest authenticated attribute. In addition, digest values 109 are input to signature algorithms. 111 The digest algorithm identifiers use the AlgorithmIdentifier syntax 112 elaborated upon in Section 1. 114 The algorithm field is discussed in Sections 2.1-2.4 for each message 115 digest algorithm. 117 There are two possible encodings for the SHA AlgorithmIdentifier 118 parameters field. The two alternatives arise from the fact that when 119 the 1988 syntax for AlgorithmIdentifier was translated into the 1997 120 syntax, the OPTIONAL associated with the AlgorithmIdentifier 121 parameters got lost. Later the OPTIONAL was recovered via a defect 122 report, but by then many people thought that algorithm parameters 123 were mandatory. Because of this history some implementations encode 124 parameters as a NULL element and others omit them entirely. The 125 correct encoding is to omit the parameters field; however, 126 implementations MUST also handle a SHA AlgorithmIdentifier parameters 127 field which contains a NULL. 129 The AlgorithmIdentifier parameters field is OPTIONAL. If present, 130 the parameters field MUST contain a NULL. Implementations MUST 131 accept SHA2 AlgorithmIdentifiers with absent parameters. 132 Implementations MUST accept SHA2 AlgorithmIdentifiers with NULL 133 parameters. Implementations SHOULD generate SHA2 134 AlgorithmIdentifiers with absent parameters. 136 2.1. SHA-224 138 The SHA-224 message digest algorithm is defined in [SHS]. The 139 algorithm identifier for SHA-224 is: 141 id-sha224 OBJECT IDENTIFIER ::= { 142 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 143 csor(3) nistalgorithm(4) hashalgs(2) 4 } 145 The parameters are as specified in Section 2. 147 2.2. SHA-256 149 The SHA-256 message digest algorithm is defined in [SHS]. The 150 algorithm identifier for SHA-256 is: 152 id-sha256 OBJECT IDENTIFIER ::= { 153 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 154 csor(3) nistalgorithm(4) hashalgs(2) 1 } 156 The parameters are as specified in Section 2. 158 2.3. SHA-384 160 The SHA-384 message digest algorithm is defined in [SHS]. The 161 algorithm identifier for SHA-384 is: 163 id-sha384 OBJECT IDENTIFIER ::= { 164 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 165 csor(3) nistalgorithm(4) hashalgs(2) 2 } 167 The parameters are as specified in Section 2. 169 2.4. SHA-512 171 The SHA-512 message digest algorithm is defined in [SHS]. The 172 algorithm identifier for SHA-512 is: 174 id-sha512 OBJECT IDENTIFIER ::= { 175 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 176 csor(3) nistalgorithm(4) hashalgs(2) 3 } 178 The parameters are as specified in Section 2. 180 3. Signature Algorithms 182 This section specifies the conventions employed by CMS 183 implementations that support DSA, RSA, and ECDSA with SHA2 184 algorithms. 186 Signature algorithm identifiers are located in the SignerInfo 187 signatureAlgorithm field of SignedData. Also, signature algorithm 188 identifiers are located in the SignerInfo signatureAlgorithm field of 189 countersignature attributes. 191 Signature values are located in the SignerInfo signature field of 192 SignedData. Also, signature values are located in the SignerInfo 193 signature field of countersignature attributes. 195 3.1. DSA 197 [RFC3370] section 3.1 specifies the conventions for DSA with SHA1 198 public key algorithm identifiers, parameters, public keys, and 199 signature values. DSA with SHA2 algorithms uses the same conventions 200 for these public key algorithm identifiers, parameters, public keys, 201 and signature values. DSA MAY be used with SHA-224 and SHA-256. 203 DSA has not been specified with SHA-384 and SHA-512. SHA-384 and 204 SHA-512 are not supported because the maximum bit length of p 205 (specified as L) is 3072 for DSA. For consistent cryptographic 206 strength, SHA-384 would be used with DSA where L is 7068, and SHA-512 207 would be used with DSA where L is 15360. 209 The algorithm identifier for DSA with SHA-224 signature values is: 211 id-dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 212 country(16) us(840) organization(1) gov(101) csor(3) 213 algorithms(4) id-dsa-with-sha2(3) 1 } 215 The algorithm identifier for DSA with SHA-256 signature values is: 217 id-dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 218 country(16) us(840) organization(1) gov(101) csor(3) 219 algorithms(4) id-dsa-with-sha2(3) 2 } 221 When either of these algorithm identifiers is used, the 222 AlgorithmIdentifier parameters field MUST be absent. 224 3.2. RSA 226 [RFC3370] section 3.2 specifies the conventions for RSA with SHA-1 227 (PKCS #1 v1.5) public key algorithm identifiers, parameters, public 228 keys, and signature values. RSA with SHA2 algorithms uses the same 229 conventions for these public key algorithm identifiers, parameters, 230 public keys, and signature values. RSA (PKCS #1 v1.5) MAY be used 231 with SHA-224, SHA-256, SHA-384, or SHA-512. 233 The object identifier for RSA with SHA-224 signature values is: 235 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 236 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } 238 The object identifier for RSA with SHA-256 signature values is: 240 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 241 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } 243 The object identifier for RSA with SHA-384 signature values is: 245 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 246 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } 248 The object identifier for RSA with SHA-512 signature values is: 250 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 251 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } 253 When any of these four object identifiers appears within an 254 AlgorithmIdentifier, the parameters MUST be NULL. Implementations 255 MUST accept the parameters being absent as well as present. 257 3.3. ECDSA 259 [RFC3278] section 2.1 specifies the conventions for ECDSA with SHA1 260 public key algorithm identifiers, parameters, public keys, and 261 signature values. ECDSA with SHA2 algorithms uses the same 262 conventions for these public key algorithm identifiers, parameters, 263 public keys, and signature values, except that the digestAlgorithm 264 MUST include the corresponding message digest algorithm identifier, 265 and not the sha-1 object identifier. ECDSA MAY be used with SHA-224, 266 SHA-256, SHA-384, or SHA-512. 268 The algorithm identifier for ECDSA with SHA-224 signature values is: 270 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 271 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } 273 The algorithm identifier for ECDSA with SHA-256 signature values is: 275 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 276 us(840)ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 278 The algorithm identifier for ECDSA with SHA-384 signature values is: 280 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 281 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 283 The algorithm identifier for ECDSA with SHA-512 signature values is: 285 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 286 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 288 When any of these four object identifiers appears within an 289 AlgorithmIdentifier, the parameters MUST omit the parameters field. 290 That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one 291 component: the OID ecdsa-with-SHA224, ecdsa-with-SHA256, 292 ecdsa-with-SHA384 or ecdsa-with-SHA512. 294 4. Security Considerations 296 The security considerations in [RFC3278], [RFC3370], [RFC3874], 297 [RFC4055], and [ECCADD] apply. No new security considerations are 298 introduced as a result of this specification. 300 5. IANA Considerations 302 None: All identifiers are already registered. Please remove this 303 section prior to publication as an RFC. 305 6. References 307 6.1. Normative References 309 [ECCADD] Dang, S., Santesson, S., Moriarty, K., and Brown, 310 "Internet X.509 Public Key Infrastructure: Additional 311 Algorithms and Identifiers for DSA and ECDSA", work-in- 312 progress. 314 [DSS] National Institute of Standards and Technology (NIST), 315 FIPS Publication 186-2: Digital Signature Standard, 316 January 2000. 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119. March 1997. 321 [RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 322 2313, March 1998. 324 [RFC3278] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of 325 Elliptic Curve Cryptography (ECC) Algorithms in 326 Cryptographic Message Syntax (CMS)", RFC 3278, April 327 2002. 329 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 330 Algorithms", RFC 3370, August 2002. 332 [RFC3852] Housley, R., "The Cryptographic Message Syntax (CMS)", 333 RFC 3852. July 2004. 335 [RFC3874] Housley, R., "A 224-bit One Way Hash Function: SHA-224", 336 RFC 3874. September 2004. 338 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 339 Algorithms and Identifiers for RSA Cryptography for use 340 in the Internet Public Key Infrastructure Certificate and 341 Certificate Revocation List (CRL) Profile", RFC 4055. 342 June 2005. 344 [SHS] National Institute of Standards and Technology (NIST), 345 FIPS Publication 180-2: Secure Hash Standard, August 346 2002. 348 [X9.62] X9.62-2005, "Public Key Cryptography for the Financial 349 Services Industry: The Elliptic Curve Digital Signature 350 Standard (ECDSA)", November, 2005. 352 6.2. Informative References 354 [RFC4231] Nystrom, A. "Identifiers and Test Vectors for HMAC-SHA- 355 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 356 RFC4231. December 2005. 358 [RFC4634] Eastlake, D., and T. Hansen, "US Secure Hash Algorithms 359 (SHA and HMAC-SHA)", RFC 4634, July 2006. 361 Author's Addresses 363 Sean Turner 365 IECA, Inc. 366 3057 Nutley Street, Suite 106 367 Fairfax, VA 22031 368 USA 370 EMail: turners@ieca.com 372 Full Copyright Statement 374 Copyright (C) The IETF Trust (2008). 376 This document is subject to the rights, licenses and restrictions 377 contained in BCP 78, and except as set forth therein, the authors 378 retain all their rights. 380 This document and the information contained herein are provided on an 381 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 382 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 383 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 384 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 385 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 386 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 388 Intellectual Property 390 The IETF takes no position regarding the validity or scope of any 391 Intellectual Property Rights or other rights that might be claimed to 392 pertain to the implementation or use of the technology described in 393 this document or the extent to which any license under such rights 394 might or might not be available; nor does it represent that it has 395 made any independent effort to identify any such rights. Information 396 on the procedures with respect to rights in RFC documents can be 397 found in BCP 78 and BCP 79. 399 Copies of IPR disclosures made to the IETF Secretariat and any 400 assurances of licenses to be made available, or the result of an 401 attempt made to obtain a general license or permission for the use of 402 such proprietary rights by implementers or users of this 403 specification can be obtained from the IETF on-line IPR repository at 404 http://www.ietf.org/ipr. 406 The IETF invites any interested party to bring to its attention any 407 copyrights, patents or patent applications, or other proprietary 408 rights that may cover technology that may be required to implement 409 this standard. Please address the information to the IETF at 410 ietf-ipr@ietf.org. 412 Acknowledgment 414 Funding for the RFC Editor function is provided by the IETF 415 Administrative Support Activity (IASA).