idnits 2.17.1 draft-ietf-smime-sha2-03.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 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 411. 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 (January 30, 2008) is 5923 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 January 30, 2008 3 Intended Status: Standard Track 4 Expires: July 30, 2008 6 Using SHA2 Algorithms with Cryptographic Message Syntax 7 draft-ietf-smime-sha2-03.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 July 30, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 This document describes the conventions for using the message digest 41 algorithms SHA-224, SHA-256, SHA-384, SHA-512, as defined in FIPS 42 180-3, with the Cryptographic Message Syntax (CMS). It also describes 43 the conventions for using these algorithms with CMS and the DSA, RSA, 44 and ECDSA signature algorithms. 46 Conventions used in this document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in [RFC2119]. 52 Table of Contents 54 1. Introduction...................................................2 55 2. Message Digest Algorithms......................................3 56 2.1. SHA-224...................................................4 57 2.2. SHA-256...................................................4 58 2.3. SHA-384...................................................4 59 2.4. SHA-512...................................................4 60 3. Signature Algorithms...........................................5 61 3.1. DSA.......................................................5 62 3.2. RSA.......................................................6 63 3.3. ECDSA.....................................................6 64 4. Security Considerations........................................7 65 5. IANA Considerations............................................7 66 6. References.....................................................7 67 6.1. Normative References......................................7 68 6.2. Informative References....................................8 70 1. Introduction 72 This document specifies the algorithm identifiers and specifies 73 parameters for the message digest algorithms SHA-224, SHA-256, SHA- 74 384, and SHA-512 for use with the Cryptographic Message Syntax (CMS) 75 [RFC3852]. The message digest algorithms are defined in and [SHS]. 76 If an implementation chooses to support one of the algorithms 77 discussed in this document, then the implementation MUST do so as 78 described in this document. 80 This document also specifies the algorithm identifiers and parameters 81 for use of SHA-224, SHA-256, SHA-384, and SHA-512 with DSA, RSA, and 82 ECDSA. If an implementation chooses to support one of the algorithms 83 discussed in this document, then the implementation MUST do so as 84 described in this document. 86 This document does not define new identifiers; they are taken from 87 [RFC3874], [RFC4055], [ECCADD], [RFC3278], and [RFC3370]. 88 Additionally, the parameters follow the conventions specified 89 therein. Therefore, there is no ASN.1 module included in this 90 document. 92 Note that [RFC4231] specifies the conventions for use of for the 93 message authentication code (MAC) algorithms: HMAC with SHA-224, HMAC 94 with SHA-256, HMAC with SHA-384, and HMAC with SHA-512. 96 In CMS, the various algorithm identifiers use the AlgorithmIdentifier 97 syntax, which is included here for convenience: 99 AlgorithmIdentifier ::= SEQUENCE { 100 algorithm OBJECT IDENTIFIER, 101 parameters ANY DEFINED BY algorithm OPTIONAL } 103 2. Message Digest Algorithms 105 Digest algorithm identifiers are located in the SignedData 106 digestAlgorithms field, the SignerInfo digestAlgorithm field, the 107 DigestedData digestAlgorithm field, and the AuthenticatedData 108 digestAlgorithm field. 110 Digest values are located in the DigestedData digest field and the 111 Message Digest authenticated attribute. In addition, digest values 112 are input to signature algorithms. 114 The digest algorithm identifiers use the AlgorithmIdentifier syntax 115 elaborated upon in Section 1. 117 The algorithm field is discussed in Sections 2.1-2.4 for each message 118 digest algorithm. 120 The following addresses the parameters field: 122 There are two possible encodings for the SHA AlgorithmIdentifier 123 parameters field. The two alternatives arise from the fact that when 124 the 1988 syntax for AlgorithmIdentifier was translated into the 1997 125 syntax, the OPTIONAL associated with the AlgorithmIdentifier 126 parameters got lost. Later the OPTIONAL was recovered via a defect 127 report, but by then many people thought that algorithm parameters 128 were mandatory. Because of this history some implementations encode 129 parameters as a NULL element and others omit them entirely. The 130 correct encoding is to omit the parameters field; however, 131 implementations MUST also handle a SHA AlgorithmIdentifier parameters 132 field which contains a NULL. 134 The AlgorithmIdentifier parameters field is OPTIONAL. If present, 135 the parameters field MUST contain a NULL. Implementations MUST 136 accept SHA2 AlgorithmIdentifiers with absent parameters. 137 Implementations MUST accept SHA2 AlgorithmIdentifiers with NULL 138 parameters. Implementations SHOULD generate SHA2 139 AlgorithmIdentifiers with absent parameters. 141 2.1. SHA-224 143 The SHA-224 message digest algorithm is defined in [SHS]. The 144 algorithm identifier for SHA-224 is: 146 id-sha224 OBJECT IDENTIFIER ::= { 147 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 148 csor(3) nistalgorithm(4) hashalgs(2) 4 } 150 The parameters are as specified in Section 2. 152 2.2. SHA-256 154 The SHA-256 message digest algorithm is defined in [SHS]. The 155 algorithm identifier for SHA-256 is: 157 id-sha256 OBJECT IDENTIFIER ::= { 158 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 159 csor(3) nistalgorithm(4) hashalgs(2) 1 } 161 The parameters are as specified in Section 2. 163 2.3. SHA-384 165 The SHA-384 message digest algorithm is defined in [SHS]. The 166 algorithm identifier for SHA-384 is: 168 id-sha384 OBJECT IDENTIFIER ::= { 169 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 170 csor(3) nistalgorithm(4) hashalgs(2) 2 } 172 The parameters are as specified in Section 2. 174 2.4. SHA-512 176 The SHA-256 message digest algorithm is defined in [SHS]. The 177 algorithm identifier for SHA-512 is: 179 id-sha512 OBJECT IDENTIFIER ::= { 180 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 181 csor(3) nistalgorithm(4) hashalgs(2) 3 } 183 The parameters are as specified in Section 2. 185 3. Signature Algorithms 187 This section specifies the conventions employed by CMS 188 implementations that support DSA [DSS], ECDSA [X9.62], and RSA 189 [RFC2313] with SHA2 algorithms. 191 Signature algorithm identifiers are located in the SignerInfo 192 signatureAlgorithm field of SignedData. Also, signature algorithm 193 identifiers are located in the SignerInfo signatureAlgorithm field of 194 countersignature attributes. 196 Signature values are located in the SignerInfo signature field of 197 SignedData. Also, signature values are located in the SignerInfo 198 signature field of countersignature attributes. 200 NOTE [to be removed upon publication as an RFC]: NIST has not yet 201 finalized FIPS 186-3 and there is a chance that the draft may be 202 changed. This may result in differences between what is documented 203 in the current version of this document and what is in the FIPS. It 204 is intended to synchronize the final version of this draft with the 205 FIPS before publication as an RFC. 207 3.1. DSA 209 [RFC3370] section 3.1 specifies the conventions for DSA with SHA1 210 public key algorithm identifiers, parameters, public keys, and 211 signature values. DSA with SHA2 algorithms uses the same conventions 212 for these public key algorithm identifiers, parameters, public keys, 213 and signature values. DSA MAY be used with SHA-224 and SHA-256. 215 The algorithm identifier for DSA with SHA-224 signature values is: 217 id-dsa-with-sha224 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) 1 } 221 The algorithm identifier for DSA with SHA-224 signature values is: 223 id-dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 224 country(16) us(840) organization(1) gov(101) csor(3) 225 algorithms(4) id-dsa-with-sha2(3) 2 } 227 When either of these algorithm identifiers is used, the 228 AlgorithmIdentifier parameters field MUST be absent. 230 3.2. RSA 232 [RFC3370] section 3.2 specifies the conventions for RSA with SHA-1 233 (PKCS #1 v1.5) public key algorithm identifiers, parameters, public 234 keys, and signature values. RSA with SHA2 algorithms uses the same 235 conventions for these public key algorithm identifiers, parameters, 236 public keys, and signature values. RSA (PKCS #1 v1.5) MAY be used 237 with SHA-224, SHA-256, SHA-384, or SHA-512. 239 The object identifier for RSA with SHA-224 signature values is: 241 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 242 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } 244 The object identifier for RSA with SHA-256 signature values is: 246 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 247 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } 249 The object identifier for RSA with SHA-384 signature values is: 251 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 252 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } 254 The object identifier for RSA with SHA-512 signature values is: 256 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 257 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } 259 When any of these four object identifiers appears within an 260 AlgorithmIdentifier, the parameters MUST be NULL. Implementations 261 MUST accept the parameters being absent as well as present. 263 3.3. ECDSA 265 [RFC3278] section 2.1 specifies the conventions for ECDSA with SHA1 266 public key algorithm identifiers, parameters, public keys, and 267 signature values. ECDSA with SHA2 algorithms uses the same 268 conventions for these public key algorithm identifiers, parameters, 269 public keys, and signature values, except that the digestAlgorithm 270 MUST include the corresponding message digest algorithm identifier, 271 and not sha-1 object identifier. ECDSA MAY be used with SHA-224, 272 SHA-256, SHA-384, or SHA-512. 274 The algorithm identifier for ECDSA with SHA-224 signature values is: 276 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 277 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } 279 The algorithm identifier for ECDSA with SHA-256 signature values is: 281 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 282 us(840)ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 284 The algorithm identifier for ECDSA with SHA-384 signature values is: 286 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 287 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 289 The algorithm identifier for ECDSA with SHA-512 signature values is: 291 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 292 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 294 When any of these four object identifiers appears within an 295 AlgorithmIdentifier, the parameters MUST be NULL. 297 4. Security Considerations 299 The security considerations in [RFC3278], [RFC3370], [RFC3874], 300 [RFC4055], and [ECCADD] apply. No new security considerations are 301 introduced as a result of this specification. 303 5. IANA Considerations 305 None: All identifiers are already registered. Please remove this 306 section prior to publication as an RFC. 308 6. References 310 6.1. Normative References 312 [ECCADD] Dang, S., Santesson, S., Moriarty, K., and Brown, 313 "Internet X.509 Public Key Infrastructure: Additional 314 Algorithms and Identifiers for DSA and ECDSA", work-in- 315 progress. 317 [DSS] Federal Information Processing Standards Publication 318 (FIPS PUB) 186-3, Secure Hash Standard (SHS), July 2007. 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119. March 1997. 323 [RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 324 2313, March 1998. 326 [RFC3278] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of 327 Elliptic Curve Cryptography (ECC) Algorithms in 328 Cryptographic Message Syntax (CMS)", RFC 3278, April 329 2002. 331 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 332 Algorithms", RFC 3370, August 2002. 334 [RFC3852] Housley, R., "The Cryptographic Message Syntax (CMS)", 335 RFC 3852. July 2004. 337 Housley, R., "Cryptographic Message Syntax (CMS) Multiple 338 Signer Clarification", RFC 4852, April 2007. 340 [RFC3874] Housley, R., "A 224-bit One Way Hash Function: SHA-224", 341 RFC 3874. September 2004. 343 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 344 Algorithms and Identifiers for RSA Cryptography for use 345 in the Internet Public Key Infrastructure Certificate and 346 Certificate Revocation List (CRL) Profile", RFC 4055. 347 June 2005. 349 [SHS] National Institute of Standards and Technology (NIST), 350 FIPS Publication 180-3: Secure Hash Standard, June 2007. 352 [X9.62] X9.62-2005, "Public Key Cryptography for the Financial 353 Services Industry: The Elliptic Curve Digital Signature 354 Standard (ECDSA)", November, 2005. 356 6.2. Informative References 358 [RFC4231] Nystrom, A. "Identifiers and Test Vectors for HMAC-SHA- 359 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 360 RFC4231. December 2005. 362 Author's Addresses 364 Sean Turner 366 IECA, Inc. 367 3057 Nutley Street, Suite 106 368 Fairfax, VA 22031 369 USA 371 EMail: turners@ieca.com 373 Full Copyright Statement 375 Copyright (C) The IETF Trust (2008). 377 This document is subject to the rights, licenses and restrictions 378 contained in BCP 78, and except as set forth therein, the authors 379 retain all their rights. 381 This document and the information contained herein are provided on an 382 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 383 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 384 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 385 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 386 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 387 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 389 Intellectual Property 391 The IETF takes no position regarding the validity or scope of any 392 Intellectual Property Rights or other rights that might be claimed to 393 pertain to the implementation or use of the technology described in 394 this document or the extent to which any license under such rights 395 might or might not be available; nor does it represent that it has 396 made any independent effort to identify any such rights. Information 397 on the procedures with respect to rights in RFC documents can be 398 found in BCP 78 and BCP 79. 400 Copies of IPR disclosures made to the IETF Secretariat and any 401 assurances of licenses to be made available, or the result of an 402 attempt made to obtain a general license or permission for the use of 403 such proprietary rights by implementers or users of this 404 specification can be obtained from the IETF on-line IPR repository at 405 http://www.ietf.org/ipr. 407 The IETF invites any interested party to bring to its attention any 408 copyrights, patents or patent applications, or other proprietary 409 rights that may cover technology that may be required to implement 410 this standard. Please address the information to the IETF at 411 ietf-ipr@ietf.org. 413 Acknowledgment 415 Funding for the RFC Editor function is provided by the IETF 416 Administrative Support Activity (IASA).