idnits 2.17.1 draft-ietf-smime-rfc3278-update-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 354. 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 == Unrecognized Status in 'Intended Status: Information', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) (Using the creation date from RFC3278, updated by this document, for RFC5378 checks: 1999-10-26) -- 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 31, 2008) is 5869 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) == Missing Reference: 'SEC1' is mentioned on line 268, but not defined == Missing Reference: 'SEC2' is mentioned on line 175, but not defined == Missing Reference: 'FIPS-180' is mentioned on line 251, but not defined == Missing Reference: 'FIPS' is mentioned on line 268, but not defined == Missing Reference: 'FIPS-186-2' is mentioned on line 268, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'PKI-ALG' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMIME-SHA2' ** Obsolete normative reference: RFC 3278 (Obsoleted by RFC 5753) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 9 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 31, 2008 3 Intended Status: Information 4 Updates: 3278 (once approved) 5 Expires: September 31, 2008 7 Update to Use of Elliptic Curve Cryptography (ECC) Algorithms 8 in Cryptographic Message Syntax (CMS) 9 draft-ietf-smime-rfc3278-update-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on September 31, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 RFC 3278 describes how to use Elliptic Curve Cryptography (ECC) 43 public-key algorithms in the Cryptographic Message Syntax (CMS). 44 This document updates RFC 3278 to add support for the SHA2 family of 45 hash 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 [MUST]. 53 Discussion 55 This draft is being discussed on the 'ietf-smime' mailing list. To 56 subscribe, send a message to ietf-smime-request@imc.org with the 57 single word subscribe in the body of the message. There is a Web site 58 for the mailing list at . 60 Table of Contents 62 1. Introduction......................................... 2 63 2. Updates to Paragraph 2.1.1............................. 3 64 3. Updates to Paragraph 5 ................................ 3 65 4. Updates to Paragraph 7 ................................ 4 66 5. Updates to Paragraph 8.1............................... 4 67 6. Updates to Paragraph 9 ................................ 6 68 7. Changes to Security Considerations....................... 6 69 8. Security Considerations................................ 6 70 9. IANA Considerations................................... 7 71 10. References ......................................... 7 72 10.1. Normative References............................. 7 73 10.2. Informative References ........................... 7 75 1. Introduction 77 RFC 3278 describes how to use Elliptic Curve Cryptography (ECC) 78 public-key algorithms in the Cryptographic Message Syntax (CMS). 79 This document updates RFC 3278 to add support for the SHA2 family of 80 hash algorithms. 82 The following summarizes the changes: 84 - Paragraph 2.1.1 limited the digest algorithm to SHA-1. This 85 document expands the allowed algorithms to SHA-224, SHA-256, SHA- 86 384, and SHA-512. 88 - Paragraph 5 added requirements for hash algorithms and 89 recommendations for matching curves and hash algorithms. 91 - Paragraph 7 added S/MIME capabilities for ECDSA with SHA-224, SHA- 92 256, SHA-384, and SHA-512. 94 - Paragraph 8.1 listed the algorithm identifiers for SHA-1 and SHA-1 95 with ECDSA. This document adds algorithms for SHA-224, SHA-256, 96 SHA-384, and SHA-512 and SHA-224, SHA-256, SHA-384, and SHA-512 97 with ECDSA. 99 - Paragraph 9 references need to be updated. 101 - Security considerations paragraph referring to definitions of SHA- 102 224, SHA-256, SHA-384, and SHA-512 needs to be deleted. 104 2. Updates to Paragraph 2.1.1 106 Old: 108 digestAlgorithm MUST contain the algorithm identifier sha-1 (see 109 Section 8.1) which identifies the SHA-1 hash algorithm. 111 signatureAlgorithm contains the algorithm identifier ecdsa-with- 112 SHA1 (see Section 8.1) which identifies the ECDSA signature 113 algorithm. 115 New: 117 digestAlgorithm MUST contain the algorithm identifier of the hash 118 algorithm (see Section 8.1): id-sha1 identifies the SHA-1 hash 119 algorithm, id-sha224 identifies the SHA-224 hash algorithm, id- 120 sha256 identifies the SHA-256 hash algorithm, id-sha384 121 identifies the SHA-384 algorithm, and id-sha512 identifies the 122 SHA-512 algorithm. 124 signatureAlgorithm contains the signature algorithm identifier 125 (see Section 8.1): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa- 126 with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512. 128 3. Updates to Paragraph 5 130 Add the following to the end of the section: 132 Implementations of this specification MUST implement the SHA-256 133 hash algorithm. The SHA-1, SHA-224, SHA-384, SHA-512 hash 134 algorithms MAY be supported. 136 When ECDSA is used, it is RECOMMENDED that the P-256 curve be 137 used with SHA-256, the P-384 curve be used with SHA-384, and the 138 P-521 curve be used with SHA-512. 140 4. Updates to Paragraph 7 142 Old: 144 The SMIMECapability value to indicate support for the ECDSA 145 signature algorithm is the SEQUENCE with the capabilityID field 146 containing the object identifier ecdsa-with-SHA1 with NULL 147 parameters. The DER encoding is: 149 30 0b 06 07 2a 86 48 ce 3d 04 01 05 00 151 New: 153 The SMIMECapability value to indicate support for the ECDSA 154 signature algorithm is the SEQUENCE with the capabilityID field 155 containing the object identifiers ecdsa-with-SHA1, 156 ecdsa-with-withSHA224, ecdsa-with-SHA256, ecdsa-with-SHA384, and 157 ecdsa-with-SHA512 all with NULL parameters. The DER encodings 158 are: 160 ecdsa-with-SHA1: 30 0b 06 07 2a 86 48 ce 3d 04 01 05 00 162 ecdsa-with-SHA224: 30 0c 06 08 2a 86 48 ce 3d 04 03 01 05 00 164 ecdsa-with-SHA256: 30 0c 06 08 2a 86 48 ce 3d 04 03 02 05 00 166 ecdsa-with-SHA384: 30 0c 06 08 2a 86 48 ce 3d 04 03 03 05 00 168 ecdsa-with-SHA512: 30 0c 06 08 2a 86 48 ce 3d 04 03 04 05 00 170 5. Updates to Paragraph 8.1 172 Old: 174 The algorithm identifiers used in this document are taken from 175 [X9.62], [SEC1] and [SEC2]. 177 The following object identifier indicates the hash algorithm used 178 in this document: 180 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 181 oiw(14) secsig(3) algorithm(2) 26 } 183 New: 185 The algorithm identifiers used in this document are taken from 186 [SMIME-SHA2] 187 The following object identifier indicates the hash algorithm used 188 in this document: 190 id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified- 191 organization(3) oiw(14) secsig(3) algorithm(2) 26 } 193 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 194 country(16) us(840) organization(1) gov(101) csor(3) 195 nistalgorithm(4) hashalgs(2) 4 } 197 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 198 country(16) us(840) organization(1) gov(101) csor(3) 199 nistalgorithm(4) hashalgs(2) 1 } 201 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 202 country(16) us(840) organization(1) gov(101) csor(3) 203 nistalgorithm(4) hashalgs(2) 2 } 205 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 206 country(16) us(840) organization(1) gov(101) csor(3) 207 nistalgorithm(4) hashalgs(2) 3 } 209 Old: 211 The following object identifier indicates the digital signature 212 algorithm used in this document: 214 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { ansi-x9-62 215 signatures(4) 1 } 217 New: 219 The following object identifier indicates the digital signature 220 algorithm used in this document: 222 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { ansi-x9-62 223 signatures(4) 1 } 225 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { ansi-x9-62 226 signatures(4) ecdsa-with-SHA2(3) 1 } 228 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { ansi-x9-62 229 signatures(4) ecdsa-with-SHA2(3) 2 } 231 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { ansi-x9-62 232 signatures(4) ecdsa-with-SHA2(3) 3 } 233 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { ansi-x9-62 234 signatures(4) ecdsa-with-SHA2(3) 4 } 236 6. Updates to Paragraph 9 238 Add the following reference: 240 [SMIME-SHA2] Turner, S., "Using SHA2 Algorithms with 241 Cryptographic Message Syntax", work-in-progress. 243 Update the following references: 245 Old: 247 [PKI-ALG] Bassham, L., Housley R. and W. Polk, "Algorithms and 248 Identifiers for the Internet X.509 Public Key Infrastructure 249 Certificate and CRL Profile", RFC 3279, April 2002. 251 [FIPS-180] FIPS 180-1, "Secure Hash Standard", National Institute 252 of Standards and Technology, April 17, 1995. 254 New: 256 [PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and W. 257 Polk," Elliptic Curve Cryptography Subject Public Key 258 Information", work-in-progress. 260 [FIPS] FIPS 180-2, "Secure Hash Standard", National Institute of 261 Standards and Technology, August 1, 2002. 263 7. Changes to Security Considerations 265 Delete the following: 267 When 256, 384, and 512 bit hash functions succeed SHA-1 in future 268 revisions of [FIPS], [FIPS-186-2], [X9.62] and [SEC1], then they 269 can similarly succeed SHA-1 in a future revision of this 270 document. 272 8. Security Considerations 274 No new security considerations to those already specified in 275 [RFC3278], [SMIME-SHA2], and [PKI-ALG]. 277 9. IANA Considerations 279 None: All identifiers are already registered. Please remove this 280 section prior to publication as an RFC. 282 10. References 284 10.1. Normative References 286 [MUST] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", RFC 2119, BCP 14, March 1997. 289 [PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and W. 290 Polk, "Elliptic Curve Cryptography Subject Public Key 291 Information", work-in-progress. 293 [SMIME-SHA2] Turner, S., "Using SHA2 Algorithms with Cryptographic 294 Message Syntax", work-in-progress. 296 [RFC3278] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of 297 Elliptic Curve Cryptography (ECC) Algorithms in 298 Cryptographic Message Syntax (CMS)", RFC 3278, April 299 2002. 301 10.2. Informative References 303 None. 305 Author's Addresses 307 Sean Turner 309 IECA, Inc. 310 3057 Nutley Street, Suite 106 311 Fairfax, VA 22031 312 USA 314 Email: turners@ieca.com 316 Full Copyright Statement 318 Copyright (C) The IETF Trust (2008). 320 This document is subject to the rights, licenses and restrictions 321 contained in BCP 78, and except as set forth therein, the authors 322 retain all their rights. 324 This document and the information contained herein are provided on an 325 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 327 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 328 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 329 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 Intellectual Property 334 The IETF takes no position regarding the validity or scope of any 335 Intellectual Property Rights or other rights that might be claimed to 336 pertain to the implementation or use of the technology described in 337 this document or the extent to which any license under such rights 338 might or might not be available; nor does it represent that it has 339 made any independent effort to identify any such rights. Information 340 on the procedures with respect to rights in RFC documents can be 341 found in BCP 78 and BCP 79. 343 Copies of IPR disclosures made to the IETF Secretariat and any 344 assurances of licenses to be made available, or the result of an 345 attempt made to obtain a general license or permission for the use of 346 such proprietary rights by implementers or users of this 347 specification can be obtained from the IETF on-line IPR repository at 348 http://www.ietf.org/ipr. 350 The IETF invites any interested party to bring to its attention any 351 copyrights, patents or patent applications, or other proprietary 352 rights that may cover technology that may be required to implement 353 this standard. Please address the information to the IETF at 354 ietf-ipr@ietf.org. 356 Acknowledgment 358 Funding for the RFC Editor function is provided by the IETF 359 Administrative Support Activity (IASA).