idnits 2.17.1 draft-ietf-pkix-sha2-dsa-ecdsa-05.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 547. 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 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 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 30, 2008) is 5657 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) -- 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 (~~), 1 warning (==), 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 (Microsoft) 3 Intended Category: Standards Track K. Moriarty (RSA) 4 D. Brown (Certicom Corp.) 5 Expires: April 30, 2009 T. Polk (NIST) 6 October 30, 2008 8 Internet X.509 Public Key Infrastructure: Additional 9 Algorithms and Identifiers for DSA and ECDSA 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents 15 that any applicable patent or other IPR claims of which he 16 or she is aware have been or will be disclosed, and any of 17 which he or she becomes aware will be disclosed, in 18 accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet 21 Engineering Task Force (IETF), its areas, and its working 22 groups. Note that other groups may also distribute working 23 documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of 26 six months and may be updated, replaced, or obsoleted by 27 other documents at any time. It is inappropriate to use 28 Internet-Drafts as reference material or to cite them other 29 than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be 35 accessed at http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document supplements RFC 3279. It specifies algorithm 44 identifiers and ASN.1 encoding rules for the Digital 45 Signature Algorithm (DSA) and Elliptic Curve Digital 46 Signature Algorithm (ECDSA) digital signatures when using 47 SHA-224, SHA-256, SHA-384 or SHA-512 as hashing algorithm. 48 This specification applies to the Internet X.509 Public Key 49 Infrastructure (PKI) when digital signatures are used to 50 sign certificates and certificate revocation lists (CRLs). 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 53 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 54 and "OPTIONAL" in this document are to be interpreted as 55 described in [RFC 2119]. 57 Table of Contents 59 1. Introduction...................................................2 60 2. One-way Hash Functions.........................................3 61 3. Signature Algorithms...........................................4 62 3.1 DSA Signature Algorithm..................................4 63 3.2 ECDSA Signature Algorithm................................6 64 4. ASN.1 Module...................................................7 65 5. Security Considerations........................................8 66 6. References....................................................10 67 6.1 Normative references:...................................10 68 6.2 Informative references..................................11 69 7. Authors' Addresses............................................11 70 8. IANA Considerations...........................................12 71 9. Intellectual Property.........................................12 72 10.Copyright Statement...........................................13 74 1. Introduction 76 This specification supplements [RFC 3279], "Algorithms and Identifiers 77 for the Internet X.509 Public Key Infrastructure Certificate and 78 Certificate Revocation List (CRL) Profile" and extends the list of 79 algorithms defined for use in the Internet PKI. This document specifies 80 algorithm identifiers and ASN.1 [X.660] encoding rules for DSA and ECDSA 81 digital signatures in certificates and CRLs when using one of the SHA-2 82 hash algorithms (SHA-224, SHA-256, SHA-384, and SHA-512) as the hash 83 algorithm. 85 This specification defines the contents of the signatureAlgorithm, 86 signatureValue and signature fields within Internet X.509 certificates 87 and CRLs when these objects are signed using DSA or ECDSA with a SHA-2 88 hash algorithm. These fields are more fully described in [RFC 5280]. 90 This document profiles material presented in the ''Secure Hash Standard 91 '' [FIPS 180-3], "Public Key Cryptography for the Financial Services 92 Industry: The Elliptic Curve Digital Signature Standard (ECDSA)" 93 [X9.62], and the ''Digital Signature Standard'' [FIPS 186-3]. 95 Algorithm identifiers and encoding rules for RSA, DSA and ECDSA when 96 used with SHA-1 are specified in [RFC 3279]. Algorithm identifiers and 97 encoding rules for RSA when used with SHA-2 are specified in [RFC 4055]. 99 2. One-way Hash Functions 101 This section identifies four additional hash algorithms for use with DSA 102 and ECDSA in the Internet X.509 certificate and CRL profile [RFC 5280]. 104 SHA-224, SHA-256, SHA-384, and SHA-512 produce a 224-bit, 256-bit, 384- 105 bit and 512-bit "hash" of the input respectively and are fully described 106 in the Federal Information Processing Standard 180-3 [FIPS 180-3]. 108 The listed one-way hash functions are identified by the following object 109 identifiers (OIDs): 111 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 112 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 113 4 } 115 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 116 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 117 1 } 119 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 120 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 121 2 } 123 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 124 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 125 3 } 127 When one of these OIDs appears in an AlgorithmIdentifier, all 128 implementations MUST accept both NULL and absent parameters as legal and 129 equivalent encodings. 131 3. Signature Algorithms 133 Certificates and CRLs conforming to [RFC 5280] may be signed with any 134 public key signature algorithm. The certificate or CRL indicates the 135 algorithm through an identifier, which appears in the signatureAlgorithm 136 field within the Certificate or CertificateList. This algorithm 137 identifier is an OID and has optionally associated parameters. This 138 section denotes algorithm identifiers and parameters that MUST be used 139 in the signatureAlgorithm field in a Certificate or CertificateList. 141 Signature algorithms are always used in conjunction with a one-way hash 142 function. This section identifies OIDs for DSA and ECDSA with SHA-224, 143 SHA-256, SHA-384, and SHA-512. The contents of the parameters component 144 for each signature algorithm vary; details are provided for each 145 algorithm. 147 The data to be signed (e.g., the one-way hash function output value) is 148 formatted for the signature algorithm to be used. Then, a private key 149 operation (e.g., DSA encryption) is performed to generate the signature 150 value. This signature value is then ASN.1 encoded as a BIT STRING and 151 included in the Certificate or CertificateList in the signature field. 152 More detail on how digital signatures are generated can be found in 153 [FIPS 186-3]. 155 Entities that validate DSA signatures MUST support SHA-224 and SHA-256. 156 Entities that validate ECDSA signatures MUST support SHA-224 and SHA-256 157 and should support SHA-384 and SHA-512. 159 3.1 DSA Signature Algorithm 161 The DSA is defined in the Digital Signature Standard (DSS) [FIPS 186-3]. 162 DSA was developed by the U.S. Government, and can be used in conjunction 163 with a SHA2 one-way hash function such as SHA-224 or SHA-256. DSA is 164 fully described in [FIPS 186-3]. 166 [FIPS 186-3] specifies four size-choices for a DSA key pair of the form 167 (public key size, private key size) in bits. The four choices are (1024, 168 160), (2048, 224), (2048, 256), and (3072, 256). More information can be 169 found in [FIPS 186-3]. For the remainder of this specification, each and 170 every key pair of the DSA key pairs is referred to by the size of its 171 public key. 173 DSA key pairs of 1024 and 2048 bits may be used with SHA-224. DSA key 174 pairs of any of the four sizes may use SHA-256. The following are the 175 OIDs of the DSA digital signature algorithm when used with SHA-224 or 176 SHA-256. 178 When SHA-224 is used, the OID is: 180 id-dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 181 country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) 182 id-dsa-with-sha2(3) 1 } 184 When SHA-256 is used, the OID is: 186 id-dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 187 country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) 188 id-dsa-with-sha2(3) 2 } 190 The(3072, 256) DSA key pair provides 128 bits of security and provides 191 the most security among all the four sizes of DSA key pairs. More 192 information on security strength assessments of DSA and other 193 cryptographic algorithms can be found in [SP 800-57]. A digital 194 signature algorithm has the same security strength as its asymmetric key 195 algorithm like DSA or ECDSA only if its hashing algorithm has at least 196 the same security strength as the asymmetric key algorithm. Therefore, a 197 128-bit security strength hashing algorithm which is SHA-256 will be 198 sufficient to build a 128-bit security strength DSA digital signature 199 algorithm when a DSA key pair of the size (3072, 256) is used. 200 Therefore, it is only needed to specify DSA with SHA-224 and SHA-256 201 because SHA-256 provides sufficient security for using with any DSA key 202 pair of any of the four size choices. More information on security 203 strengths of the hash functions SHAs specified in [FIPS 180-3] and the 204 digital signature algorithms specified in [FIPS 186-3] can be found in 205 [SP 800-107] and [SP 800-57]. 207 When the id-dsa-with-sha224 or id-dsa-with-sha256 algorithm identifier 208 appears in the algorithm field as an AlgorithmIdentifier, the encoding 209 SHALL omit the parameters field. That is, the AlgorithmIdentifier SHALL 210 be a SEQUENCE of one component, the OID id-dsa-with-sha224 or id-dsa- 211 with-sha256. 213 Encoding rules for DSA signature values are specified in [RFC 3279]. For 214 completeness, this information is repeated below: 216 When signing, the DSA algorithm generates two values commonly referred 217 to as r and s. To easily transfer these two values as one signature, 218 they SHALL be ASN.1 encoded using the following ASN.1 structure: 220 Dss-Sig-Value ::= SEQUENCE { 221 r INTEGER, 222 s INTEGER 223 } 225 The DSA parameters in the subjectPublicKeyInfo field of the certificate 226 of the issuer SHALL apply to the verification of the signature. 228 3.2 ECDSA Signature Algorithm 230 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in, 231 "Public Key Cryptography for the Financial Services Industry: The 232 Elliptic Curve Digital Signature Standard (ECDSA)" [X9.62]. The ASN.1 233 OIDs used to specify that an ECDSA signature was generated using SHA224, 234 SHA256, SHA384 or SHA 512 are respectively: 236 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 237 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } 239 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 240 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 242 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 243 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 245 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 246 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 248 When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384 or 249 ecdsa-with-SHA512 algorithm identifier appears in the algorithm field as 250 an AlgorithmIdentifier, the encoding MUST omit the parameters field. 251 That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, 252 the OID ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384 or 253 ecdsa-with-SHA512. 255 Conforming CA implementations MUST specify the hash algorithm 256 explicitly, using the OIDs specified above, when encoding ECDSA/SHA-2 257 signatures in certificates and CRLs. 259 Conforming client implementations that process ECDSA signatures with any 260 of the SHA-2 hash algorithms when processing certificates and CRLs MUST 261 recognize the corresponding OIDs specified above. 263 [X9.62] has defined additional OIDs for the ECDSA signature algorithm. 265 Encoding rules for ECDSA signature values are specified in [RFC 3279]. 266 For completeness, this information is repeated below: 268 When signing, the ECDSA algorithm generates two values commonly referred 269 to as r and s. To easily transfer these two values as one signature, 270 they MUST be ASN.1 encoded using the following ASN.1 structure: 272 Ecdsa-Sig-Value ::= SEQUENCE { 273 r INTEGER, 274 s INTEGER 275 } 277 The elliptic curve parameters in the subjectPublicKeyInfo field of the 278 certificate of the issuer MUST be applied to the verification of the 279 signature. The subjectPublicKeyInfo field must be compliant with 280 requirements for Subject Public Key Information field in [Elliptic 281 Curve]. 283 4. ASN.1 Module 285 DEFINITIONS EXPLICIT TAGS ::= 287 BEGIN 289 -- EXPORTS ALL -- 290 -- All types and values defined in this module are 291 -- exported for use in other ASN.1 modules. 293 IMPORTS 295 NONE 297 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 298 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 299 4 } 301 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 302 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 303 1 } 305 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 306 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 307 2 } 309 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 310 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 311 3 } 312 -- 313 -- DSA with SHA-224 and SHA-256 signature algorithms 314 -- 316 id-dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 317 country(16) us(840) organization(1) gov(101) csor(3) 318 algorithms(4) id-dsa-with-sha2(3) 1 } 320 id-dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 321 country(16) us(840) organization(1) gov(101) csor(3) 322 algorithms(4) id-dsa-with-sha2(3) 2 } 324 -- 325 -- ECDSA Signatures with SHA-2 Hashes, from X9.62 326 -- 328 ecdsa-with-SHA224 ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) 329 signatures(4) ecdsa-with-SHA2(3) 1 } 331 ecdsa-with-SHA256 ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) 332 signatures(4) ecdsa-with-SHA2(3) 2 } 334 ecdsa-with-SHA384 ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) 335 signatures(4) ecdsa-with-SHA2(3) 3 } 337 ecdsa-with-SHA512 ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) 338 signatures(4) ecdsa-with-SHA2(3) 4 } 340 END -- Definitions 342 5. Security Considerations 344 This specification supplements [RFC 3279]. This document covers the DSA 345 and ECDSA algorithms with SHA2 hash functions and the associated 346 considerations. 348 The appropriate use of the hash functions in terms of the algorithm 349 strengths and expected time frames for secure use as defined by NIST can 350 be found in Special Publications (SPs) 800-78-1 [SP 800-78-1], 800-57 351 [SP 800-57] and 800-107 [SP 800-107]. 353 FIPS 186-3 fully specifies the DSA digital signature algorithm and 354 defines security requirements for the DSA and ECDSA digital signature 355 algorithms; details can be found in [FIPS 186-3]. ECDSA is fully 356 specified in [X9.62].[FIPS 186-3] also specifies three types of elliptic 357 curves for use in conjunction with one of the described hash functions: 358 curves over prime fields, curves over binary fields, and Koblitz curves 359 (anomalous binary curves). FIPS 186-3 provides a table listing the uses 360 and time periods for each algorithm and key size combinations for 361 various applications. The DSA and ECDSA private keys must be generated 362 from pseudorandom functions whose security strengths meet or exceed the 363 desired security strengths for the digital signature algorithms. 364 Guidelines on building these NIST-approved pseudorandom functions can be 365 found in SP 800-90 [SP 800-90]. The hash functions must meet or exceed 366 the desired security strengths of the digital signature algorithms. More 367 guidelines can be found in SP 800-57 [SP 800-57] and SP 800-107 [SP 800- 368 107]. 370 The one-way hash algorithms discussed in this document, SHA-224, SHA- 371 256, SHA-384, and SHA-512 each have a recommended lifetime when used in 372 combination with a digital signature algorithm. NIST provides 373 information on the appropriate time periods for which each combination 374 should be used based upon the security needs of the service and 375 information being protected in NIST Special Publication 800-57. A table 376 outlines the year in which NIST deems it is no longer safe to use 377 specific combinations of key lengths and algorithms of various strengths 378 for RSA, DSA, and ECDSA. NIST also provides Recommendation for using 379 NIST-approved hash algorithms in the digital signature applications in 380 [SP 800-107]. 382 The Special Publication 800-57 also provides guidelines for key 383 management to be used by both developers and system administrators. The 384 document covers the aspects of key management from algorithm selection 385 and key sizes with associated key usage period to key usage (preventing 386 key overlap), the compromise of keys and keying material, and key 387 destruction. Specific guidelines are offered for key usage periods such 388 as the lifetime of a private signature key may be shorter than the 389 lifetime of the public verification key for practical applications. The 390 specification also provides recommendations on the number of years 391 various key types should be used such as public and private signature 392 keys, public and private authentication keys, etc. 394 NIST Special Publication 800-78-1 also lists time frames for the use of 395 combined hash algorithms and digital signature algorithms for specific 396 key types, but differentiates some security requirements between digital 397 signature and authentication keys. 399 The recommendation for the size of digital signature keys and key 400 management keys is more restrictive than that of authentication keys, 401 because they are used to protect data for longer periods of time. 403 Therefore, the transition dates to larger key sizes are earlier in 404 general. 406 Guidelines for the protection of domain parameters, initialization 407 vectors (IVs), and per message secret numbers for use with digital 408 signature algorithms, DSA and ECSDA are provided in [FIPS 186-3]. An 409 assurance of integrity should be obtained prior to using all keying 410 material for the generation of digital signatures using DSA and ECDSA. 411 Recommendation for Obtaining Assurances for Digital Signature 412 Applications can be found in [SP 800-89]. The purpose of this is to 413 ensure the keying material is in the proper format, the domain 414 parameters are valid, the possession of the private key, the validity of 415 the public key, and that the request is coming from an authorized 416 source. 418 Certificate Authorities (CAs) that issue certificates using the DSA and 419 ECDSA algorithms for key generation SHOULD adhere to the recommended 420 security guidelines for key management in the NIST Special Publication 421 800-57. When signing a digital signature certificate, a CA should use 422 the same or greater size hash function than the hash function in the 423 digital signature algorithm in the certificate. 425 6. References 427 6.1 Normative references: 429 [RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate 430 Requirement Levels", RFC 2119, March 1997. 432 [RFC 3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 433 Identifiers for the Internet X.509 Public Key 434 Infrastructure Certificate and Certificate Revocation 435 List (CRL) Profile", RFC 3279, April 2002. 437 [RFC 5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. 438 Housley, R., and W. Polk, "Internet X.509 Public Key 439 Infrastructure Certificate and Certificate Revocation 440 List (CRL) Profile", RFC 5280, May 2008. 442 [X9.62] X9.62-2005, "Public Key Cryptography for the Financial 443 Services Industry: The Elliptic Curve Digital Signature 444 Standard (ECDSA)", November, 2005. 446 [Elliptic Curve]Turner S., Brown D., Yiu K., Housley R., and Polk W., 447 "Elliptic Curve Cryptography Subject Public Key 448 Information" draft-ietf-pkix-ecc-subpubkeyinfo-08.txt 449 (work in progress), September 2008. 451 [FIPS 180-3] Federal Information Processing Standards Publication 452 (FIPS PUB) 180-3, Secure Hash Standard (SHS), October 453 2008. 455 [FIPS 186-3] Federal Information Processing Standards Publication 456 (FIPS PUB) 186-3, Digital Signature Standard (DSS), 457 (draft) 13 March 2006. 459 6.2 Informative references 461 [SP 800-107] Q. Dang, NIST, "Recommendation for Applications Using 462 Approved Hash Algorithms", (draft) July 2008. 464 [SP 800-78-1] W. Timothy Polk, Donna, F. Dodson, William E. Burr, 465 NIST, "Cryptographic Standards and Key Sizes for 466 Personal Identity Verification", August 2007. 468 [SP 800-57] Elaine Barker, William Barker, William E. Burr, NIST, 469 "Recommendation for Key Management", August 2005. 471 [SP 800-89] Elaine Barker, NIST, "Recommendation for Obtaining 472 Assurances for Digital Signature Applications", 473 November 2006. 475 [SP 800-90] Elaine Barker, John Kelsey, NIST, ''Recommendation for 476 Random Number Generation Using Deterministic Random Bit 477 Generators'', March 2007. 479 [RFC 4055] Schaad, J., Kaliski, B., and Housley, R., "Additional 480 Algorithms and Identifiers for RSA Cryptography for use 481 in the Internet X. 509 Public Key Infrastructure 482 Certificate and Certificate Revocation List (CRL) 483 Profile", RFC 4055, June 2005. 485 7. Authors' Addresses 487 Quynh Dang 489 NIST 490 100 Bureau Drive, Stop 8930 491 Gaithersburg, MD 20899-8930 492 USA 494 Email: quynh.dang@nist.gov 495 Stefan Santesson 496 Microsoft 497 Tuborg Boulevard 12 498 2900 Hellerup 499 Denmark 500 EMail: stefans@microsoft.com 502 Kathleen M. Moriarty 503 RSA, The Security Division of EMC 504 174 Middlesex Turnpike 505 Bedford, MA 01730 506 Email: kathleen.moriarty@rsa.com 508 Daniel R. L. Brown 509 Certicom Corp. 510 5520 Explorer Drive 511 Mississaug, ON L4W 5L1 512 Email: dbrown@certicom.com 514 Tim Polk 515 NIST 516 100 Bureau Drive, Stop 8930 517 Gaithersburg, MD 20899-8930 518 USA 519 Email: tim.polk@nist.gov 521 8. IANA Considerations 523 This document has no actions for IANA. 525 9. Intellectual Property 527 The IETF takes no position regarding the validity or scope of any 528 Intellectual Property Rights or other rights that might be claimed to 529 pertain to the implementation or use of the technology described in this 530 document or the extent to which any license under such rights might or 531 might not be available; nor does it represent that it has made any 532 independent effort to identify any such rights. Information on the 533 procedures with respect to rights in RFC documents can be found in BCP 534 78 and BCP 79. 536 Copies of IPR disclosures made to the IETF Secretariat and any 537 assurances of licenses to be made available, or the result of an attempt 538 made to obtain a general license or permission for the use of such 539 proprietary rights by implementers or users of this specification can be 540 obtained from the IETF on-line IPR repository at 541 http://www.ietf.org/ipr. 543 The IETF invites any interested party to bring to its attention any 544 copyrights, patents or patent applications, or other proprietary rights 545 that may cover technology that may be required to implement this 546 standard. Please address the information to the IETF at ietf- 547 ipr@ietf.org. 549 10.Copyright Statement 551 Copyright (C) The IETF Trust (2008). 553 This document is subject to the rights, licenses and restrictions 554 contained in BCP 78, and except as set forth therein, the authors 555 retain all their rights. 557 This document and the information contained herein are provided on an 558 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 559 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 560 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 561 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 562 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 563 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.