idnits 2.17.1 draft-ietf-smime-rfc3278-update-00.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 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 306. 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 (February 12, 2008) is 5917 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 220, but not defined == Missing Reference: 'SEC2' is mentioned on line 125, but not defined == Missing Reference: 'FIPS-180' is mentioned on line 203, but not defined == Missing Reference: 'FIPS' is mentioned on line 220, but not defined == Missing Reference: 'FIPS-186-2' is mentioned on line 220, 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 February 12, 2008 3 Intended Status: Information 4 Updates: 3278 (once approved) 5 Expires: August 12, 2008 7 Update to Use of Elliptic Curve Cryptography (ECC) Algorithms 8 in Cryptographic Message Syntax (CMS) 9 draft-ietf-smime-rfc3278-update-00.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 July 12, 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 8.1.......................................3 65 4. Updates to Paragraph 9.........................................5 66 5. Changes to Security Considerations.............................5 67 6. Security Considerations........................................5 68 7. IANA Considerations............................................5 69 8. References.....................................................6 70 8.1. Normative References......................................6 71 8.2. Informative References....................................6 73 1. Introduction 75 RFC 3278 describes how to use Elliptic Curve Cryptography (ECC) 76 public-key algorithms in the Cryptographic Message Syntax (CMS). 77 This document updates RFC 3278 to add support for the SHA2 family of 78 hash algorithms. 80 There are changes to four paragraphs: 82 - Paragraph 2.1.1 limited the digest algorithm to SHA-1. This 83 document expands the allowed algorithms to SHA-224, SHA-256, SHA- 84 284, and SHA-512. 86 - Paragraph 8.1 listed the algorithm identifiers for SHA-1 and SHA-1 87 with ECDSA. This document adds algorithms for SHA-224, SHA-256, 88 SHA-284, and SHA-512 and SHA-224, SHA-256, SHA-284, and SHA-512 89 with ECDSA. 91 - Paragraph 9 references need to be updated. 93 - Security considerations paragraph referring to definitions of SHA- 94 224, SHA-256, SHA-284, and SHA-512 needs to be deleted. 96 2. Updates to Paragraph 2.1.1 98 Old: 100 digestAlgorithm MUST contain the algorithm identifier sha-1 (see 101 Section 8.1) which identifies the SHA-1 hash algorithm. 103 signatureAlgorithm contains the algorithm identifier ecdsa-with- 104 SHA1 (see Section 8.1) which identifies the ECDSA signature 105 algorithm. 107 New: 109 digestAlgorithm MUST contain the algorithm identifier of the hash 110 algorithm (see Section 8.1): id-sha1 identifies the SHA-1 hash 111 algorithm, id-sha224 identifies the SHA-224 hash algorithm, id- 112 sha256 identifies the SHA-256 hash algorithm, id-sha384 113 identifies the SHA-384 algorithm, and id-sha512 identifies the 114 SHA-512 algorithm. 116 signatureAlgorithm contains the signature algorithm identifier 117 (see Section 8.1): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa- 118 with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512. 120 3. Updates to Paragraph 8.1 122 Old: 124 The algorithm identifiers used in this document are taken from 125 [X9.62], [SEC1] and [SEC2]. 127 The following object identifier indicates the hash algorithm used 128 in this document: 130 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 131 oiw(14) secsig(3) algorithm(2) 26 } 133 New: 135 The algorithm identifiers used in this document are taken from 136 [SMIME-SHA2] 138 The following object identifier indicates the hash algorithm used 139 in this document: 141 id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified- 142 organization(3) oiw(14) secsig(3) algorithm(2) 26 } 144 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 145 country(16) us(840) organization(1) gov(101) csor(3) 146 nistalgorithm(4) hashalgs(2) 4 } 148 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 149 country(16) us(840) organization(1) gov(101) csor(3) 150 nistalgorithm(4) hashalgs(2) 1 } 152 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 153 country(16) us(840) organization(1) gov(101) csor(3) 154 nistalgorithm(4) hashalgs(2) 2 } 156 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 157 country(16) us(840) organization(1) gov(101) csor(3) 158 nistalgorithm(4) hashalgs(2) 3 } 160 Old: 162 The following object identifier indicates the digital signature 163 algorithm used in this document: 165 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { ansi-x9-62 166 signatures(4) 1 } 168 New: 170 The following object identifier indicates the digital signature 171 algorithm used in this document: 173 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { ansi-x9-62 174 signatures(4) 1 } 176 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { ansi-x9-62 177 signatures(4) ecdsa-with-SHA2(3) 1 } 179 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { ansi-x9-62 180 signatures(4) ecdsa-with-SHA2(3) 2 } 182 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { ansi-x9-62 183 signatures(4) ecdsa-with-SHA2(3) 3 } 185 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { ansi-x9-62 186 signatures(4) ecdsa-with-SHA2(3) 4 } 188 4. Updates to Paragraph 9 190 Add the following reference: 192 [SMIME-SHA2] Turner, S., "Using SHA2 Algorithms with 193 Cryptographic Message Syntax", work-in-progress. 195 Update the following references: 197 Old: 199 [PKI-ALG] Bassham, L., Housley R. and W. Polk, "Algorithms and 200 Identifiers for the Internet X.509 Public Key Infrastructure 201 Certificate and CRL Profile", RFC 3279, April 2002. 203 [FIPS-180] FIPS 180-1, "Secure Hash Standard", National Institute 204 of Standards and Technology, April 17, 1995. 206 New: 208 [PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and W. 209 Polk, " Elliptic Curve Cryptography Subject Public Key 210 Information", work-in-progress. 212 [FIPS] FIPS 180-2, "Secure Hash Standard", National Institute of 213 Standards and Technology, August 1, 2002. 215 5. Changes to Security Considerations 217 Delete the following: 219 When 256, 384, and 512 bit hash functions succeed SHA-1 in future 220 revisions of [FIPS], [FIPS-186-2], [X9.62] and [SEC1], then they 221 can similarly succeed SHA-1 in a future revision of this 222 document. 224 6. Security Considerations 226 No new security considerations to those already specified in 227 [RFC3278], [SMIME-SHA2], and [PKI-ALG]. 229 7. IANA Considerations 231 None: All identifiers are already registered. Please remove this 232 section prior to publication as an RFC. 234 8. References 236 8.1. Normative References 238 [MUST] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", RFC 2119, BCP 14, March 1997. 241 [PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and W. 242 Polk, "Elliptic Curve Cryptography Subject Public Key 243 Information", work-in-progress. 245 [SMIME-SHA2] Turner, S., "Using SHA2 Algorithms with Cryptographic 246 Message Syntax", work-in-progress. 248 [RFC3278] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of 249 Elliptic Curve Cryptography (ECC) Algorithms in 250 Cryptographic Message Syntax (CMS)", RFC 3278, April 251 2002. 253 8.2. Informative References 255 None. 257 Author's Addresses 259 Sean Turner 261 IECA, Inc. 262 3057 Nutley Street, Suite 106 263 Fairfax, VA 22031 264 USA 266 Email: turners@ieca.com 268 Full Copyright Statement 270 Copyright (C) The IETF Trust (2008). 272 This document is subject to the rights, licenses and restrictions 273 contained in BCP 78, and except as set forth therein, the authors 274 retain all their rights. 276 This document and the information contained herein are provided on an 277 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 278 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 279 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 280 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 281 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 282 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 284 Intellectual Property 286 The IETF takes no position regarding the validity or scope of any 287 Intellectual Property Rights or other rights that might be claimed to 288 pertain to the implementation or use of the technology described in 289 this document or the extent to which any license under such rights 290 might or might not be available; nor does it represent that it has 291 made any independent effort to identify any such rights. Information 292 on the procedures with respect to rights in RFC documents can be 293 found in BCP 78 and BCP 79. 295 Copies of IPR disclosures made to the IETF Secretariat and any 296 assurances of licenses to be made available, or the result of an 297 attempt made to obtain a general license or permission for the use of 298 such proprietary rights by implementers or users of this 299 specification can be obtained from the IETF on-line IPR repository at 300 http://www.ietf.org/ipr. 302 The IETF invites any interested party to bring to its attention any 303 copyrights, patents or patent applications, or other proprietary 304 rights that may cover technology that may be required to implement 305 this standard. Please address the information to the IETF at 306 ietf-ipr@ietf.org. 308 Acknowledgment 310 Funding for the RFC Editor function is provided by the IETF 311 Administrative Support Activity (IASA).