idnits 2.17.1 draft-ietf-smime-sha2-09.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 373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 397. 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 (October 6, 2008) is 5678 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) == Outdated reference: A later version (-10) exists of draft-ietf-pkix-sha2-dsa-ecdsa-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' ** Obsolete normative reference: RFC 2313 (Obsoleted by RFC 2437) ** 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 3278 (Obsoleted by RFC 5753) -- Obsolete informational reference (is this intentional?): RFC 4634 (Obsoleted by RFC 6234) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 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 October 6, 2008 3 Intended Status: Standard Track 4 Expires: April 6, 2009 6 Using SHA2 Algorithms with Cryptographic Message Syntax 7 draft-ietf-smime-sha2-09.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 April 6, 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...................................................3 58 2.2. SHA-256...................................................4 59 2.3. SHA-384...................................................4 60 2.4. SHA-512...................................................4 61 3. Signature Algorithms...........................................4 62 3.1. DSA.......................................................5 63 3.2. RSA.......................................................5 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 [DSS]. 83 This document does not define new identifiers; they are taken from 84 [RFC3874], [RFC4055], and [ECCADD]. Additionally, the parameters 85 follow the conventions specified therein. Therefore, there is no 86 Abstract Syntax Notation One (ASN.1) module included in this 87 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. The object identifiers are taken from 106 [RFC4055]. 108 Digest values are located in the DigestedData digest field and the 109 Message Digest authenticated attribute. In addition, digest values 110 are input to signature algorithms. 112 The digest algorithm identifiers use the AlgorithmIdentifier syntax 113 elaborated upon in Section 1. 115 The algorithm field is discussed in Sections 2.1-2.4 for each message 116 digest algorithm. 118 The AlgorithmIdentifier parameters field is OPTIONAL. Implementations 119 MUST accept SHA2 AlgorithmIdentifiers with absent parameters. 120 Implementations MUST accept SHA2 AlgorithmIdentifiers with NULL 121 parameters. Implementations MUST generate SHA2 AlgorithmIdentifiers 122 with absent parameters. 124 2.1. SHA-224 126 The SHA-224 message digest algorithm is defined in [SHS]. The 127 algorithm identifier for SHA-224 is: 129 id-sha224 OBJECT IDENTIFIER ::= { 130 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 131 csor(3) nistalgorithm(4) hashalgs(2) 4 } 133 The parameters are as specified in Section 2. 135 2.2. SHA-256 137 The SHA-256 message digest algorithm is defined in [SHS]. The 138 algorithm identifier for SHA-256 is: 140 id-sha256 OBJECT IDENTIFIER ::= { 141 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 142 csor(3) nistalgorithm(4) hashalgs(2) 1 } 144 The parameters are as specified in Section 2. 146 2.3. SHA-384 148 The SHA-384 message digest algorithm is defined in [SHS]. The 149 algorithm identifier for SHA-384 is: 151 id-sha384 OBJECT IDENTIFIER ::= { 152 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 153 csor(3) nistalgorithm(4) hashalgs(2) 2 } 155 The parameters are as specified in Section 2. 157 2.4. SHA-512 159 The SHA-512 message digest algorithm is defined in [SHS]. The 160 algorithm identifier for SHA-512 is: 162 id-sha512 OBJECT IDENTIFIER ::= { 163 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 164 csor(3) nistalgorithm(4) hashalgs(2) 3 } 166 The parameters are as specified in Section 2. 168 3. Signature Algorithms 170 This section specifies the conventions employed by CMS 171 implementations that support DSA, RSA, and ECDSA with SHA2 172 algorithms. 174 Signature algorithm identifiers are located in the SignerInfo 175 signatureAlgorithm field of SignedData. Also, signature algorithm 176 identifiers are located in the SignerInfo signatureAlgorithm field of 177 countersignature attributes. 179 Signature values are located in the SignerInfo signature field of 180 SignedData. Also, signature values are located in the SignerInfo 181 signature field of countersignature attributes. 183 3.1. DSA 185 [RFC3370] section 3.1 specifies the conventions for DSA with SHA-1 186 public key algorithm identifiers, parameters, public keys, and 187 signature values. DSA with SHA2 algorithms uses the same conventions 188 for these public key algorithm identifiers, parameters, public keys, 189 and signature values. DSA MAY be used with SHA-224 and SHA-256. The 190 object identifiers are taken from [ECCADD]. 192 DSA has not been specified with SHA-384 and SHA-512. SHA-384 and 193 SHA-512 are not supported because the maximum bit length of p 194 (specified as L) is 3072 for DSA. For consistent cryptographic 195 strength, SHA-384 would be used with DSA where L is 7680, and SHA-512 196 would be used with DSA where L is 15360. 198 The algorithm identifier for DSA with SHA-224 signature values is: 200 id-dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 201 country(16) us(840) organization(1) gov(101) csor(3) 202 algorithms(4) id-dsa-with-sha2(3) 1 } 204 The algorithm identifier for DSA with SHA-256 signature values is: 206 id-dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 207 country(16) us(840) organization(1) gov(101) csor(3) 208 algorithms(4) id-dsa-with-sha2(3) 2 } 210 When either of these algorithm identifiers is used, the 211 AlgorithmIdentifier parameters field MUST be absent. 213 3.2. RSA 215 [RFC3370] section 3.2 specifies the conventions for RSA with SHA-1 216 (PKCS #1 v1.5) public key algorithm identifiers, parameters, public 217 keys, and signature values. RSA with SHA2 algorithms uses the same 218 conventions for these public key algorithm identifiers, parameters, 219 public keys, and signature values. RSA (PKCS #1 v1.5) MAY be used 220 with SHA-224, SHA-256, SHA-384, or SHA-512. The object identifiers 221 are taken from [RFC4055]. 223 The object identifier for RSA with SHA-224 signature values is: 225 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 226 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } 228 The object identifier for RSA with SHA-256 signature values is: 230 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 231 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } 233 The object identifier for RSA with SHA-384 signature values is: 235 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 236 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } 238 The object identifier for RSA with SHA-512 signature values is: 240 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 241 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } 243 When any of these four object identifiers appears within an 244 AlgorithmIdentifier, the parameters MUST be NULL. Implementations 245 MUST accept the parameters being absent as well as present. 247 3.3. ECDSA 249 [RFC3278] section 2.1 specifies the conventions for ECDSA with SHA-1 250 public key algorithm identifiers, parameters, public keys, and 251 signature values. ECDSA with SHA2 algorithms uses the same 252 conventions for these public key algorithm identifiers, parameters, 253 public keys, and signature values, except that the digestAlgorithm 254 MUST include the corresponding message digest algorithm identifier, 255 and not the sha-1 object identifier. ECDSA MAY be used with SHA-224, 256 SHA-256, SHA-384, or SHA-512. The object identifiers are taken from 257 [ECCADD]. 259 The algorithm identifier for ECDSA with SHA-224 signature values is: 261 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 262 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } 264 The algorithm identifier for ECDSA with SHA-256 signature values is: 266 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 267 us(840)ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 269 The algorithm identifier for ECDSA with SHA-384 signature values is: 271 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 272 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 274 The algorithm identifier for ECDSA with SHA-512 signature values is: 276 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 277 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 279 When any of these four object identifiers appears within an 280 AlgorithmIdentifier, the parameters filed MUST be absent. That is, 281 the AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OID 282 ecdsa-with-SHA224, ecdsa-with-SHA256, 283 ecdsa-with-SHA384 or ecdsa-with-SHA512. 285 4. Security Considerations 287 The security considerations in [RFC3370], [RFC3874], [RFC4055], and 288 [ECCADD] apply. No new security considerations are introduced as a 289 result of this specification. 291 5. IANA Considerations 293 None: All identifiers are already registered. Please remove this 294 section prior to publication as an RFC. 296 6. References 298 6.1. Normative References 300 [ECCADD] Dang, S., Santesson, S., Moriarty, K., and Brown, 301 "Internet X.509 Public Key Infrastructure: Additional 302 Algorithms and Identifiers for DSA and ECDSA", draft- 303 ietf-pkix-sha2-dsa-ecdsa-04.txt (work-in-progress). 305 [DSS] National Institute of Standards and Technology (NIST), 306 FIPS Publication 186-3: Digital Signature Standard, 307 (draft) March 2006. 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119. March 1997. 312 [RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 313 2313, March 1998. 315 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 316 Algorithms", RFC 3370, August 2002. 318 [RFC3852] Housley, R., "The Cryptographic Message Syntax (CMS)", 319 RFC 3852. July 2004. 321 [RFC3874] Housley, R., "A 224-bit One Way Hash Function: SHA-224", 322 RFC 3874. September 2004. 324 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 325 Algorithms and Identifiers for RSA Cryptography for use 326 in the Internet Public Key Infrastructure Certificate and 327 Certificate Revocation List (CRL) Profile", RFC 4055. 328 June 2005. 330 [SHS] National Institute of Standards and Technology (NIST), 331 FIPS Publication 180-3: Secure Hash Standard, (draft) 332 June 2003. 334 6.2. Informative References 336 [RFC3278] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of 337 Elliptic Curve Cryptography (ECC) Algorithms in 338 Cryptographic Message Syntax (CMS)", RFC 3278, April 339 2002. 341 [RFC4231] Nystrom, A. "Identifiers and Test Vectors for HMAC-SHA- 342 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 343 RFC4231. December 2005. 345 [RFC4634] Eastlake, D., and T. Hansen, "US Secure Hash Algorithms 346 (SHA and HMAC-SHA)", RFC 4634, July 2006. 348 Author's Addresses 350 Sean Turner 352 IECA, Inc. 353 3057 Nutley Street, Suite 106 354 Fairfax, VA 22031 355 USA 357 EMail: turners@ieca.com 359 Full Copyright Statement 361 Copyright (C) The IETF Trust (2008). 363 This document is subject to the rights, licenses and restrictions 364 contained in BCP 78, and except as set forth therein, the authors 365 retain all their rights. 367 This document and the information contained herein are provided on an 368 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 369 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 370 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 371 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 372 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 373 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 375 Intellectual Property 377 The IETF takes no position regarding the validity or scope of any 378 Intellectual Property Rights or other rights that might be claimed to 379 pertain to the implementation or use of the technology described in 380 this document or the extent to which any license under such rights 381 might or might not be available; nor does it represent that it has 382 made any independent effort to identify any such rights. Information 383 on the procedures with respect to rights in RFC documents can be 384 found in BCP 78 and BCP 79. 386 Copies of IPR disclosures made to the IETF Secretariat and any 387 assurances of licenses to be made available, or the result of an 388 attempt made to obtain a general license or permission for the use of 389 such proprietary rights by implementers or users of this 390 specification can be obtained from the IETF on-line IPR repository at 391 http://www.ietf.org/ipr. 393 The IETF invites any interested party to bring to its attention any 394 copyrights, patents or patent applications, or other proprietary 395 rights that may cover technology that may be required to implement 396 this standard. Please address the information to the IETF at 397 ietf-ipr@ietf.org. 399 Acknowledgment 401 Funding for the RFC Editor function is provided by the IETF 402 Administrative Support Activity (IASA).