idnits 2.17.1 draft-ietf-pkix-sha2-dsa-ecdsa-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 6) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 16 instances of too long lines in the document, the longest one being 4 characters in excess of 72. -- The abstract seems to indicate that this document updates RFC3279, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == The copyright year in the IETF Trust and authors 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 07, 2009) is 5309 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) == Unused Reference: 'SP 800-57' is defined on line 307, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 180-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 186-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP 800-107' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP 800-78-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP 800-57' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group Q. Dang (NIST) 2 Internet Draft S. Santesson 3 Intended Category: Standards Track 3xA Security (AAA-sec.com) 4 K. Moriarty(RSA) 5 D. Brown (Certicom Corp.) 6 T. Polk (NIST) 7 October 07, 2009 8 Expires: April 07, 2010 10 Internet X.509 Public Key Infrastructure: Additional Algorithms and 11 Identifiers for DSA and ECDSA 12 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 07, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your 46 rights and restrictions with respect to this document. 48 Abstract 50 This document updates RFC 3279 to specify algorithm 51 identifiers and ASN.1 encoding rules for the Digital Signature 52 Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm 53 (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384 54 or SHA-512 as hashing algorithm. This specification applies to 55 the Internet X.509 Public Key infrastructure (PKI) when digital 56 signatures are used to sign certificates and certificate 57 revocation lists(CRLs). This document also identifies all four 58 SHA2 hash algorithms for use in the Internet X.509 PKI. 60 Table of Contents 62 1. Introduction.............................................2 63 2. Hash Functions...........................................3 64 3. Signature Algorithms.....................................3 65 3.1 DSA Signature Algorithm.................................4 66 3.2 ECDSA Signature Algorithm...............................4 67 4. ASN.1 Module.............................................5 68 5. Security Considerations..................................6 69 6. References...............................................6 70 6.1 Normative references: ..................................6 71 6.2 Informative references: ................................7 72 7. Authors' Addresses.......................................7 73 8. IANA Considerations......................................8 74 9. Acknowledgement..........................................8 76 1. Introduction 78 This specification defines the contents of the 79 signatureAlgorithm, signatureValue and signature fields within 80 Internet X.509 certificates and CRLs when these objects are 81 signed using DSA or ECDSA with a SHA2 hash algorithm. These 82 fields are more fully described in RFC 5280 [RFC 5280]. This 83 document also identifies all four SHA2 hash algorithms for use 84 in the Internet X.509 PKI. 86 This document profiles material presented in the "Secure Hash 87 Standard" [FIPS 180-3], "Public Key Cryptography for the 88 Financial Services Industry: The Elliptic Curve Digital Signature 89 Standard (ECDSA)" [X9.62], and the "Digital Signature 90 Standard" [FIPS 186-3]. 92 This document updates RFC 3279 [RFC 3279] sections 2.1, 2.2.2, and 93 2.2.3. Note that RFC 5480 [RFC 5480] updates sections 2.3.5, 3 94 (ASN.1 Module) and 5 (Security Considerations) of RFC 3279. 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 97 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in 99 [RFC 2119]. 101 2. Hash Functions 103 This section identifies four additional hash algorithms for use 104 with DSA and ECDSA in the Internet X.509 certificate and CRL 105 profile [RFC 5280]. SHA-224, SHA-256, SHA-384, and SHA-512 106 produce a 224-bit, 256-bit, 384-bit and 512-bit "hash" of the 107 input respectively and are fully described in the Federal 108 Information Processing Standard 180-3 [FIPS 180-3]. 110 The listed one-way hash functions are identified by the following 111 object identifiers (OIDs): 113 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 114 country(16) us(840) organization(1) gov(101) csor(3) 115 nistalgorithm(4) hashalgs(2) 4 } 117 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 118 country(16) us(840) organization(1) gov(101) csor(3) 119 nistalgorithm(4) hashalgs(2) 1 } 121 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 122 country(16) us(840) organization(1) gov(101) csor(3) 123 nistalgorithm(4) hashalgs(2) 2 } 125 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 126 country(16) us(840) organization(1) gov(101) csor(3) 127 nistalgorithm(4) hashalgs(2) 3 } 129 When one of these OIDs appears in an AlgorithmIdentifier, all 130 implementations MUST accept both NULL and absent parameters as 131 legal and equivalent encodings. 133 Conforming CA implementations SHOULD use SHA-224, SHA-256, SHA-384 134 or SHA-512 when generating certificates or CRLs, but MAY use SHA-1 135 if they have a stated policy that requires the use of this weaker 136 algorithm. 138 3. Signature Algorithms 140 This section identifies OIDs for DSA with SHA-224 and SHA-256 as 141 well as ECDSA with SHA-224, SHA-256, SHA-384, and SHA-512. The contents 142 of the parameters component for each signature algorithm vary; details 143 are provided for each algorithm. 145 3.1 DSA Signature Algorithm 147 The DSA is defined in the Digital Signature Standard (DSS) [FIPS 148 186-3]. DSA was developed by the U.S. Government, and can be used 149 in conjunction with a SHA2 hash function such as SHA-224 150 or SHA-256. DSA is fully described in [FIPS 186-3]. 152 When SHA-224 is used, the OID is: 154 id-dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 155 country(16) us(840) organization(1) gov(101) csor(3) 156 algorithms(4) id-dsa-with-sha2(3) 1 }. 158 When SHA-256 is used, the OID is: 160 id-dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 161 country(16) us(840) organization(1) gov(101) csor(3) 162 algorithms(4) id-dsa-with-sha2(3) 2 }. 164 When the id-dsa-with-sha224 or id-dsa-with-sha256 algorithm 165 identifier appears in the algorithm field as an 166 AlgorithmIdentifier, the encoding SHALL omit the parameters field. 167 That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one 168 component, the OID id-dsa-with-sha224 or id-dsa-with-sha256. 170 Encoding rules for DSA signature values are specified in [RFC 171 3279]. 173 Conforming CA implementations that generate DSA signatures for 174 certificates or CRLs MUST generate such DSA signatures in 175 accordance with all the requirements in Sections 4.1, 4.5 and 4.6 176 of [FIPS 186-3]. 178 Conforming CA implementations that generate DSA signatures for 179 certificates or CRLs MAY generate such DSA signatures in 180 accordance with all the requirements and recommendations in [FIPS 181 186-3], if they have a stated policy that requires conformance to 182 [FIPS 186-3]. 184 3.2 ECDSA Signature Algorithm 186 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined 187 in "Public Key Cryptography for the Financial Services Industry: 188 The Elliptic Curve Digital Signature Standard (ECDSA)" [X9.62]. 189 The ASN.1 OIDs used to specify that an ECDSA signature was 190 generated using SHA-224, SHA-256, SHA-384 or SHA-512 are 191 respectively: 193 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 194 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } 196 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 197 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 199 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 200 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 202 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 203 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 205 When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384 206 or ecdsa-with-SHA512 algorithm identifier appears in the algorithm 207 field as an AlgorithmIdentifier, the encoding MUST omit the 208 parameters field. That is, the AlgorithmIdentifier SHALL be a 209 SEQUENCE of one component, the OID ecdsa-with-SHA224, ecdsa-with- 210 SHA256, ecdsa-with-SHA384 or ecdsa-with-SHA512. 212 Conforming CA implementations MUST specify the hash algorithm 213 explicitly using the OIDs specified above when encoding 214 ECDSA/SHA2 signatures in certificates and CRLs. 216 Conforming client implementations that process ECDSA signatures 217 with any of the SHA2 hash algorithms when processing certificates 218 and CRLs MUST recognize the corresponding OIDs specified above. 220 Encoding rules for ECDSA signature values are specified in RFC 3279 221 [RFC 3279] Section 2.2.3 and RFC 5480 [RFC 5480]. 223 Conforming CA implementations that generate ECDSA signatures in 224 certificates or CRLs MUST generate such ECDSA signatures in 225 accordance with all the requirements specified in Sections 7.2 and 226 7.3 of [X9.62] or with all the requirements specified in Section 227 4.1.3 of [SEC1]. 229 Conforming CA implementations that ECDSA signatures in 230 certificates or CRLs MAY generate such ECDSA signatures in 231 accordance with all the requirements and recommendations in 232 [X9.62] or [SEC1] if they have a stated policy that requires 233 conformance to [X9.62] or [SEC1]. 235 4. ASN.1 Module 237 The OIDs of the SHA2 hash algorithms are in the RFC 4055 [RFC 4055] 238 ASN.1 module and the OIDs for DSA with SHA-224 and SHA-256 as well 239 as ECDSA with SHA-224, SHA-256, SHA-384 and SHA-512 are defined 240 in the RFC 5480 [RFC 5480] ASN.1 module. 242 5. Security Considerations 244 NIST has defined appropriate use of the hash functions in terms of 245 the algorithm strengths and expected time frames for secure use in 246 Special Publications (SPs) 800-78-1 [SP 800-78-1], 800-57 [SP 800- 247 57] and 800-107 [SP 800-107]. These documents can be used as 248 guides to choose appropriate key sizes for various security 249 scenarios. 251 ANSI also provides security considerations for ECDSA in [X9.62]. 252 These security considerations may be used as a guide. 254 6. References 256 6.1 Normative references: 258 [RFC 2119] Bradner, S., "Key Words for Use in RFCs to 259 Indicate Requirement Levels", RFC 2119, March 1997. 261 [RFC 3279] Bassham, L., Polk, W., and R. Housley, "Algorithms 262 and Identifiers for the Internet X.509 Public Key 263 Infrastructure Certificate and Certificate 264 Revocation List (CRL) Profile", RFC 3279, April 265 2002. 267 [RFC 4055] Schaad, J., Kaliski, B., and Housley, R.,"Additional 268 Algorithms and Identifiers for RSA Cryptography for 269 use in the Internet X.509 Public Key Infrastructure 270 Certificate and Certificate Revocation List (CRL) 271 Profile", RFC 4055, June 2005. 273 [RFC 5480] Turner, S., Brown D., Yiu K., Housley R.,and Polk,T., 274 "Elliptic Curve Cryptography Subject Public Key 275 Information", RFC 5480, March 2009. 277 [RFC 5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. 278 Housley, R., and W. Polk, "Internet X.509 Public 279 Key Infrastructure Certificate and Certificate 280 Revocation List (CRL) Profile", RFC 5280, May 2008. 282 [FIPS 180-3] Federal Information Processing Standards 283 Publication (FIPS PUB) 180-3, Secure Hash Standard 284 (SHS), October 2008. 286 [FIPS 186-3] Federal Information Processing Standards 287 Publication (FIPS PUB) 186-3, Digital Signature 288 Standard (DSS), June 2009. 290 [SEC1] Standards for Efficient Cryptography SEC 1: 291 Elliptic Curve Cryptography, Version 2.0, 2009. 293 [X9.62] X9.62-2005, "Public Key Cryptography for the 294 Financial Services Industry: The Elliptic Curve 295 Digital Signature Standard (ECDSA)", November, 296 2005. 298 6.2 Informative references: 300 [SP 800-107] Quynh Dang, NIST, "Recommendation for Applications 301 Using Approved Hash Algorithms", February 2009. 303 [SP 800-78-1] W. Timothy Polk, Donna, F. Dodson, William E. 304 Burr, NIST, "Cryptographic Standards and Key Sizes 305 for Personal Identity Verification", August 2007. 307 [SP 800-57] Elaine Barker, William Barker, William E. Burr, 308 NIST, "Recommendation for Key Management", August 309 2005. 311 7. Authors' addresses 313 Quynh Dang 315 NIST 316 100 Bureau Drive, Stop 8930 317 Gaithersburg, MD 20899-8930 318 USA 320 Email: quynh.dang@nist.gov 322 Stefan Santesson 324 3xA Security (AAA-sec.com) 325 Bjornstorp 744 326 247 98 Genarp 327 Sweden 329 EMail: sts@aaa-sec.com 331 Kathleen M. Moriarty 333 RSA, The Security Division of EMC 334 174 Middlesex Turnpike 335 Bedford, MA 01730 336 Email: Moriarty_Kathleen@emc.com 338 Daniel R. L. Brown 340 Certicom Corp. 341 5520 Explorer Drive 342 Mississaug, ON L4W 5L1 344 Email: dbrown@certicom.com 346 Tim Polk 348 NIST 349 100 Bureau Drive, Stop 8930 350 Gaithersburg, MD 20899-8930 351 USA 353 Email: tim.polk@nist.gov 355 8. IANA Considerations 357 This document has no actions for IANA. 359 9. Acknowledgement 361 Authors of this document would like to acknowledge great inputs 362 for this document from Alfred Hoenes, Sean Turner, Katrin Hoeper 363 and many others from IETF community. The authors also appreciate 364 many great revision suggestions from Russ Housley and Paul 365 Hoffman.