idnits 2.17.1 draft-ietf-smime-sha2-04.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 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 404. 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 (March 11, 2008) is 5887 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' Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 10 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 March 11, 2008 3 Intended Status: Standard Track 4 Expires: September 11, 2008 6 Using SHA2 Algorithms with Cryptographic Message Syntax 7 draft-ietf-smime-sha2-04.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 September 11, 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]. 78 This document also specifies the algorithm identifiers and parameters 79 for use of SHA-224, SHA-256, SHA-384, and SHA-512 with DSA [DSS], RSA 80 [RFC2313], and ECDSA [X9.62]. 82 This document does not define new identifiers; they are taken from 83 [RFC3874], [RFC4055], [ECCADD], and [RFC3278]. Additionally, the 84 parameters follow the conventions specified therein. Therefore, 85 there is no Abstract Syntax Notation One (ASN.1) module included in 86 this document. 88 Note that [RFC4231] specifies the conventions for the message 89 authentication code (MAC) algorithms: HMAC with SHA-224, HMAC with 90 SHA-256, HMAC with SHA-384, and HMAC with SHA-512. 92 In CMS, the various algorithm identifiers use the AlgorithmIdentifier 93 syntax, which is included here for convenience: 95 AlgorithmIdentifier ::= SEQUENCE { 96 algorithm OBJECT IDENTIFIER, 97 parameters ANY DEFINED BY algorithm OPTIONAL } 99 2. Message Digest Algorithms 101 Digest algorithm identifiers are located in the SignedData 102 digestAlgorithms field, the SignerInfo digestAlgorithm field, the 103 DigestedData digestAlgorithm field, and the AuthenticatedData 104 digestAlgorithm field. 106 Digest values are located in the DigestedData digest field and the 107 Message Digest authenticated attribute. In addition, digest values 108 are input to signature algorithms. 110 The digest algorithm identifiers use the AlgorithmIdentifier syntax 111 elaborated upon in Section 1. 113 The algorithm field is discussed in Sections 2.1-2.4 for each message 114 digest algorithm. 116 There are two possible encodings for the SHA AlgorithmIdentifier 117 parameters field. The two alternatives arise from the fact that when 118 the 1988 syntax for AlgorithmIdentifier was translated into the 1997 119 syntax, the OPTIONAL associated with the AlgorithmIdentifier 120 parameters got lost. Later the OPTIONAL was recovered via a defect 121 report, but by then many people thought that algorithm parameters 122 were mandatory. Because of this history some implementations encode 123 parameters as a NULL element and others omit them entirely. The 124 correct encoding is to omit the parameters field; however, 125 implementations MUST also handle a SHA AlgorithmIdentifier parameters 126 field which contains a NULL. 128 The AlgorithmIdentifier parameters field is OPTIONAL. If present, 129 the parameters field MUST contain a NULL. Implementations MUST 130 accept SHA2 AlgorithmIdentifiers with absent parameters. 131 Implementations MUST accept SHA2 AlgorithmIdentifiers with NULL 132 parameters. Implementations SHOULD generate SHA2 133 AlgorithmIdentifiers with absent parameters. 135 2.1. SHA-224 137 The SHA-224 message digest algorithm is defined in [SHS]. The 138 algorithm identifier for SHA-224 is: 140 id-sha224 OBJECT IDENTIFIER ::= { 141 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 142 csor(3) nistalgorithm(4) hashalgs(2) 4 } 144 The parameters are as specified in Section 2. 146 2.2. SHA-256 148 The SHA-256 message digest algorithm is defined in [SHS]. The 149 algorithm identifier for SHA-256 is: 151 id-sha256 OBJECT IDENTIFIER ::= { 152 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 153 csor(3) nistalgorithm(4) hashalgs(2) 1 } 155 The parameters are as specified in Section 2. 157 2.3. SHA-384 159 The SHA-384 message digest algorithm is defined in [SHS]. The 160 algorithm identifier for SHA-384 is: 162 id-sha384 OBJECT IDENTIFIER ::= { 163 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 164 csor(3) nistalgorithm(4) hashalgs(2) 2 } 166 The parameters are as specified in Section 2. 168 2.4. SHA-512 170 The SHA-512 message digest algorithm is defined in [SHS]. The 171 algorithm identifier for SHA-512 is: 173 id-sha512 OBJECT IDENTIFIER ::= { 174 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 175 csor(3) nistalgorithm(4) hashalgs(2) 3 } 177 The parameters are as specified in Section 2. 179 3. Signature Algorithms 181 This section specifies the conventions employed by CMS 182 implementations that support DSA, RSA, and ECDSA with SHA2 183 algorithms. 185 Signature algorithm identifiers are located in the SignerInfo 186 signatureAlgorithm field of SignedData. Also, signature algorithm 187 identifiers are located in the SignerInfo signatureAlgorithm field of 188 countersignature attributes. 190 Signature values are located in the SignerInfo signature field of 191 SignedData. Also, signature values are located in the SignerInfo 192 signature field of countersignature attributes. 194 3.1. DSA 196 [RFC3370] section 3.1 specifies the conventions for DSA with SHA1 197 public key algorithm identifiers, parameters, public keys, and 198 signature values. DSA with SHA2 algorithms uses the same conventions 199 for these public key algorithm identifiers, parameters, public keys, 200 and signature values. DSA MAY be used with SHA-224 and SHA-256. 202 DSA has not been specified with SHA-384 and SHA-512. SHA-384 and 203 SHA-512 are not supported because the maximum bit length of p 204 (specified as L) is 3072 for DSA. For consistent cryptographic 205 strength, SHA-384 would be used with DSA where L is 7068, and SHA-512 206 would be used with DSA where L is 15360. 208 The algorithm identifier for DSA with SHA-224 signature values is: 210 id-dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 211 country(16) us(840) organization(1) gov(101) csor(3) 212 algorithms(4) id-dsa-with-sha2(3) 1 } 214 The algorithm identifier for DSA with SHA-256 signature values is: 216 id-dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 217 country(16) us(840) organization(1) gov(101) csor(3) 218 algorithms(4) id-dsa-with-sha2(3) 2 } 220 When either of these algorithm identifiers is used, the 221 AlgorithmIdentifier parameters field MUST be absent. 223 3.2. RSA 225 [RFC3370] section 3.2 specifies the conventions for RSA with SHA-1 226 (PKCS #1 v1.5) public key algorithm identifiers, parameters, public 227 keys, and signature values. RSA with SHA2 algorithms uses the same 228 conventions for these public key algorithm identifiers, parameters, 229 public keys, and signature values. RSA (PKCS #1 v1.5) MAY be used 230 with SHA-224, SHA-256, SHA-384, or SHA-512. 232 The object identifier for RSA with SHA-224 signature values is: 234 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 235 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } 237 The object identifier for RSA with SHA-256 signature values is: 239 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 240 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } 242 The object identifier for RSA with SHA-384 signature values is: 244 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 245 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } 247 The object identifier for RSA with SHA-512 signature values is: 249 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 250 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } 252 When any of these four object identifiers appears within an 253 AlgorithmIdentifier, the parameters MUST be NULL. Implementations 254 MUST accept the parameters being absent as well as present. 256 3.3. ECDSA 258 [RFC3278] section 2.1 specifies the conventions for ECDSA with SHA1 259 public key algorithm identifiers, parameters, public keys, and 260 signature values. ECDSA with SHA2 algorithms uses the same 261 conventions for these public key algorithm identifiers, parameters, 262 public keys, and signature values, except that the digestAlgorithm 263 MUST include the corresponding message digest algorithm identifier, 264 and not the sha-1 object identifier. ECDSA MAY be used with SHA-224, 265 SHA-256, SHA-384, or SHA-512. 267 The algorithm identifier for ECDSA with SHA-224 signature values is: 269 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 270 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } 272 The algorithm identifier for ECDSA with SHA-256 signature values is: 274 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 275 us(840)ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 277 The algorithm identifier for ECDSA with SHA-384 signature values is: 279 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 280 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 282 The algorithm identifier for ECDSA with SHA-512 signature values is: 284 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 285 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 287 When any of these four object identifiers appears within an 288 AlgorithmIdentifier, the parameters MUST be NULL. 290 4. Security Considerations 292 The security considerations in [RFC3278], [RFC3370], [RFC3874], 293 [RFC4055], and [ECCADD] apply. No new security considerations are 294 introduced as a result of this specification. 296 5. IANA Considerations 298 None: All identifiers are already registered. Please remove this 299 section prior to publication as an RFC. 301 6. References 303 6.1. Normative References 305 [ECCADD] Dang, S., Santesson, S., Moriarty, K., and Brown, 306 "Internet X.509 Public Key Infrastructure: Additional 307 Algorithms and Identifiers for DSA and ECDSA", work-in- 308 progress. 310 [DSS] Federal Information Processing Standards Publication 311 (FIPS PUB) 186-2, Secure Hash Standard (SHS), 2000. 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119. March 1997. 316 [RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 317 2313, March 1998. 319 [RFC3278] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of 320 Elliptic Curve Cryptography (ECC) Algorithms in 321 Cryptographic Message Syntax (CMS)", RFC 3278, April 322 2002. 324 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 325 Algorithms", RFC 3370, August 2002. 327 [RFC3852] Housley, R., "The Cryptographic Message Syntax (CMS)", 328 RFC 3852. July 2004. 330 Housley, R., "Cryptographic Message Syntax (CMS) Multiple 331 Signer Clarification", RFC 4852, April 2007. 333 [RFC3874] Housley, R., "A 224-bit One Way Hash Function: SHA-224", 334 RFC 3874. September 2004. 336 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 337 Algorithms and Identifiers for RSA Cryptography for use 338 in the Internet Public Key Infrastructure Certificate and 339 Certificate Revocation List (CRL) Profile", RFC 4055. 340 June 2005. 342 [SHS] National Institute of Standards and Technology (NIST), 343 FIPS Publication 180-2: Secure Hash Standard, 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 Author's Addresses 357 Sean Turner 359 IECA, Inc. 360 3057 Nutley Street, Suite 106 361 Fairfax, VA 22031 362 USA 364 EMail: turners@ieca.com 366 Full Copyright Statement 368 Copyright (C) The IETF Trust (2008). 370 This document is subject to the rights, licenses and restrictions 371 contained in BCP 78, and except as set forth therein, the authors 372 retain all their rights. 374 This document and the information contained herein are provided on an 375 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 376 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 377 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 378 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 379 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 380 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 382 Intellectual Property 384 The IETF takes no position regarding the validity or scope of any 385 Intellectual Property Rights or other rights that might be claimed to 386 pertain to the implementation or use of the technology described in 387 this document or the extent to which any license under such rights 388 might or might not be available; nor does it represent that it has 389 made any independent effort to identify any such rights. Information 390 on the procedures with respect to rights in RFC documents can be 391 found in BCP 78 and BCP 79. 393 Copies of IPR disclosures made to the IETF Secretariat and any 394 assurances of licenses to be made available, or the result of an 395 attempt made to obtain a general license or permission for the use of 396 such proprietary rights by implementers or users of this 397 specification can be obtained from the IETF on-line IPR repository at 398 http://www.ietf.org/ipr. 400 The IETF invites any interested party to bring to its attention any 401 copyrights, patents or patent applications, or other proprietary 402 rights that may cover technology that may be required to implement 403 this standard. Please address the information to the IETF at 404 ietf-ipr@ietf.org. 406 Acknowledgment 408 Funding for the RFC Editor function is provided by the IETF 409 Administrative Support Activity (IASA).