idnits 2.17.1 draft-ietf-smime-sha2-05.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 383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 401. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 407. 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 (April 29, 2008) is 5838 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 April 29, 2008 3 Intended Status: Standard Track 4 Expires: October 29, 2008 6 Using SHA2 Algorithms with Cryptographic Message Syntax 7 draft-ietf-smime-sha2-05.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 October 29, 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 be NULL. 291 4. Security Considerations 293 The security considerations in [RFC3278], [RFC3370], [RFC3874], 294 [RFC4055], and [ECCADD] apply. No new security considerations are 295 introduced as a result of this specification. 297 5. IANA Considerations 299 None: All identifiers are already registered. Please remove this 300 section prior to publication as an RFC. 302 6. References 304 6.1. Normative References 306 [ECCADD] Dang, S., Santesson, S., Moriarty, K., and Brown, 307 "Internet X.509 Public Key Infrastructure: Additional 308 Algorithms and Identifiers for DSA and ECDSA", work-in- 309 progress. 311 [DSS] Federal Information Processing Standards Publication 312 (FIPS PUB) 186-2, Digital Signature Standard, January 313 2000. 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119. March 1997. 318 [RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 319 2313, March 1998. 321 [RFC3278] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of 322 Elliptic Curve Cryptography (ECC) Algorithms in 323 Cryptographic Message Syntax (CMS)", RFC 3278, April 324 2002. 326 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 327 Algorithms", RFC 3370, August 2002. 329 [RFC3852] Housley, R., "The Cryptographic Message Syntax (CMS)", 330 RFC 3852. July 2004. 332 [RFC3874] Housley, R., "A 224-bit One Way Hash Function: SHA-224", 333 RFC 3874. September 2004. 335 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 336 Algorithms and Identifiers for RSA Cryptography for use 337 in the Internet Public Key Infrastructure Certificate and 338 Certificate Revocation List (CRL) Profile", RFC 4055. 339 June 2005. 341 [SHS] National Institute of Standards and Technology (NIST), 342 FIPS Publication 180-2: Secure Hash Standard, August 343 2002. 345 [X9.62] X9.62-2005, "Public Key Cryptography for the Financial 346 Services Industry: The Elliptic Curve Digital Signature 347 Standard (ECDSA)", November, 2005. 349 6.2. Informative References 351 [RFC4231] Nystrom, A. "Identifiers and Test Vectors for HMAC-SHA- 352 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 353 RFC4231. December 2005. 355 [RFC4634] Eastlake, D., and T. Hansen, "US Secure Hash Algorithms 356 (SHA and HMAC-SHA)", RFC 4634, July 2006. 358 Author's Addresses 360 Sean Turner 362 IECA, Inc. 363 3057 Nutley Street, Suite 106 364 Fairfax, VA 22031 365 USA 367 EMail: turners@ieca.com 369 Full Copyright Statement 371 Copyright (C) The IETF Trust (2008). 373 This document is subject to the rights, licenses and restrictions 374 contained in BCP 78, and except as set forth therein, the authors 375 retain all their rights. 377 This document and the information contained herein are provided on an 378 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 379 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 380 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 381 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 382 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 383 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 385 Intellectual Property 387 The IETF takes no position regarding the validity or scope of any 388 Intellectual Property Rights or other rights that might be claimed to 389 pertain to the implementation or use of the technology described in 390 this document or the extent to which any license under such rights 391 might or might not be available; nor does it represent that it has 392 made any independent effort to identify any such rights. Information 393 on the procedures with respect to rights in RFC documents can be 394 found in BCP 78 and BCP 79. 396 Copies of IPR disclosures made to the IETF Secretariat and any 397 assurances of licenses to be made available, or the result of an 398 attempt made to obtain a general license or permission for the use of 399 such proprietary rights by implementers or users of this 400 specification can be obtained from the IETF on-line IPR repository at 401 http://www.ietf.org/ipr. 403 The IETF invites any interested party to bring to its attention any 404 copyrights, patents or patent applications, or other proprietary 405 rights that may cover technology that may be required to implement 406 this standard. Please address the information to the IETF at 407 ietf-ipr@ietf.org. 409 Acknowledgment 411 Funding for the RFC Editor function is provided by the IETF 412 Administrative Support Activity (IASA).