idnits 2.17.1 draft-ietf-pkix-sha2-dsa-ecdsa-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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 696. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (June 19, 2008) is 5790 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: 'RFC 2119' is mentioned on line 563, but not defined == Missing Reference: 'RFC 3279' is mentioned on line 567, but not defined == Missing Reference: 'RFC 5280' is mentioned on line 573, but not defined == Missing Reference: 'FIPS 180-3' is mentioned on line 591, but not defined == Missing Reference: 'FIPS 186-3' is mentioned on line 596, but not defined Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group Q. Dang (NIST) 3 Internet Draft S. Santesson (Microsoft) 4 Intended Category:Standards Track K. Moriarty (RSA) 5 Expires: December 2008 D. Brown (Certicom Corp.) 6 T. Polk (NIST) 7 June 19, 2008 9 Internet X.509 Public Key Infrastructure: 10 Additional Algorithms and Identifiers for 11 DSA and ECDSA 13 15 Status of this Memo 17 By submitting this Internet-Draft, each author 18 represents that any applicable patent or other 19 IPR claims of which he or she is aware have 20 been or will be disclosed, and any of which he 21 or she becomes aware will be disclosed, in 22 accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the 25 Internet Engineering Task Force (IETF), its 26 areas, and its working groups. Note that other 27 groups may also distribute working documents 28 as Internet-Drafts. 30 Internet-Drafts are draft documents valid for 31 a maximum of six months and may be updated, 32 replaced, or obsoleted by other documents at 33 any time. It is inappropriate to use Internet- 34 Drafts as reference material or to cite them 35 other than as "work in progress." 37 The list of current Internet-Drafts can be 38 accessed at http://www.ietf.org/ietf/1id- 39 abstracts.txt 41 The list of Internet-Draft Shadow Directories 42 can be accessed at 43 http://www.ietf.org/shadow.html. 45 Copyright Notice 46 Copyright (C) The IETF Trust (2008). 48 Abstract 50 This document supplements RFC 3279. It 51 specifies algorithm identifiers and ASN.1 52 encoding rules for the Digital Signature 53 Algorithm (DSA) and Elliptic Curve Digital 54 Signature Algorithm (ECDSA) digital signatures 55 when using SHA-224, SHA-256, SHA-384 or SHA- 56 512 as hashing algorithm. This specification 57 applies to the Internet X.509 Public Key 58 Infrastructure (PKI) when digital signatures 59 are used to sign certificates and certificate 60 revocation lists (CRLs). 62 The key words "MUST", "MUST NOT", "REQUIRED", 63 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 64 "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in 66 [RFC 2119]. 68 Table of Contents 70 1. Introduction......................................3 71 2. One-way Hash Functions............................3 72 3. Signature Algorithm...............................4 73 3.1. DSA Signature Algorithm......................5 74 3.2. ECDSA Signature Algorithm....................6 75 3.2.1. ECDSA with SHA-2 Hash Algorithms........8 76 3.2.2. ECDSA with Recommended Hash Algorithm...8 77 3.2.3. ECDSA with Specified Hash Algorithm.....9 78 4. ASN.1 Module......................................9 79 5. Security Considerations..........................11 80 6. References.......................................13 81 6.1. Normative references:.......................13 82 6.2. Informative references......................14 83 7. Authors' Addresses...............................15 84 8. Acknowledgements.................................15 85 9. IANA Considerations..............................16 86 10. Intellectual Property...........................16 87 11. Copyright Statement.............................16 89 1. Introduction 91 This specification supplements [RFC 3279], "Algorithms 92 and Identifiers for the Internet X.509 Public Key 93 Infrastructure Certificate and Certificate Revocation 94 List (CRL) Profile" and extends the list of 95 algorithms defined for use in the Internet PKI. This 96 document specifies algorithm identifiers and ASN.1 [X.660] 97 encoding rules for DSA and ECDSA digital signatures in 98 certificates and CRLs when using one of the SHA-2 hash 99 algorithms (SHA-224, SHA-256, SHA-384, and SHA-512) as the 100 hash algorithm. 102 This specification defines the contents of the 103 signatureAlgorithm, signatureValue and signature fields 104 within Internet X.509 certificates and CRLs when these 105 objects are signed using DSA or ECDSA with a SHA-2 hash 106 algorithm. These fields are more fully described in 107 [RFC 5280]. 109 This document profiles material presented in the "Secure 110 Hash Standard" [FIPS 180-3], "Public Key Cryptography for 111 the Financial Services Industry: The Elliptic Curve 112 Digital Signature Standard (ECDSA)" [X9.62], and the 113 "Digital Signature Standard" [FIPS 186-3]. 115 Algorithm identifiers and encoding rules for RSA, DSA and 116 ECDSA when used with SHA-1 are specified in [RFC 3279]. 117 Algorithm identifiers and encoding rules for RSA when used 118 with SHA-2 are specified in [RFC 4055]. 120 2. One-way Hash Functions 122 This section identifies four additional hash algorithms 123 for use with DSA and ECDSA in the Internet X.509 124 certificate and CRL profile [RFC 5280]. 126 SHA-224, SHA-256, SHA-384, and SHA-512 produce a 224-bit, 127 256-bit, 384-bit and 512-bit "hash" of the input 128 respectively and are fully described in the Federal 129 Information Processing Standard 180-3 [FIPS 180-3]. 131 The listed one-way hash functions are identified by the 132 following object identifiers (OIDs): 134 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 135 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 136 hashalgs(2) 4 } 138 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 139 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 140 hashalgs(2) 1 } 142 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 143 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 144 hashalgs(2) 2 } 146 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 147 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 148 hashalgs(2) 3 } 150 When one of these OIDs appears in an AlgorithmIdentifier, 151 all implementations MUST accept both NULL and absent 152 parameters as legal and equivalent encodings. 154 3. Signature Algorithm 156 Certificates and CRLs conforming to [RFC 5280] may be 157 signed with any public key signature algorithm. The 158 certificate or CRL indicates the algorithm through an 159 identifier, which appears in the signatureAlgorithm field 160 within the Certificate or CertificateList. This algorithm 161 identifier is an OID and has optionally associated 162 parameters. This section denotes algorithm identifiers and 163 parameters that MUST be used in the signatureAlgorithm 164 field in a Certificate or CertificateList. 166 Signature algorithms are always used in conjunction with a 167 one-way hash function. This section identifies OIDs for 168 DSA and ECDSA with SHA-224, SHA-256, SHA-384, and SHA-512. 169 The contents of the parameters component for each 170 signature algorithm vary; details are provided for each 171 algorithm. 173 The data to be signed (e.g., the one-way hash function 174 output value) is formatted for the signature algorithm to 175 be used. Then, a private key operation (e.g., DSA 176 encryption) is performed to generate the signature value. 177 This signature value is then ASN.1 encoded as a BIT STRING 178 and included in the Certificate or CertificateList in the 179 signature field. More detail on how digital signatures are 180 generated can be found in [FIPS 186-3]. 182 Entities that validate DSA signatures MUST support SHA-224 183 and SHA-256. Entities that validate ECDSA signatures MUST 184 support SHA-224 and SHA-256 and should support SHA-384 and 185 SHA-512. 187 3.1. DSA Signature Algorithm 189 The DSA is defined in the Digital Signature Standard (DSS) 190 [FIPS 186-3]. DSA was developed by the U.S. Government, 191 and can be used in conjunction with a SHA2 one-way hash 192 function such as SHA-224 or SHA-256. DSA is fully 193 described in [FIPS 186-3]. 195 [FIPS 186-3] specifies four size-choices for a DSA key 196 pair of the form (public key size, private key size) in 197 bits. The four choices are (1024, 160), (2048, 224), 198 (2048, 256), and (3072, 256). More information can be 199 found in [FIPS 186-3]. 201 DSA key pairs of the sizes (1024, 160) and (2048, 224) may 202 be used with SHA-224. DSA key pairs of all the 203 four sizes may use SHA-256. The following are the OIDs of 204 the DSA digital signature algorithm when used with SHA-224 205 or SHA-256. 207 When SHA-224 is used, the OID is: 209 dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 210 country(16) us(840) organization(1) gov(101) csor(3) 211 algorithms(4) id-dsa-with-sha2(3) 1 } 213 When SHA-256 is used, the OID is: 215 dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 216 country(16) us(840) organization(1) gov(101) csor(3) 217 algorithms(4) id-dsa-with-sha2(3) 2 } 219 The(3072, 256) DSA key pair provides 128 bits of security 220 and provides the most security among all the four sizes of 221 DSA key pairs. More information on security strength 222 assessments of DSA and other cryptographic algorithms can 223 be found in [SP 800-57]. A digital signature algorithm has 224 the same security strength as its asymmetric key algorithm 225 like DSA or ECDSA only if its hashing algorithm has at 226 least the same security strength as the asymmetric key 227 algorithm. Therefore, a 128-bit security strength hashing 228 algorithm which is SHA-256 will be sufficient to build a 229 128-bit security strength DSA digital signature algorithm 230 when a DSA key pair of the size (3072, 256) is used. 231 Therefore, it is only needed to specify DSA with SHA-224 232 and SHA-256 because SHA-256 provides sufficient security for 233 using with any DSA key pair of any of the four size 234 choices. More information on security strengths of the 235 hash functions SHAs specified in [FIPS 180-3] and the 236 digital signature algorithms specified in [FIPS 186-3] can 237 be found in [SP 800-107] and [SP 800-57]. 239 When the id-dsa-with-sha224 or id-dsa-with-sha256 240 algorithm identifier appears in the algorithm field as an 241 AlgorithmIdentifier, the encoding SHALL omit the 242 parameters field. That is, the AlgorithmIdentifier SHALL 243 be a SEQUENCE of one component, the OID id-dsa-with-sha224 244 or id-dsa-with-sha256. 246 Encoding rules for DSA signature values are specified in 247 [RFC 3279]. For completeness, this information is repeated 248 below: 250 When signing, the DSA algorithm generates two values 251 commonly referred to as r and s. To easily transfer these 252 two values as one signature, they SHALL be ASN.1 encoded 253 using the following ASN.1 structure: 255 Dss-Sig-Value ::= SEQUENCE { 256 r INTEGER, 257 s INTEGER } 259 The DSA parameters in the subjectPublicKeyInfo field of 260 the certificate of the issuer SHALL apply to the 261 verification of the signature. 263 3.2. ECDSA Signature Algorithm 265 The Elliptic Curve Digital Signature Algorithm (ECDSA) is 266 defined in, "Public Key Cryptography for the Financial 267 Services Industry: The Elliptic Curve Digital Signature 268 Standard (ECDSA)" [X9.62]. [X9.62] provides alternative 269 mechanisms for specifying the hash algorithm used in the 270 signature generation process. Three methods are specified 271 in that document. 273 1) The signature OID may explicitly identify the hash 274 algorithm, as specified in Section 3.2.1 below. 276 2) The signature OID may specify that the signer used the 277 recommended hash algorithm for a given key size, as 278 described in Section 3.2.2. A verifier infers from the 279 size of the public key which hash algorithm was used. 281 3) The signature OID may indicate that the hash algorithm 282 is specified as a parameter of the signature OID. The 283 verifier identifies the appropriate hash algorithm 284 according to the hash algorithm OID in the parameters 285 field. The hash algorithm must be one of the SHA-2 hash 286 algorithms. 288 Conforming CA implementations MUST specify the hash 289 algorithm explicitly, using the OIDs specified in Section 290 3.2.1, when encoding ECDSA/SHA-2 signatures in 291 certificates and CRLs. 293 Conforming client implementations that process ECDSA 294 signatures with any of the SHA-2 hash algorithms when 295 processing certificates and CRLs MUST recognize the 296 corresponding OIDs specified in Section 3.2.1. Conforming 297 client implementations MAY also recognize the signature 298 OIDs specified in Sections 3.2.2 and 3.2.3. 300 Encoding rules for ECDSA signature values are specified in 301 [RFC 3279]. For completeness, this information is repeated 302 below: 304 When signing, the ECDSA algorithm generates two values 305 commonly referred to as r and s. To easily transfer these 306 two values as one signature, they MUST be ASN.1 encoded 307 using the following ASN.1 structure: 309 Ecdsa-Sig-Value ::= SEQUENCE { 310 r INTEGER, 311 s INTEGER } 313 The elliptic curve parameters in the subjectPublicKeyInfo 314 field of the certificate of the issuer MUST be applied to 315 the verification of the signature. The 316 subjectPublicKeyInfo field must be compliant with 317 requirements for Subject Public Key Information field in 318 [Elliptic Curve]. 320 3.2.1. ECDSA with SHA-2 Hash Algorithms 322 The ASN.1 OIDs used to specify that an ECDSA signature was 323 generated using SHA224, SHA256, SHA384 or SHA 512 324 respectively: 326 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 327 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } 329 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 330 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 332 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 333 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 335 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 336 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 338 When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with- 339 SHA384 or ecdsa-with-SHA512 algorithm identifier appears 340 in the algorithm field as an AlgorithmIdentifier, the 341 encoding MUST omit the parameters field. That is, the 342 AlgorithmIdentifier SHALL be a SEQUENCE of one component: 343 the OID: ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with- 344 SHA384 or ecdsa-with-SHA512. 346 3.2.2. ECDSA with Recommended Hash Algorithm 348 The following object identifier identifies the hash 349 function to be used for message digesting implicitly, 350 based on the size of the signer's public key: 352 ecdsa-with-Recommended OBJECT IDENTIFIER ::= { iso(1) 353 member-body(2) us(840) ansi-X9-62(10045) signatures(4) 354 recommended(2) } 356 The recommended hash functions are given in [X9.62], and 357 are determined as follows. Among the hash functions SHA-1, 358 SHA-224, SHA-256, SHA-384, SHA-512, the recommended one 359 has the largest bit size that does not require bit 360 truncation during the signing process. Bit truncation 361 occurs when the hash output bit-length is greater than the 362 bit length of n, the order of the base point G. (Note: 363 even if bit truncation does not occur, modular reduction 364 can occur.) 366 Conforming CA implementations MUST NOT specify the ecdsa- 367 with-Recommended OID when encoding certificates and CRLs. 368 To maximize interoperability, conforming client 369 implementations MAY recognize the ecdsa-with-Recommended 370 OID when processing certificates and CRLs. 372 3.2.3. ECDSA with Specified Hash Algorithm 374 The following object identifier identifies the hash 375 function to be used for message digesting is the one 376 specified in the parameters field of the algorithm 377 identifier: 379 ecdsa-with-Specified OBJECT IDENTIFIER ::= { iso(1) 380 member-body(2) us(840) ansi-X9-62(10045) signatures(4) 381 ecdsa-with-SHA2(3) } 383 For signatures generated using one of the SHA-2 hash 384 algorithms, the parameters field would contain the 385 appropriate OID from Section 2. 387 Conforming CA implementations MUST NOT specify the ecdsa- 388 with-Specified OID when encoding certificates and CRLs. 389 To maximize interoperability, conforming client 390 implementations MAY recognize the ecdsa-with-Specified OID 391 when processing certificates and CRLs. 393 4. ASN.1 Module 395 DEFINITIONS EXPLICIT TAGS ::= 397 BEGIN 399 -- EXPORTS ALL -- 400 -- All types and values defined in this module are 401 -- exported for use in other ASN.1 modules. 403 IMPORTS 405 NONE 406 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 407 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 408 hashalgs(2) 4 } 410 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 411 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 412 hashalgs(2) 1 } 414 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 415 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 416 hashalgs(2) 2 } 418 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 419 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 420 hashalgs(2) 3 } 422 -- 423 -- ECDSA Signatures with SHA-2 Hashes, from X9.62 424 -- 426 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 427 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } 429 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 430 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 432 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 433 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 435 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 436 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 438 ecdsa-with-Recommended OBJECT IDENTIFIER ::= { iso(1) 439 member-body(2) us(840) ansi-X9-62(10045) signatures(4) 440 recommended(2) } 442 ecdsa-with-Specified OBJECT IDENTIFIER ::= { iso(1) 443 member-body(2) us(840) ansi-X9-62(10045) signatures(4) 444 ecdsa-with-SHA2(3) } 446 -- 447 -- DSA with SHA-224 and SHA-256 signature algorithms 448 -- 449 dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 450 country(16) us(840) organization(1) gov(101) csor(3) 451 algorithms(4) id-dsa-with-sha2(3) 1 } 453 dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 454 country(16) us(840) organization(1) gov(101) csor(3) 455 algorithms(4) id-dsa-with-sha2(3) 2 } 457 END -- Definitions 459 5. Security Considerations 461 This specification supplements [RFC 3279]. The Security 462 Considerations section of that document applies, but is 463 specific to the RSA algorithm and this document covers the 464 DSA and ECDSA algorithms and the associated 465 considerations. 467 The appropriate use of the hash functions in terms of the 468 algorithm strengths and expected time frames for secure 469 use as defined by NIST can be found in Special 470 Publications 800-78-1 [SP 800-78-1], 800-57 [SP 800-57] 471 and 800-107 [SP 800-107]. 473 For security reasons, in [FIPS 186-3] NIST recommends three 474 types of elliptic curves for use in conjunction with one of 475 the described hash functions: curves over prime fields, curves 476 over binary fields, and Koblitz curves (anomalous binary 477 curves). FIPS 186-3 provides a table listing the uses and 478 time periods for each algorithm and key size combinations 479 for various applications. For further details, see the 480 referenced document. 482 The one-way hash algorithms discussed in this document, 483 SHA-224, SHA-256, SHA-384, and SHA-512 each have a 484 recommended lifetime when used in combination with a 485 digital signature algorithm. NIST provides information on 486 the appropriate time periods for which each combination 487 should be used based upon the security needs of the 488 service and information being protected in NIST Special 489 Publication 800-57. A table outlines the year in which 490 NIST deems it is no longer safe to use specific 491 combinations of key lengths and algorithms of various 492 strengths for RSA, DSA, and ECDSA. NIST also provides 493 Recommendation for using NIST-approved hash algorithms in 494 the digital signature applications in [SP 800-107]. 496 The Special Publication 800-57 also discusses the "best 497 practices" for key management to be used by both 498 developers and system administrators. The document covers 499 the aspects of key management from algorithm selection and 500 key sizes with associated key usage period to key usage 501 (preventing key overlap), the compromise of keys and 502 keying material, and key destruction. Specific guidelines 503 are offered for key usage periods such as the lifetime of 504 a private signature key may be shorter than the lifetime 505 of the public verification key for practical applications. 506 The specification also provides recommendations on the 507 number of years various key types should be used such as 508 public and private signature keys, public and private 509 authentication keys, etc. 511 NIST Special Publication 800-78-1 also lists time frames 512 for the use of combined hash algorithms and digital 513 signature algorithms for specific key types, including the 515 O Personal Identity Verification (PIV) authentication 516 key, 517 O Card authentication key, 518 O Digital signature key, and 519 O Key management key. 521 Specific requirements on the PIV can be found in 522 [FIPS 201]. 524 The recommendation for the size of digital signatures and 525 key management keys is more restrictive than that of 526 authentication keys, because they are used to protect data 527 for longer periods of time. Therefore, the transition 528 dates to larger key sizes are earlier in general. 530 Guidelines for the protection of domain parameters, 531 initialization vectors (IVs), and per message secret 532 numbers for use with digital signature algorithms, DSA and 533 ECSDA are provided in [FIPS 186-3]. An assurance of 534 integrity should be obtained prior to using all keying 535 material for the generation of digital signatures using 536 DSA and ECDSA. Recommendation for Obtaining Assurances for 537 Digital Signature Applications can be found in [SP 800-89]. 538 The purpose of this is to ensure the keying material 539 is in the proper format, the domain parameters are valid, 540 the possession of the private key, the validity of the 541 public key, and that the request is coming from an 542 authorized source. 544 Algorithm implementations MUST follow the appropriate 545 specification to ensure the generation of secure keys. The 546 SHA-2 algorithms are fully defined in [FIPS 180-3]. FIPS 547 186-3 defines the requirements for the digital signature 548 standard specifying the requirements for both DSA and 549 ECDSA. ECDSA is fully specified in [X9.62]. 551 Certificate Authorities (CAs) that issue certificates 552 using the DSA and ECDSA algorithms for key generation 553 SHOULD adhere to the recommended security guidelines for 554 key management in the NIST Special Publication 800-57. A 555 CA should use the same size or greater hash function than 556 what is used when generating keys for subscriber signature 557 certificates. 559 6. References 561 6.1. Normative references: 563 [RFC 2119] Bradner, S., "Key Words for Use in RFCs to 564 Indicate Requirement Levels", RFC 2119, 565 March 1997. 567 [RFC 3279] Bassham, L., Polk, W., and R. Housley, 568 "Algorithms and Identifiers for the 569 Internet X.509 Public Key Infrastructure 570 Certificate and Certificate Revocation 571 List (CRL) Profile", RFC 3279, April 2002. 573 [RFC 5280] Cooper, D., Santesson, S., Farrell, S., 574 Boeyen, S., Housley, R., and Polk, W., 575 "Internet X.509 Public Key Infrastructure 576 Certificate and Certificate Revocation 577 List (CRL) Profile", RFC 5280, May 2008. 579 [X9.62] X9.62-2005, "Public Key Cryptography for 580 the Financial Services Industry: The 581 Elliptic Curve Digital Signature Standard 582 (ECDSA)", December, 2005. 584 [Elliptic Curve] Turner S., Brown D., Yiu K., Housley 585 R., and Polk W., "Elliptic Curve 586 Cryptography Subject Public Key 587 Information" draft-ietf-pkix-ecc- 588 subpubkeyinfo-05.txt (work in progress), 589 April 2008. 591 [FIPS 180-3] Federal Information Processing 592 Standards Publication (FIPS PUB) 180-3, 593 Secure Hash Standard (SHS), (draft) 594 June 2007. 596 [FIPS 186-3] Federal Information Processing 597 Standards Publication (FIPS PUB) 186-3, 598 Digital Signature Standard (DSS), (draft) 599 March 2006. 601 6.2. Informative references 603 [SP 800-107] Q. Dang, NIST, "Recommendation for 604 Applications Using Approved Hash 605 Algorithm",(draft) July 2007. 607 [SP 800-78-1] W. Timothy Polk, Donna, F. Dodson, 608 William E. Burr, NIST, "Cryptographic 609 Standards and Key Sizes for Personal 610 Identity Verification", August 2007. 612 [SP 800-57] Elaine Barker, William Barker, William E. 613 Burr, NIST, "Recommendation for Key 614 Management", August 2005. 616 [SP 800-89] Elaine Barker, NIST, "Recommendation for 617 Obtaining Assurances for Digital Signature 618 Applications", December 2006. 620 [RFC 4055] Schaad, J., Kaliski, B., and Housley, R., 621 "Additional Algorithms and Identifiers for 622 RSA Cryptography for use in the Internet 623 X. 509 Public Key Infrastructure 624 Certificate and Certificate Revocation 625 List (CRL) Profile", RFC 4055, June 2005. 627 [FIPS 201] Federal Information Processing Standards 628 Publication (FIPS PUB) 201, Personal 629 Identity Verification (PIV) of Federal 630 Employees and Contractors, 25 February 631 2005. 633 7. Authors' Addresses 635 Quynh Dang 636 NIST 637 100 Bureau Drive, Stop 8930 638 Gaithersburg, MD 20899-8930 639 USA 640 Email: quynh.dang@nist.gov 642 Stefan Santesson 643 Microsoft 644 Tuborg Boulevard 12 645 2900 Hellerup 646 Denmark 647 EMail: stefans@microsoft.com 649 Kathleen M. Moriarty 650 RSA, The Security Division of EMC 651 174 Middlesex Turnpike 652 Bedford, MA 01730 653 Email: kathleen.moriarty@rsa.com 655 Daniel R. L. Brown 656 Certicom Corp. 657 5520 Explorer Drive 658 Mississaug, ON L4W 5L1 659 Email: dbrown@certicom.com 661 Tim Polk 662 NIST 663 100 Bureau Drive, Stop 8930 664 Gaithersburg, MD 20899-8930 665 USA 666 Email: tim.polk@nist.gov 668 8. IANA Considerations 670 This document has no actions for IANA. 672 9. Intellectual Property 674 The IETF takes no position regarding the validity or scope 675 of any Intellectual Property Rights or other rights that 676 might be claimed to pertain to the implementation or use 677 of the technology described in this document or the extent 678 to which any license under such rights might or might not 679 be available; nor does it represent that it has made any 680 independent effort to identify any such rights. 681 Information on the procedures with respect to rights in 682 RFC documents can be found in BCP 78 and BCP 79. 684 Copies of IPR disclosures made to the IETF Secretariat and 685 any assurances of licenses to be made available, or the 686 result of an attempt made to obtain a general license or 687 permission for the use of such proprietary rights by 688 implementers or users of this specification can be 689 obtained from the IETF on-line IPR repository at 690 http://www.ietf.org/ipr. 692 The IETF invites any interested party to bring to its 693 attention any copyrights, patents or patent applications, 694 or other proprietary rights that may cover technology that 695 may be required to implement this standard. Please address 696 the information to the IETF at ietf-ipr@ietf.org. 698 10. Copyright Statement 700 Copyright (C) The IETF Trust (2008). 702 This document is subject to the rights, licenses and 703 restrictions contained in BCP 78, and except as set forth 704 therein, the authors retain all their rights. 706 This document and the information contained herein are provided 707 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 708 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 709 INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET 710 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 711 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 712 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 713 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 714 FITNESS FOR A PARTICULAR PURPOSE. 716 Expires December 2008.