idnits 2.17.1 draft-ietf-pkix-ecc-subpubkeyinfo-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 945. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 963. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 969. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC3279, but the abstract doesn't seem to directly say this. It does mention RFC3279 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3279, updated by this document, for RFC5378 checks: 2000-07-21) -- 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 (December 11, 2008) is 5587 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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. 'FIPS180-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' == Outdated reference: A later version (-10) exists of draft-ietf-pkix-sha2-dsa-ecdsa-05 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF PKIX WG Sean Turner, IECA 2 Internet Draft Daniel Brown, Certicom 3 Intended Status: Standard Track Kelvin Yiu, Microsoft 4 Updates: 3279 (once approved) Russ Housley, Vigil Security 5 Expires: June 11, 2009 Tim Polk, NIST 6 December 11, 2008 8 Elliptic Curve Cryptography Subject Public Key Information 9 draft-ietf-pkix-ecc-subpubkeyinfo-11.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on June 11, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document specifies the syntax and semantics for the Subject 43 Public Key Information field in certificates that support Elliptic 44 Curve Cryptography. This document updates Sections 2.3.5 and 5, and 45 the ASN.1 module of Algorithms and Identifiers for the Internet X.509 46 Public Key Infrastructure Certificate and Certificate Revocation List 47 (CRL) Profile, RFC 3279. 49 Table of Contents 51 1. Introduction...................................................2 52 1.1. Terminology...............................................3 53 2. Subject Public Key Information Fields..........................3 54 2.1. Elliptic Curve Cryptography Public Key Algorithm 55 Identifiers...............................................4 56 2.2. Subject Public Key........................................7 57 3. Key Usage Bits.................................................8 58 4. Security Considerations........................................9 59 5. ASN.1 Considerations..........................................11 60 6. IANA Considerations...........................................11 61 7. Acknowledgments...............................................12 62 8. References....................................................12 63 8.1. Normative References.....................................12 64 8.2. Informative References...................................13 65 Appendix A. ASN.1 Module.........................................13 67 1. Introduction 69 This document specifies the format of the subjectPublicKeyInfo field 70 in X.509 certificates [PKI] that use Elliptic Curve Cryptography 71 (ECC). It updates RFC 3279 [PKI-ALG]. This document specifies the 72 encoding formats for public keys used with the following ECC 73 algorithms: 75 o Elliptic Curve Digital Signature Algorithm (ECDSA); 77 o Elliptic Curve Diffie-Hellman (ECDH) family schemes; and 79 o Elliptic Curve Menezes-Qu-Vanstone (ECMQV) family schemes. 81 Two methods for specifying the algorithms that can be used with the 82 subjectPublicKey are defined. One method does not restrict the 83 algorithms the key can be used with while the other method does 84 restrict the algorithms the key can be used with. To promote 85 interoperability, this document indicates which is required to 86 implement for Certification Authorities (CAs) that implement ECC 87 algorithms and relying parties that claim to process ECC algorithms. 89 The ASN.1 module in this document includes ASN.1 for ECC algorithms. 90 It also includes ASN.1 for non-ECC algorithms defined in [PKI-ALG] 91 and [PKI-ADALG] even though the associated text is unaffected. By 92 updating all of the ASN.1 from [PKI-ALG] in this document, 93 implementers only need to use the module found in this document. 95 1.1. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [MUSTSHOULD]. 101 2. Subject Public Key Information Fields 103 In the X.509 certificate, the subjectPublicKeyInfo field has the 104 SubjectPublicKeyInfo type, which has the following ASN.1 syntax: 106 SubjectPublicKeyInfo ::= SEQUENCE { 107 algorithm AlgorithmIdentifier, 108 subjectPublicKey BIT STRING 109 } 111 The fields in SubjectPublicKeyInfo have the following meanings: 113 o algorithm is the algorithm identifier and parameters for the 114 ECC public key. 116 o subjectPublicKey is the ECC public key. See Section 2.2. 118 The AlgorithmIdentifier type, which is included for convenience 119 [PKI], is defined as follows: 121 AlgorithmIdentifier ::= SEQUENCE { 122 algorithm OBJECT IDENTIFIER, 123 parameters ANY DEFINED BY algorithm OPTIONAL 124 } 126 The fields in AlgorithmIdentifier have the following meanings: 128 o algorithm identifies the cryptographic algorithm with an object 129 identifier. See Section 2.1. 131 o parameters, which are optional, are the associated parameters 132 for the algorithm identifier in the algorithm field. See 133 Section 2.1.1. 135 2.1. Elliptic Curve Cryptography Public Key Algorithm Identifiers 137 The algorithm field in the SubjectPublicKeyInfo structure [PKI] 138 indicates the algorithm and any associated parameters for the ECC 139 public key (see Section 2.2). Three algorithm identifiers are 140 defined in this document: 142 o id-ecPublicKey indicates that the algorithms that can be used 143 with the subject public key is unrestricted. The key is only 144 restricted by the values indicated in the key usage certificate 145 extension (see Section 3). id-ecPublicKey MUST be supported. 146 See Section 2.1.1. This value is also included in certificates 147 when a public key is used with ECDSA. 149 o id-ecDH indicates that the algorithm that can be used with the 150 subject public key is restricted to the Elliptic Curve Diffie- 151 Hellman algorithm. See Section 2.1.2. id-ecDH MAY be 152 supported. 154 o id-ecMQV indicates that the algorithm that can be used with the 155 subject public key is restricted to the Elliptic Curve Menezes- 156 Qu-Vanstone key agreement algorithm. See Section 2.1.2. id- 157 ecMQV MAY be supported. 159 2.1.1. Unrestricted Algorithm Identifier and Parameters 161 The "unrestricted" algorithm identifier is: 163 id-ecPublicKey OBJECT IDENTIFIER ::= { 164 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } 166 The public key (ECPoint) syntax is described in Section 2.2. 168 The parameter for id-ecPublicKey is as follows and MUST always be 169 present: 171 ECParameters ::= CHOICE { 172 namedCurve OBJECT IDENTIFIER 173 -- implicitCurve NULL 174 -- specifiedCurve SpecifiedECDomain 175 } 176 -- implicitCurve and specifiedCurve MUST NOT be used in PKIX. 177 -- Details for SpecifiedECDomain can be found in [X9.62]. 178 -- Any future additions to this CHOICE should be coordinated 179 -- with ANSI X9. 181 The fields in ECParameters have the following meanings: 183 o namedCurve identifies all the required values for a particular 184 set of elliptic curve domain parameters to be represented by an 185 object identifier. This choice MUST be supported. See Section 186 2.1.1.1. 188 o implicitCurve allows the elliptic curve domain parameters to be 189 inherited. This choice MUST NOT be used. 191 o specifiedCurve, which is of type SpecifiedECDomain type 192 (defined in [X9.62]), allows all of the elliptic curve domain 193 parameters to be explicitly specified. This choice MUST NOT be 194 used. See the ASN.1 Considerations section. 196 The addition of any new choices in ECParameters needs to be 197 coordinated with ANSI X9. 199 The AlgorithmIdentifier within subjectPublicKeyInfo is the only place 200 within a certificate where the elliptic curve domain parameters may 201 be located. If the elliptic curve domain parameters are not present, 202 then clients MUST reject the certificate. 204 2.1.1.1. Named Curve 206 The namedCurve field in ECParameters uses object identifiers to name 207 well known curves. This document publishes curve identifiers for the 208 fifteen NIST recommended curves [FIPS186-3]. Other documents can 209 publish other name curve identifiers. The NIST named curves are: 211 -- Note that in [X9.62] the curves are referred to as 'ansiX9' as 212 -- opposed to 'sec'. For example secp192r1 is the same curve as 213 -- ansix9p192r1. 215 -- Note that in [PKI-ALG] the secp192r1 curve was referred to as 216 -- prime192v1 and the secp256r1 curve was referred to as 217 -- prime256v1. 219 -- Note that [FIPS186-3] refers to secp192r1 as P-192, secp224r1 as 220 -- P-224, secp256r1 as P-256, secp384r1 as P-384, and secp521r1 as 221 -- P-521. 223 secp192r1 OBJECT IDENTIFIER ::= { 224 iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) 225 prime(1) 1 } 227 sect163k1 OBJECT IDENTIFIER ::= { 228 iso(1) identified-organization(3) certicom(132) curve(0) 1 } 230 sect163r2 OBJECT IDENTIFIER ::= { 231 iso(1) identified-organization(3) certicom(132) curve(0) 15 } 233 secp224r1 OBJECT IDENTIFIER ::= { 234 iso(1) identified-organization(3) certicom(132) curve(0) 33 } 236 sect233k1 OBJECT IDENTIFIER ::= { 237 iso(1) identified-organization(3) certicom(132) curve(0) 26 } 239 sect233r1 OBJECT IDENTIFIER ::= { 240 iso(1) identified-organization(3) certicom(132) curve(0) 27 } 242 secp256r1 OBJECT IDENTIFIER ::= { 243 iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) 244 prime(1) 7 } 246 sect283k1 OBJECT IDENTIFIER ::= { 247 iso(1) identified-organization(3) certicom(132) curve(0) 16 } 249 sect283r1 OBJECT IDENTIFIER ::= { 250 iso(1) identified-organization(3) certicom(132) curve(0) 17 } 252 secp384r1 OBJECT IDENTIFIER ::= { 253 iso(1) identified-organization(3) certicom(132) curve(0) 34 } 255 sect409k1 OBJECT IDENTIFIER ::= { 256 iso(1) identified-organization(3) certicom(132) curve(0) 36 } 258 sect409r1 OBJECT IDENTIFIER ::= { 259 iso(1) identified-organization(3) certicom(132) curve(0) 37 } 261 secp521r1 OBJECT IDENTIFIER ::= { 262 iso(1) identified-organization(3) certicom(132) curve(0) 35 } 264 sect571k1 OBJECT IDENTIFIER ::= { 265 iso(1) identified-organization(3) certicom(132) curve(0) 38 } 267 sect571r1 OBJECT IDENTIFIER ::= { 268 iso(1) identified-organization(3) certicom(132) curve(0) 39 } 270 2.1.2. Restricted Algorithm Identifiers and Parameters 272 Two "restricted" algorithms are defined for key agreement algorithms: 273 the Elliptic Curve Diffie-Hellman (ECDH) key agreement family schemes 274 and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement 275 family schemes. Both algorithms are identified by an object 276 identifier and have parameters. The object identifier varies based 277 on the algorithm but the parameters are always ECParameters and they 278 MUST always be present (see Section 2.1.1). 280 The ECDH algorithm uses the following object identifier: 282 id-ecDH OBJECT IDENTIFIER ::= { 283 iso(1) identified-organization(3) certicom(132) schemes(1) 284 ecdh(12) } 286 The ECMQV algorithm uses the following object identifier: 288 id-ecMQV OBJECT IDENTIFIER ::= { 289 iso(1) identified-organization(3) certicom(132) schemes(1) 290 ecmqv(13) } 292 2.2. Subject Public Key 294 The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key. 295 ECC public keys have the following syntax: 297 ECPoint ::= OCTET STRING 299 Implementations of elliptic curve cryptography according to this 300 document MUST support the uncompressed form and MAY support the 301 compressed form of the ECC public key. The hybrid form of the ECC 302 public key from [X9.62] MUST NOT be used. As specified in [SEC1]: 304 o The elliptic curve public key (a value of type ECPoint which is 305 an OCTET STRING) is mapped to a subjectPublicKey (a value of 306 type BIT STRING) as follows: the most significant bit of the 307 OCTET STRING value becomes the most significant bit of the BIT 308 STRING value, and so on; the least significant bit of the OCTET 309 STRING becomes the least significant bit of the BIT STRING. 310 Conversion routines are found in Sections 2.3.1 and 2.3.2 of 311 [SEC1]. 313 o The first octet of the OCTET STRING indicates whether the key 314 is compressed or uncompressed. The uncompressed form is 315 indicated by 0x04 and the compressed form is indicated by 316 either 0x02 or 0x03 (see 2.3.3 in [SEC1]). The public key MUST 317 be rejected if any other value is included in the first octet. 319 3. Key Usage Bits 321 If the keyUsage extension is present in a Certification Authority 322 (CA) certificate that indicates id-ecPublicKey in 323 subjectPublicKeyInfo, then any combination of the following values 324 MAY be present: 326 digitalSignature; 327 nonRepudiation; 328 keyAgreement; 329 keyCertSign; and 330 cRLSign. 332 If the CA certificate keyUsage extension asserts keyAgreement, then 333 it MAY assert either encipherOnly or decipherOnly. However, this 334 specification RECOMMENDS that if keyCertSign or cRLSign is present, 335 then keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be 336 present. 338 If the keyUsage extension is present in an End Entity (EE) 339 certificate that indicates id-ecPublicKey in subjectPublicKeyInfo, 340 then any combination of the following values MAY be present: 342 digitalSignature; 343 nonRepudiation; and 344 keyAgreement. 346 If the EE certificate keyUsage extension asserts keyAgreement, then 347 it MAY assert either encipherOnly or decipherOnly. 349 If the keyUsage extension is present in a certificate that indicates 350 id-ecDH or id-ecMQV in subjectPublicKeyInfo, then the following MUST 351 be present: 353 keyAgreement; 355 one of the following MAY be present: 357 encipherOnly; or 358 decipherOnly. 360 If the keyUsage extension is present in a certificate that indicates 361 id-ecDH or id-ecMQV in subjectPublicKeyInfo, then the following 362 values MUST NOT be present: 364 digitalSignature; 365 nonRepudiation; 366 keyTransport; 367 keyCertSign; and 368 cRLSign. 370 4. Security Considerations 372 The security considerations in [PKI-ALG] apply. 374 When implementing ECC in X.509 Certificates and Certificate 375 Revocation Lists (CRLs), there are three algorithm related choices 376 that need to be made for the signatureAlgorithm field in a 377 Certificate: 379 1) What is the public key size? 381 2) What is the hash algorithm [FIPS180-3]? 383 3) What is the curve? 385 Consideration must be given by the CA to the strength of the security 386 provided by each of these choices. Security is measured in bits, 387 where a strong symmetric cipher with a key of X bits is said to 388 provide X bits of security. It is recommended that the bits of 389 security provided by each choice are roughly equivalent. The 390 following table provides comparable minimum bits of security [SP800- 391 57] for the ECDSA key sizes and message digest algorithms. It also 392 lists curves (see Section 2.1.1.1) for the key sizes. 394 Minimum | ECDSA | Message | Curves 395 Bits of | Key Size | Digest | 396 Security | | Algorithms | 397 ---------+----------+------------+----------- 398 80 | 160-223 | SHA-1 | sect163k1 399 | | SHA-224 | secp163r2 400 | | SHA-256 | secp192r1 401 | | SHA-384 | 402 | | SHA-512 | 403 ---------+----------+------------+----------- 404 112 | 224-255 | SHA-224 | secp224r1 405 | | SHA-256 | sect233k1 406 | | SHA-384 | sect233r1 407 | | SHA-512 | 408 ---------+----------+------------+----------- 409 128 | 256-383 | SHA-256 | secp256r1 410 | | SHA-384 | sect283k1 411 | | SHA-512 | sect283r1 412 ---------+----------+------------+----------- 413 192 | 384-511 | SHA-384 | secp384r1 414 | | SHA-512 | sect409k1 415 | | | sect409r1 416 ---------+----------+------------+----------- 417 256 | 512+ | SHA-512 | secp521r1 418 | | | sect571k1 419 | | | sect571r1 420 ---------+----------+------------+----------- 422 To promote interoperability, the following choices are RECOMMENDED: 424 Minimum | ECDSA | Message | Curves 425 Bits of | Key Size | Digest | 426 Security | | Algorithms | 427 ---------+----------+------------+----------- 428 80 | 192 | SHA-256 | secp192r1 429 ---------+----------+------------+----------- 430 112 | 224 | SHA-256 | secp224r1 431 ---------+----------+------------+----------- 432 128 | 256 | SHA-256 | secp256r1 433 ---------+----------+------------+----------- 434 192 | 384 | SHA-384 | secp384r1 435 ---------+----------+------------+----------- 436 256 | 512 | SHA-512 | secp521r1 437 ---------+----------+------------+----------- 439 Using a larger hash value and then truncating it, consumes more 440 processing power than is necessary. This is more important on 441 constrained devices. Since the signer does not know the environment 442 that the recipient will use to validate the signature, it is better 443 to use a hash function that provides the desired hash value output 444 size, and no more. 446 There are security risks with using keys not associated with well 447 known and widely reviewed curves. For example, the curve may not 448 satisfy the Menezes-Okamoto-Vanstone (MOV) condition [X9.62] or the 449 curve may be vulnerable to the Anomalous attack [X9.62]. 450 Additionally, either a) all of the arithmetic properties of a 451 candidate ECC public key must be validated to ensure that it has the 452 unique correct representation in the correct (additive) subgroup (and 453 therefore is also in the correct EC group) specified by the 454 associated ECC domain parameters or b) some of the arithmetic 455 properties of a candidate ECC public key must be validated to ensure 456 that it is in the correct group (but not necessarily the correct 457 subgroup) specified by the associated ECC domain parameters [SP800- 458 56A]. 460 As noted in [PKI-ALG], the use of MD2 and MD5 for new applications is 461 discouraged. It is still reasonable to use MD2 and MD5 to verify 462 existing signatures. 464 5. ASN.1 Considerations 466 [X9.62] defines additional options for ECParameters and ECDSA-Sig- 467 Value [PKI-ALG]. If an implementation needs to use these options, 468 then use the [X9.62] ASN.1 module. This RFC contains a conformant 469 subset of the ASN.1 module defined in [X9.62]. 471 If an implementation generates a PER [X.691] encoding using the ASN.1 472 module found in this specification, it might not achieve the same 473 encoded output as one that uses the [X9.62] module. PER is not 474 required by either the PKIX or S/MIME environments. If an 475 implementation environment requires PER, then implementation concerns 476 are less likely with the use of the [X9.62] module. 478 6. IANA Considerations 480 This document makes extensive use of object identifiers to register 481 public key types, elliptic curves, and algorithms. Most are 482 registered in the ANSI X9.62 arc with the exception of the hash 483 algorithms, which are in NIST arc, and many of the curves, which are 484 in the Certicom Inc. arc (these curves have been adopted by ANSI and 485 NIST). Additionally, an object identifier is used to identify the 486 ASN.1 module found in Appendix A. It is defined in an arc delegated 487 by IANA to the PKIX Working Group. No further action by IANA is 488 necessary for this document or any anticipated updates. 490 7. Acknowledgments 492 The authors wish to thank Stephen Farrell, Alfred Hoenes, Johannes 493 Merkle, Jim Schaad, and Carl Wallace for their valued input. 495 8. References 497 8.1. Normative References 499 [FIPS180-3] National Institute of Standards and Technology (NIST), 500 FIPS Publication 180-3: Secure Hash Standard, October 501 2008. 503 [FIPS186-3] National Institute of Standards and Technology (NIST), 504 FIPS Publication 186-3: Digital Signature Standard, 505 (draft) November 2008. 507 [PKI] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. 508 Housley, R., and W. Polk, "Internet X.509 Public Key 509 Infrastructure Certificate and Certificate Revocation 510 List (CRL) Profile", RFC 5280, May 2008. 512 [PKI-ALG] Polk, W., Housley, R. and L. Bassham, "Algorithm 513 Identifiers for the Internet X.509 Public Key 514 Infrastructure", RFC 3279, April 2002. 516 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate 517 Requirement Levels", BCP 14, RFC 2119, March 1997. 519 [RSAOAEP] Schaad, J., Kaliski, B., and R. Housley, "Additional 520 Algorithms and Identifiers for RSA Cryptography for use 521 in the Internet X.509 Public Key Infrastructure 522 Certificate and Certificate Revocation List (CRL) 523 Profile", RFC 4055, June 2005. 525 [SEC1] Standards for Efficient Cryptography Group (SECG), "SEC 526 1: Elliptic Curve Cryptography", Version 1.0, September 527 2000. 529 [X9.62] American National Standards Institute (ANSI), ANS 530 X9.62-2005: The Elliptic Curve Digital Signature 531 Algorithm (ECDSA), 2005. 533 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 534 1:2002. Information Technology - Abstract Syntax 535 Notation One. 537 8.2. Informative References 539 [PKI-ADALG] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and 540 T. Polk, "Internet X.509 Public Key Infrastructure: 541 Additional Algorithms and Identifiers for DSA and 542 ECDSA", draft-ietf-pkix-sha2-dsa-ecdsa-05.txt, work-in- 543 progress, October 2008. 545 [SP800-56A] National Institute of Standards and Technology (NIST), 546 Special Publication 800-56A: Recommendation for Pair- 547 Wise Key Establishment Schemes Using Discrete Logarithm 548 Cryptography (Revised), March 2007. 550 [SP800-57] National Institute of Standards and Technology (NIST), 551 Special Publication 800-57: Recommendation for Key 552 Management - Part 1 (Revised), March 2007. 554 [X.691] ITU-T Recommendation X.691 (2002) | ISO/IEC 8825- 555 2:2002. Information Technology - ASN.1 Encoding Rules: 556 Specification of Packed Encoding Rules. 558 Appendix A. ASN.1 Module 560 NOTE: The value for TBA1 will be included during AUTH48. 562 //** RFC Editor: Remove this note prior to publication **// 564 PKIX1Algorithms2008 { iso(1) identified-organization(3) dod(6) 565 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) TBA1 } 567 DEFINITIONS EXPLICIT TAGS ::= 569 BEGIN 571 -- EXPORTS ALL; 572 IMPORTS 574 -- From RFC 4055 [RSAOAEP] 576 id-sha224, id-sha256, id-sha384, id-sha512 577 FROM PKIX1-PSS-OAEP-Algorithms 578 { iso(1) identified-organization(3) dod(6) internet(1) 579 security(5) mechanisms(5) pkix(7) id-mod(0) 580 id-mod-pkix1-rsa-pkalgs(33) } 582 ; 584 -- 585 -- Message Digest Algorithms 586 -- 588 -- MD-2 589 -- Parameters are NULL 591 id-md2 OBJECT IDENTIFIER ::= { 592 iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2 } 594 -- MD-5 595 -- Parameters are NULL 597 id-md5 OBJECT IDENTIFIER ::= { 598 iso(1) member-body(2) us(840) rsadsi(113549)digestAlgorithm(2) 5 } 600 -- SHA-1 601 -- Parameters are preferred absent 603 id-sha1 OBJECT IDENTIFIER ::= { 604 iso(1) identified-organization(3) oiw(14) secsig(3) 605 algorithm(2) 26 } 607 -- SHA-224 608 -- Parameters are preferred absent 610 -- id-sha224 OBJECT IDENTIFIER ::= { 611 -- joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 612 -- csor(3) nistalgorithm(4) hashalgs(2) 4 } 613 -- SHA-256 614 -- Parameters are preferred absent 616 -- id-sha256 OBJECT IDENTIFIER ::= { 617 -- joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 618 -- csor(3) nistalgorithm(4) hashalgs(2) 1 } 620 -- SHA-384 621 -- Parameters are preferred absent 623 -- id-sha384 OBJECT IDENTIFIER ::= { 624 -- joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 625 -- csor(3) nistalgorithm(4) hashalgs(2) 2 } 627 -- SHA-512 628 -- Parameters are preferred absent 630 -- id-sha512 OBJECT IDENTIFIER ::= { 631 -- joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 632 -- csor(3) nistalgorithm(4) hashalgs(2) 3 } 634 -- 635 -- Public Key (PK) Algorithms 636 -- 638 -- RSA PK Algorithm and Key 640 rsaEncryption OBJECT IDENTIFIER ::= { 641 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 643 RSAPublicKey ::= SEQUENCE { 644 modulus INTEGER, -- n 645 publicExponent INTEGER -- e 646 } 648 -- DSA PK Algorithm, Key, and Parameters 650 id-dsa OBJECT IDENTIFIER ::= { 651 iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } 653 DSAPublicKey ::= INTEGER -- public key, y 655 DSS-Parms ::= SEQUENCE { 656 p INTEGER, 657 q INTEGER, 658 g INTEGER 659 } 660 -- Diffie-Hellman PK Algorithm, Key, and Parameters 662 dhpublicnumber OBJECT IDENTIFIER ::= { 663 iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } 665 DHPublicKey ::= INTEGER -- public key, y = g^x mod p 667 DomainParameters ::= SEQUENCE { 668 p INTEGER, -- odd prime, p=jq +1 669 g INTEGER, -- generator, g 670 q INTEGER, -- factor of p-1 671 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 672 validationParms ValidationParms OPTIONAL 673 } 675 ValidationParms ::= SEQUENCE { 676 seed BIT STRING, 677 pgenCounter INTEGER 678 } 680 -- KEA PK Algorithm and Parameters 682 id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= { 683 2 16 840 1 101 2 1 1 22 } 685 KEA-Parms-Id ::= OCTET STRING 687 -- Sec 2.1.1 Unrestricted Algorithm ID, Key, and Parameters 688 -- (ECDSA keys use id-ecPublicKey) 690 id-ecPublicKey OBJECT IDENTIFIER ::= { 691 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } 693 ECPoint ::= OCTET STRING 695 -- Parameters for both Restricted and Unrestricted 697 ECParameters ::= CHOICE { 698 namedCurve OBJECT IDENTIFIER 699 -- implicitCurve NULL 700 -- specifiedCurve SpecifiedECDomain 701 } 702 -- implicitCurve and specifiedCurve MUST NOT be used in PKIX. 703 -- Details for SpecifiedECDomain can be found in [X9.62]. 704 -- Any future additions to this CHOICE should be coordinated 705 -- with ANSI X9. 707 -- Sec 2.1.2 Restricted Algorithm IDs, Key, and Parameters: ECDH 709 id-ecDH OBJECT IDENTIFIER ::= { 710 iso(1) identified-organization(3) certicom(132) schemes(1) 711 ecdh(12) } 713 -- ECPoint ::= OCTET STRING 715 -- Parameters are ECParameters. 717 -- Sec 2.1.2 Restricted Algorithm IDs, Key, and Parameters: ECMQV 719 id-ecMQV OBJECT IDENTIFIER ::= { 720 iso(1) identified-organization(3) certicom(132) schemes(1) 721 ecmqv(13) } 723 -- ECPoint ::= OCTET STRING 725 -- Parameters are ECParameters. 727 -- 728 -- Signature Algorithms 729 -- 731 -- RSA with MD-2 732 -- Parameters are NULL 734 md2WithRSAEncryption OBJECT IDENTIFIER ::= { 735 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2 } 737 -- RSA with MD-5 738 -- Parameters are NULL 740 md5WithRSAEncryption OBJECT IDENTIFIER ::= { 741 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 } 743 -- RSA with SHA-1 744 -- Parameters are NULL 746 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { 747 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 749 -- DSA with SHA-1 750 -- Parameters are ABSENT 752 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { 753 iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 3 } 755 -- DSA with SHA-224 756 -- Parameters are ABSENT 758 id-dsa-with-sha224 OBJECT IDENTIFIER ::= { 759 joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) 760 csor(3) algorithms(4) id-dsa-with-sha2(3) 1 } 762 -- DSA with SHA-256 763 -- Parameters are ABSENT 765 id-dsa-with-sha256 OBJECT IDENTIFIER ::= { 766 joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) 767 csor(3) algorithms(4) id-dsa-with-sha2(3) 2 } 769 -- ECDSA with SHA-1 770 -- Parameters are ABSENT 772 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { 773 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 } 775 -- ECDSA with SHA-224 776 -- Parameters are ABSENT 778 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { 779 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 780 ecdsa-with-SHA2(3) 1 } 782 -- ECDSA with SHA-256 783 -- Parameters are ABSENT 785 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 786 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 787 ecdsa-with-SHA2(3) 2 } 789 -- ECDSA with SHA-384 790 -- Parameters are ABSENT 792 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { 793 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 794 ecdsa-with-SHA2(3) 3 } 796 -- ECDSA with SHA-512 797 -- Parameters are ABSENT 799 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { 800 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 801 ecdsa-with-SHA2(3) 4 } 803 -- 804 -- Signature Values 805 -- 807 -- DSA 809 DSA-Sig-Value ::= SEQUENCE { 810 r INTEGER, 811 s INTEGER 812 } 814 -- ECDSA 816 ECDSA-Sig-Value ::= SEQUENCE { 817 r INTEGER, 818 s INTEGER 819 } 821 -- 822 -- Named Elliptic Curves 823 -- 825 -- Note that in [X9.62] the curves are referred to as 'ansiX9' as 826 -- opposed to 'sec'. For example secp192r1 is the same curve as 827 -- ansix9p192r1. 829 -- Note that in [PKI-ALG] the secp192r1 curve was referred to as 830 -- prime192v1 and the secp256r1 curve was referred to as prime256v1. 832 -- Note that [FIPS186-3] refers to secp192r1 as P-192, secp224r1 as 833 -- P-224, secp256r1 as P-256, secp384r1 as P-384, and secp521r1 as 834 -- P-521. 836 secp192r1 OBJECT IDENTIFIER ::= { 837 iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) 838 prime(1) 1 } 840 sect163k1 OBJECT IDENTIFIER ::= { 841 iso(1) identified-organization(3) certicom(132) curve(0) 1 } 843 sect163r2 OBJECT IDENTIFIER ::= { 844 iso(1) identified-organization(3) certicom(132) curve(0) 15 } 846 secp224r1 OBJECT IDENTIFIER ::= { 847 iso(1) identified-organization(3) certicom(132) curve(0) 33 } 849 sect233k1 OBJECT IDENTIFIER ::= { 850 iso(1) identified-organization(3) certicom(132) curve(0) 26 } 852 sect233r1 OBJECT IDENTIFIER ::= { 853 iso(1) identified-organization(3) certicom(132) curve(0) 27 } 855 secp256r1 OBJECT IDENTIFIER ::= { 856 iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) 857 prime(1) 7 } 859 sect283k1 OBJECT IDENTIFIER ::= { 860 iso(1) identified-organization(3) certicom(132) curve(0) 16 } 862 sect283r1 OBJECT IDENTIFIER ::= { 863 iso(1) identified-organization(3) certicom(132) curve(0) 17 } 865 secp384r1 OBJECT IDENTIFIER ::= { 866 iso(1) identified-organization(3) certicom(132) curve(0) 34 } 868 sect409k1 OBJECT IDENTIFIER ::= { 869 iso(1) identified-organization(3) certicom(132) curve(0) 36 } 871 sect409r1 OBJECT IDENTIFIER ::= { 872 iso(1) identified-organization(3) certicom(132) curve(0) 37 } 874 secp521r1 OBJECT IDENTIFIER ::= { 875 iso(1) identified-organization(3) certicom(132) curve(0) 35 } 877 sect571k1 OBJECT IDENTIFIER ::= { 878 iso(1) identified-organization(3) certicom(132) curve(0) 38 } 880 sect571r1 OBJECT IDENTIFIER ::= { 881 iso(1) identified-organization(3) certicom(132) curve(0) 39 } 883 END 884 Authors' Addresses 886 Sean Turner 888 IECA, Inc. 889 3057 Nutley Street, Suite 106 890 Fairfax, VA 22031 891 USA 893 EMail: turners@ieca.com 895 Kelvin Yiu 897 Microsoft 898 One Microsoft Way 899 Redmond, WA 98052-6399 900 USA 902 Email: kelviny@microsoft.com 904 Daniel R. L. Brown 906 Certicom Corp 907 5520 Explorer Drive #400 908 Mississauga, ON L4W 5L1 909 CANADA 911 EMail: dbrown@certicom.com 913 Russ Housley 915 Vigil Security, LLC 916 918 Spring Knoll Drive 917 Herndon, VA 20170 918 USA 920 EMail: housley@vigilsec.com 922 Tim Polk 924 NIST 925 Building 820, Room 426 926 Gaithersburg, MD 20899 927 USA 929 EMail: wpolk@nist.gov 931 Full Copyright Statement 933 Copyright (C) The IETF Trust (2008). 935 This document is subject to the rights, licenses and restrictions 936 contained in BCP 78, and except as set forth therein, the authors 937 retain all their rights. 939 This document and the information contained herein are provided on an 940 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 941 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 942 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 943 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 944 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 945 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 947 Intellectual Property 949 The IETF takes no position regarding the validity or scope of any 950 Intellectual Property Rights or other rights that might be claimed to 951 pertain to the implementation or use of the technology described in 952 this document or the extent to which any license under such rights 953 might or might not be available; nor does it represent that it has 954 made any independent effort to identify any such rights. Information 955 on the procedures with respect to rights in RFC documents can be 956 found in BCP 78 and BCP 79. 958 Copies of IPR disclosures made to the IETF Secretariat and any 959 assurances of licenses to be made available, or the result of an 960 attempt made to obtain a general license or permission for the use of 961 such proprietary rights by implementers or users of this 962 specification can be obtained from the IETF on-line IPR repository at 963 http://www.ietf.org/ipr. 965 The IETF invites any interested party to bring to its attention any 966 copyrights, patents or patent applications, or other proprietary 967 rights that may cover technology that may be required to implement 968 this standard. Please address the information to the IETF at 969 ietf-ipr@ietf.org. 971 Acknowledgment 973 Funding for the RFC Editor function is provided by the IETF 974 Administrative Support Activity (IASA).