idnits 2.17.00 (12 Aug 2021) /tmp/idnits3495/draft-ietf-pkix-sha2-dsa-ecdsa-06.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 1 longer page, the longest (page 14) being 59 lines 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 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 (March 6, 2009) is 4823 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-78-1' is defined on line 612, but no explicit reference was found in the text == Outdated reference: draft-ietf-pkix-ecc-subpubkeyinfo has been published as RFC 5480 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 180-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 186-3' Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 5 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 4 Intended Category: Standards Track K. Moriarty (RSA) 5 D. Brown (Certicom Corp.) 6 T. Polk (NIST) 7 March 6, 2009 8 Expires: September 6, 2009 10 Internet X.509 Public Key Infrastructure: 11 Additional Algorithms and Identifiers for DSA and ECDSA 12 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full 17 conformance with the provisions of BCP 78 and BCP 18 79. 20 Internet-Drafts are working documents of the 21 Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may 23 also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a 27 maximum of six months and may be updated, 28 replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts 30 as reference material or to cite them other than 31 as "work in progress". 33 The list of current Internet-Drafts can be 34 accessed at http://www.ietf.org/ietf/1id- 35 abstracts.txt 37 The list of Internet-Draft Shadow Directories can 38 be accessed at http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons 43 identified as the document authors. All rights 44 reserved. 46 This document is subject to BCP 78 and the IETF 47 Trust's Legal Provisions Relating to IETF 48 Documents 49 (http://trustee.ietf.org/license-info) in effect 50 on the date of publication of this document. 51 Please review these documents carefully, as they 52 describe your rights and restrictions with respect 53 to this document. 55 Abstract 57 This document supplements RFC 3279. It specifies 58 algorithm identifiers and ASN.1 encoding rules for 59 the Digital Signature Algorithm (DSA) and Elliptic 60 Curve Digital Signature Algorithm (ECDSA) digital 61 signatures when using SHA-224, SHA-256, SHA-384 or 62 SHA-512 as hashing algorithm. This specification 63 applies to the Internet X.509 Public Key 64 Infrastructure (PKI) when digital signatures are 65 used to sign certificates and certificate 66 revocation lists (CRLs). 68 The key words "MUST", "MUST NOT", "REQUIRED", 69 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 70 "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in 72 [RFC 2119]. 74 Table of Contents 76 1. Introduction.............................................3 77 2. One-way Hash Functions...................................3 78 3. Signature Algorithms.....................................4 79 3.1 DSA Signature Algorithm................................5 80 3.2 ECDSA Signature Algorithm..............................7 81 4. ASN.1 Module.............................................8 82 5. Security Considerations.................................10 83 6. References..............................................12 84 6.1 Normative references:...............................12 85 6.2 Informative references:.............................13 86 7. Authors' Addresses......................................14 87 8. IANA Considerations.....................................15 89 1. Introduction 91 This specification supplements [RFC 3279], 92 "Algorithms and Identifiers for the Internet X.509 93 Public Key Infrastructure Certificate and 94 Certificate Revocation List (CRL) Profile" and 95 extends the list of algorithms defined for use in 96 the Internet PKI. This document specifies 97 algorithm identifiers and ASN.1 [X.690] encoding 98 rules for DSA and ECDSA digital signatures in 99 certificates and CRLs when using one of the SHA2 100 hash algorithms (SHA-224, SHA-256, SHA-384, and 101 SHA-512) as the hash algorithm. 103 This specification defines the contents of the 104 signatureAlgorithm, signatureValue and signature 105 fields within Internet X.509 certificates and CRLs 106 when these objects are signed using DSA or ECDSA 107 with a SHA2 hash algorithm. These fields are more 108 fully described in [RFC 5280]. 110 This document profiles material presented in the 111 "Secure Hash Standard" [FIPS 180-3], "Public Key 112 Cryptography for the Financial Services Industry: 113 The Elliptic Curve Digital Signature Standard 114 (ECDSA)" [X9.62], and the "Digital Signature 115 Standard" [FIPS 186-3]. 117 Algorithm identifiers and encoding rules for RSA, 118 DSA and ECDSA when used with SHA-1 are specified 119 in [RFC 3279]. Algorithm identifiers and encoding 120 rules for RSA when used with SHA2 hash algorithms 121 are specified in [RFC 4055]. 123 2. One-way Hash Functions 125 This section identifies four additional hash 126 algorithms for use with DSA and ECDSA in the 127 Internet X.509 certificate and CRL profile [RFC 128 5280]. 130 SHA-224, SHA-256, SHA-384, and SHA-512 produce a 131 224-bit, 256-bit, 384-bit and 512-bit "hash" of 132 the input respectively and are fully described in 133 the Federal Information Processing Standard 180-3 134 [FIPS 180-3]. 136 The listed one-way hash functions are identified 137 by the following object identifiers (OIDs): 139 id-sha224 OBJECT IDENTIFIER ::= { joint- 140 iso-itu-t(2) country(16) us(840) 141 organization(1) gov(101) csor(3) 142 nistalgorithm(4) hashalgs(2) 4 } 144 id-sha256 OBJECT IDENTIFIER ::= { joint- 145 iso-itu-t(2) country(16) us(840) 146 organization(1) gov(101) csor(3) 147 nistalgorithm(4) hashalgs(2) 1 } 149 id-sha384 OBJECT IDENTIFIER ::= { joint- 150 iso-itu-t(2) country(16) us(840) 151 organization(1) gov(101) csor(3) 152 nistalgorithm(4) hashalgs(2) 2 } 154 id-sha512 OBJECT IDENTIFIER ::= { joint- 155 iso-itu-t(2) country(16) us(840) 156 organization(1) gov(101) csor(3) 157 nistalgorithm(4) hashalgs(2) 3 } 159 When one of these OIDs appears in an 160 AlgorithmIdentifier, all implementations MUST 161 accept both NULL and absent parameters as legal 162 and equivalent encodings. 164 3. Signature Algorithms 166 Certificates and CRLs conforming to [RFC 5280] may 167 be signed with any public key signature algorithm. 168 The certificate or CRL indicates the algorithm 169 through an identifier, which appears in the 170 signatureAlgorithm field within the Certificate or 171 CertificateList. This algorithm identifier is an 172 OID and has optionally associated parameters. This 173 section denotes algorithm identifiers and 174 parameters that MUST be used in the 175 signatureAlgorithm field in a Certificate or 176 CertificateList. 178 Signature algorithms are always used in 179 conjunction with a one-way hash function. This 180 section identifies OIDs for DSA and ECDSA with 181 SHA-224, SHA-256, SHA-384, and SHA-512. The 182 contents of the parameters component for each 183 signature algorithm vary; details are provided for 184 each algorithm. 186 The data to be signed (e.g., the one-way hash 187 function output value) is formatted for the 188 signature algorithm to be used. Then, a private 189 key operation (e.g., DSA encryption) is performed 190 to generate the signature value. This signature 191 value is then ASN.1 encoded as a BIT STRING and 192 included in the Certificate or CertificateList in 193 the signature field. More detail on how digital 194 signatures are generated can be found in [FIPS 195 186-3]. 197 Entities that validate DSA signatures MUST support 198 SHA-224 and SHA-256. Entities that validate ECDSA 199 signatures MUST support SHA-224 and SHA-256 and 200 should support SHA-384 and SHA-512. 202 3.1 DSA Signature Algorithm 204 The DSA is defined in the Digital Signature 205 Standard (DSS) [FIPS 186-3]. DSA was developed by 206 the U.S. Government, and can be used in 207 conjunction with a SHA2 one-way hash function such 208 as SHA-224 or SHA-256. DSA is fully described in 209 [FIPS 186-3]. 211 [FIPS 186-3] specifies four size-choices for a DSA 212 key pair of the form (public key size, private key 213 size) in bits. The four choices are (1024, 160), 214 (2048, 224), (2048, 256), and (3072, 256). More 215 information can be found in [FIPS 186-3]. For the 216 remainder of this specification, each and every 217 key pair of the DSA key pairs is referred to by 218 the size of its public key. 220 DSA key pairs of 1024 and 2048 bits may be used 221 with SHA-224. DSA key pairs of any of the four 222 sizes may use SHA-256. The following are the OIDs 223 of the DSA digital signature algorithm when used 224 with SHA-224 or SHA-256. 226 When SHA-224 is used, the OID is: 228 id-dsa-with-sha224 OBJECT IDENTIFIER ::= { 229 joint-iso-ccitt(2) country(16) us(840) 230 organization(1) gov(101) csor(3) algorithms(4) 231 id-dsa-with-sha2(3) 1 }. 233 When SHA-256 is used, the OID is: 235 id-dsa-with-sha256 OBJECT IDENTIFIER ::= { 236 joint-iso-ccitt(2) country(16) us(840) 237 organization(1) gov(101) csor(3) algorithms(4) 238 id-dsa-with-sha2(3) 2 }. 240 The DSA key pair of 3072 bits provides 128 bits of 241 security and provides the most security among all 242 the four sizes of DSA key pairs. More information 243 on security strength assessments of DSA and other 244 cryptographic algorithms can be found in [SP 800- 245 57]. A digital signature algorithm has the same 246 security strength as its asymmetric key algorithm 247 like DSA or ECDSA only if its hashing algorithm 248 has at least the same security strength as the 249 asymmetric key algorithm. Therefore, a 128-bit 250 security strength hashing algorithm which is SHA- 251 256 will be sufficient to build a 128-bit security 252 strength DSA digital signature algorithm when the 253 DSA key pair of 3072 bits is used. Therefore, it 254 is only needed to specify DSA with SHA-224 and 255 SHA-256 because SHA-256 provides sufficient 256 security for using with any DSA key pair of any of 257 the four size choices. More information on 258 security strengths of the hash functions SHAs 259 specified in [FIPS 180-3] and the digital 260 signature algorithms specified in [FIPS 186-3] can 261 be found in [SP 800-107] and [SP 800-57]. 263 When the id-dsa-with-sha224 or id-dsa-with-sha256 264 algorithm identifier appears in the algorithm 265 field as an AlgorithmIdentifier, the encoding 266 SHALL omit the parameters field. That is, the 267 AlgorithmIdentifier SHALL be a SEQUENCE of one 268 component, the OID id-dsa-with-sha224 or id-dsa- 269 with-sha256. 271 Encoding rules for DSA signature values are 272 specified in [RFC 3279]. For completeness, this 273 information is repeated below: 275 When signing, the DSA algorithm generates two 276 values commonly referred to as r and s. To easily 277 transfer these two values as one signature, they 278 SHALL be ASN.1 encoded using the following ASN.1 279 structure: 281 Dss-Sig-Value ::= SEQUENCE { 282 r INTEGER, 283 s INTEGER 284 }. 286 The DSA parameters in the subjectPublicKeyInfo 287 field of the certificate of the issuer SHALL apply 288 to the verification of the signature. 290 3.2 ECDSA Signature Algorithm 292 The Elliptic Curve Digital Signature Algorithm 293 (ECDSA) is defined in, "Public Key Cryptography 294 for the Financial Services Industry: The Elliptic 295 Curve Digital Signature Standard (ECDSA)" [X9.62]. 296 The ASN.1 OIDs used to specify that an ECDSA 297 signature was generated using SHA-224, SHA-256, 298 SHA-384 or SHA-512 are respectively: 300 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { 301 iso(1) member-body(2) us(840) ansi-X9- 302 62(10045) signatures(4) ecdsa-with-SHA2(3) 1 303 } 305 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 306 iso(1) member-body(2) us(840) ansi-X9- 307 62(10045) signatures(4) ecdsa-with-SHA2(3) 2 308 } 310 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { 311 iso(1) member-body(2) us(840) ansi-X9- 312 62(10045) signatures(4) ecdsa-with-SHA2(3) 3 313 } 315 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { 316 iso(1) member-body(2) us(840) ansi-X9- 317 62(10045) signatures(4) ecdsa-with-SHA2(3) 4 318 } 320 When the ecdsa-with-SHA224, ecdsa-with-SHA256, 321 ecdsa-with-SHA384 or ecdsa-with-SHA512 algorithm 322 identifier appears in the algorithm field as an 323 AlgorithmIdentifier, the encoding MUST omit the 324 parameters field. That is, the AlgorithmIdentifier 325 SHALL be a SEQUENCE of one component, the OID 326 ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with- 327 SHA384 or ecdsa-with-SHA512. 329 Conforming CA implementations MUST specify the 330 hash algorithm explicitly, using the OIDs 331 specified above, when encoding ECDSA/SHA2 332 signatures in certificates and CRLs. 334 Conforming client implementations that process 335 ECDSA signatures with any of the SHA-2 hash 336 algorithms when processing certificates and CRLs 337 MUST recognize the corresponding OIDs specified 338 above. 340 [X9.62] has defined additional OIDs for the ECDSA 341 signature algorithm. 343 Encoding rules for ECDSA signature values are 344 specified in [RFC 3279]. For completeness, this 345 information is repeated below: 347 When signing, the ECDSA algorithm generates two 348 values commonly referred to as r and s. To easily 349 transfer these two values as one signature, they 350 MUST be ASN.1 encoded using the following ASN.1 351 structure: 353 Ecdsa-Sig-Value ::= SEQUENCE { 354 r INTEGER, 355 s INTEGER 356 }. 358 The elliptic curve parameters in the 359 subjectPublicKeyInfo field of the certificate of 360 the issuer MUST be applied to the verification of 361 the signature. The subjectPublicKeyInfo field must 362 be compliant with requirements for Subject Public 363 Key Information field in [Elliptic]. 365 4. ASN.1 Module 367 DEFINITIONS EXPLICIT TAGS ::= 369 BEGIN 371 -- EXPORTS ALL -- 372 -- All types and values defined in this module are 373 -- exported for use in other ASN.1 modules. 375 IMPORTS 377 NONE 379 id-sha224 OBJECT IDENTIFIER ::= { joint- 380 iso-itu-t(2) country(16) us(840) 381 organization(1) gov(101) csor(3) 382 nistalgorithm(4) hashalgs(2) 4 } 384 id-sha256 OBJECT IDENTIFIER ::= { joint- 385 iso-itu-t(2) country(16) us(840) 386 organization(1) gov(101) csor(3) 387 nistalgorithm(4) hashalgs(2) 1 } 389 id-sha384 OBJECT IDENTIFIER ::= { joint- 390 iso-itu-t(2) country(16) us(840) 391 organization(1) gov(101) csor(3) 392 nistalgorithm(4) hashalgs(2) 2 } 394 id-sha512 OBJECT IDENTIFIER ::= { joint- 395 iso-itu-t(2) country(16) us(840) 396 organization(1) gov(101) csor(3) 397 nistalgorithm(4) hashalgs(2) 3 } 399 -- 400 --DSA with SHA-224 and SHA-256 signature algorithms 401 -- 403 id-dsa-with-sha224 OBJECT IDENTIFIER ::= { 404 joint-iso-ccitt(2) country(16) us(840) 405 organization(1) gov(101) csor(3) algorithms(4) 406 id-dsa-with-sha2(3) 1 } 408 id-dsa-with-sha256 OBJECT IDENTIFIER ::= { 409 joint-iso-ccitt(2) country(16) us(840) 410 organization(1) gov(101) csor(3) algorithms(4) 411 id-dsa-with-sha2(3) 2 } 413 -- 414 --ECDSA Signatures with SHA-2 Hashes, from X9.62 415 -- 417 ecdsa-with-SHA224 ::= { iso(1) member- 418 body(2) us(840) ansi-X9-62(10045) 419 signatures(4) ecdsa-with-SHA2(3) 1 } 421 ecdsa-with-SHA256 ::= { iso(1) member- 422 body(2) us(840) ansi-X9-62(10045) 423 signatures(4) ecdsa-with-SHA2(3) 2 } 424 ecdsa-with-SHA384 ::= { iso(1) member- 425 body(2) us(840) ansi-X9-62(10045) 426 signatures(4) ecdsa-with-SHA2(3) 3 } 428 ecdsa-with-SHA512 ::= { iso(1) member- 429 body(2) us(840) ansi-X9-62(10045) 430 signatures(4) ecdsa-with-SHA2(3) 4 } 432 END -- Definitions 434 5. Security Considerations 436 This specification supplements [RFC 3279]. This 437 document covers the DSA and ECDSA algorithms with 438 SHA2 hash functions and the associated 439 considerations. 441 The appropriate use of the hash functions in terms 442 of the algorithm strengths and expected time 443 frames for secure use as defined by NIST can be 444 found in Special Publications (SPs) 800-78-1 [SP 445 800-78-1], 800-57 [SP 800-57] and 800-107 [SP 800- 446 107]. 448 FIPS 186-3 fully specifies the DSA digital 449 signature algorithm and defines security 450 requirements for the DSA and ECDSA digital 451 signature algorithms; details can be found in 452 [FIPS 186-3]. ECDSA is fully specified in [X9.62]. 453 [FIPS 186-3] also specifies three types of 454 elliptic curves for use in conjunction with one of 455 the described hash functions: curves over prime 456 fields, curves over binary fields, and Koblitz 457 curves (anomalous binary curves). FIPS 186-3 458 provides a table listing the uses and time periods 459 for each algorithm and key size combinations for 460 various applications. The DSA and ECDSA private 461 keys must be generated from pseudorandom functions 462 whose security strengths meet or exceed the 463 desired security strengths for the digital 464 signature algorithms. Guidelines on building these 465 NIST-approved pseudorandom functions can be found 466 in SP 800-90 [SP 800-90]. The hash functions must 467 meet or exceed the desired security strengths of 468 the digital signature algorithms. More guidelines 469 can be found in SP 800-57 [SP 800-57] and SP 800- 470 107 [SP 800-107]. 472 The one-way hash algorithms discussed in this 473 document, SHA-224, SHA-256, SHA-384, and SHA-512 474 each have a recommended lifetime when used in 475 combination with a digital signature algorithm. 476 NIST provides information on the appropriate time 477 periods for which each combination should be used 478 based upon the security needs of the service and 479 information being protected in NIST Special 480 Publication 800-57. A table outlines the year in 481 which NIST deems it is no longer safe to use 482 specific combinations of key lengths and 483 algorithms of various strengths for RSA, DSA, and 484 ECDSA. NIST also provides Recommendation for using 485 NIST-approved hash algorithms in the digital 486 signature applications in [SP 800-107]. 488 The Special Publication 800-57 also provides 489 guidelines for key management to be used by both 490 developers and system administrators. The document 491 covers the aspects of key management from 492 algorithm selection and key sizes with associated 493 key usage period to key usage (preventing key 494 overlap), the compromise of keys and keying 495 material, and key destruction. Specific guidelines 496 are offered for key usage periods such as the 497 lifetime of a private signature key may be shorter 498 than the lifetime of the public verification key 499 for practical applications. The specification also 500 provides recommendations on the number of years 501 various key types should be used such as public 502 and private signature keys, public and private 503 authentication keys, etc. 505 NIST Special Publication 800-78-1 also lists time 506 frames for the use of combined hash algorithms and 507 digital signature algorithms for specific key 508 types, but differentiates some security 509 requirements between digital signature and 510 authentication keys. The recommendation for the 511 size of digital signature keys and key management 512 keys is more restrictive than that of 513 authentication keys, because they are used to 514 protect data for longer periods of time. 515 Therefore, the transition dates to larger key 516 sizes are earlier in general. Guidelines for the 517 protection of domain parameters, initialization 518 vectors (IVs), and per message secret numbers for 519 use with digital signature algorithms, DSA and 520 ECSDA are provided in [FIPS 186-3]. An assurance 521 of integrity should be obtained prior to using all 522 keying material for the generation of digital 523 signatures using DSA and ECDSA. Recommendation for 524 Obtaining Assurances for Digital Signature 525 Applications can be found in [SP 800-89]. The 526 purpose of this is to ensure the keying material 527 is in the proper format, the domain parameters are 528 valid, the possession of the private key, the 529 validity of the public key, and that the request 530 is coming from an authorized source. 532 Certificate Authorities (CAs) that issue 533 certificates using the DSA and ECDSA algorithms 534 for key generation SHOULD adhere to the 535 recommended security guidelines for key management 536 in the NIST Special Publication 800-57. When 537 signing a digital signature certificate, a CA 538 should use the same or greater size hash function 539 than the hash function in the digital signature 540 algorithm in the certificate. 542 6. References 544 6.1 Normative References 546 [RFC 2119] Bradner, S., "Key Words for 547 Use in RFCs to Indicate 548 Requirement Levels", RFC 2119, 549 March 1997. 551 [RFC 3279] Bassham, L., Polk, W., and R. 552 Housley, "Algorithms and 553 Identifiers for the Internet 554 X.509 Public Key 555 Infrastructure Certificate and 556 Certificate Revocation List 557 (CRL) Profile", RFC 3279, 558 April 2002. 560 [RFC 5280] Cooper, D., Santesson, S., 561 Farrell, S., Boeyen, S. 562 Housley, R., and W. Polk, 563 "Internet X.509 Public Key 564 Infrastructure Certificate and 565 Certificate Revocation List 566 (CRL) Profile", RFC 5280, May 567 2008. 569 [X9.62] X9.62-2005, "Public Key 570 Cryptography for the Financial 571 Services Industry: The 572 Elliptic Curve Digital 573 Signature Standard (ECDSA)", 574 November, 2005. 576 [Elliptic] Turner S., Brown D., Yiu K., 577 Housley R., and Polk W., 578 "Elliptic Curve Cryptography 579 Subject Public Key 580 Information" draft-ietf-pkix- 581 ecc-subpubkeyinfo-11.txt (work 582 in progress), December 2008. 584 [FIPS 180-3] Federal Information Processing 585 Standards Publication (FIPS 586 PUB) 180-3, Secure Hash 587 Standard (SHS), October 2008. 589 [FIPS 186-3] Federal Information Processing 590 Standards Publication (FIPS 591 PUB) 186-3, Digital Signature 592 Standard (DSS), (draft) 593 November 2008. 595 [X.690] ITU-T Recommendation X.660 596 Information Technology - 597 ASN.1 encoding rules: 598 Specification of Basic 599 Encoding Rules (BER), 600 Canonical Encoding Rules (CER) 601 and Distinguished Encoding 602 Rules (DER), 1997. 604 6.2 Informative References 606 [SP 800-107] Quynh Dang, NIST, 607 "Recommendation for 608 Applications Using Approved 609 Hash Algorithms", February 610 2009. 612 [SP 800-78-1] W. Timothy Polk, Donna, F. 613 Dodson, William E. Burr, NIST, 614 "Cryptographic Standards and 615 Key Sizes for Personal 616 Identity Verification", August 617 2007. 619 [SP 800-57] Elaine Barker, William Barker, 620 William E. Burr, NIST, 621 "Recommendation for Key 622 Management", August 2005. 624 [SP 800-89] Elaine Barker, NIST, 625 "Recommendation for Obtaining 626 Assurances for Digital 627 Signature Applications", 628 November 2006. 630 [SP 800-90] Elaine Barker, John Kelsey, 631 NIST, ''Recommendation for 632 Random Number Generation Using 633 Deterministic Random Bit 634 Generators'', March 2007. 636 [RFC 4055] Schaad, J., Kaliski, B., and 637 Housley, R., "Additional 638 Algorithms and Identifiers for 639 RSA Cryptography for use in 640 the Internet X. 509 Public Key 641 Infrastructure Certificate and 642 Certificate Revocation List 643 (CRL) Profile", RFC 4055, June 644 2005. 646 7. Authors' Addresses 648 Quynh Dang 650 NIST 651 100 Bureau Drive, Stop 8930 652 Gaithersburg, MD 20899-8930 653 USA 655 Email: quynh.dang@nist.gov 657 Kathleen M. Moriarty 659 RSA, The Security Division of EMC 660 174 Middlesex Turnpike 661 Bedford, MA 01730 663 Email: Moriarty_Kathleen@emc.com 664 Stefan Santesson 666 EMail: stefans@exmsft.com 668 Daniel R. L. Brown 670 Certicom Corp. 671 5520 Explorer Drive 672 Mississaug, ON L4W 5L1 674 Email: dbrown@certicom.com 676 Tim Polk 678 NIST 679 100 Bureau Drive, Stop 8930 680 Gaithersburg, MD 20899-8930 681 USA 683 Email: tim.polk@nist.gov 685 8. IANA Considerations 687 This document has no actions for IANA.