idnits 2.17.1 draft-ietf-pkix-ipki-ecdsa-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 200: '... cofactor INTEGER OPTIONAL,...' RFC 2119 keyword, line 212: '... seed BIT STRING OPTIONAL...' RFC 2119 keyword, line 264: '...D.&Type({IOSet}{@fieldType}) OPTIONAL...' RFC 2119 keyword, line 478: '...factor INTEGER OPTIONAL, -- ...' RFC 2119 keyword, line 485: '... seed BIT STRING OPTIONAL...' 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 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 21, 1999) is 8953 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 section? 'P1363' on line 614 looks like a reference -- Missing reference section? 'RFC 2459' on line 617 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group L. Bassham (NIST) 2 Internet Draft D. Johnson (Certicom) 3 expires April 21, 1999 W. Polk (NIST) 4 October 21, 1999 6 Internet X.509 Public Key Infrastructure 8 Representation of Elliptic Curve Digital Signature Algorithm 9 (ECDSA) Keys and Signatures in Internet X.509 Public Key 10 Infrastructure Certificates 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Drafts Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This is the third draft of a profile for specification of Elliptic 36 Curve Digital Signature Algorithm (ECDSA) keys and signatures in 37 Internet Public Key Infrastructure X.509 certificates and certificate 38 revocation lists. This specification is an addendum to RFC 2459; 39 implementations must also conform to RFC 2459. In addition, this 40 document references ANSI X9.62 for the specification of the ECDSA 41 algorithm. This specification only addresses the format of ECDSA 42 keys and signatures. Please send comments on this document to the 43 ietf-pkix@imc.org mail list. 45 1 Executive Summary 47 This specification contains guidance on the use of the Internet 48 Public Key Infrastructure certificates to convey Elliptic Curve 49 Digital Signature Algorithm (ECDSA) keys. This specification is an 50 addendum to RFC 2459, "Internet Public Key Infrastructure: X.509 51 Certificate and CRL Profile". Implementations of this specification 52 must also conform to RFC 2459. Implementations of this specification 53 are not required to conform to other parts from that series. 55 The Elliptic Curve Digital Signature Algorithm (ECDSA) is the 56 elliptic curve analog of the Digital Signature Algorithm (DSA). This 57 specification profiles the format and semantics of fields in X.509 V3 58 certificates containing ECDSA keys. The specification addresses the 59 subjectPublicKeyInfo field and the keyUsage extension. 61 2 Requirements and Assumptions 63 The goal is to augment the X.509 certificate profile presented in 64 Part 1 to facilitate the use and management of ECDSA keys for those 65 communities which use this algorithm. 67 2.1 Communication and Topology 69 This profile, as presented in Part 1 and augmented by this 70 specification, supports users without high bandwidth, real-time IP 71 connectivity, or high connection availability. In addition, the 72 profile allows for the presence of firewall or other filtered 73 communication. 75 This profile does not assume the deployment of an X.500 Directory 76 system. The profile does not prohibit the use of an X.500 Directory, 77 but other means of distributing certificates and certificate 78 revocation lists (CRLs) are supported. 80 2.2 Acceptability Criteria 82 The goal of the Internet Public Key Infrastructure (PKI) is to meet 83 the needs of deterministic, automated identification, authentication, 84 access control, and authorization functions. Support for these 85 services determines the attributes contained in the certificate as 86 well as the ancillary control information in the certificate such as 87 policy data and certification path constraints. 89 The goal of this document is to profile ECDSA certificates, 90 specifying the contents and semantics of attributes which were not 91 fully specified by Part 1. If not specifically addressed by this 92 document, the contents and semantics of the fields and extensions 93 must be as described in Part 1. 95 2.3 User Expectations 97 Users of the Internet PKI are people and processes who use client 98 software and are the subjects named in certificates. These uses 99 include readers and writers of electronic mail, the clients for WWW 100 browsers, WWW servers, and the key manager for IPSEC within a router. 101 This profile recognizes the limitations of the platforms these users 102 employ and the sophistication/attentiveness of the users themselves. 103 This manifests itself in minimal user configuration responsibility 104 (e.g., root keys, rules), explicit platform usage constraints within 105 the certificate, certification path constraints which shield the user 106 from many malicious actions, and applications which sensibly automate 107 validation functions. 109 2.4 Administrator Expectations 111 As with users, the Internet PKI profile is structured to support the 112 individuals who generally operate Certification Authorities (CAs). 113 Providing administrators with unbounded choices increases the chances 114 that a subtle CA administrator mistake will result in broad 115 compromise or unnecessarily limit interoperability. This profile 116 defines the object identifiers and data formats that must be 117 supported to interpret ECDSA public keys. 119 3 ECDSA Algorithm Support 121 This section describes object identifiers and data formats which may 122 be used with PKIX certificate profile to describe X.509 certificates 123 containing an ECDSA public key or signed with ECDSA. Conforming CAs 124 are required to use the object identifiers and data formats when 125 issuing ECDSA certificates. Conforming applications shall recognize 126 the object identifiers and process the data formats when processing 127 such certificates. 129 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 130 the ANSI X9.62 standard [X9.62]. The ASN.1 object identifiers used 131 to identify the ECDSA algorithm are defined in the following arc: 133 ansi-X9-62 OBJECT IDENTIFIER ::= 134 { iso(1) member-body(2) us(840) 10045 } 136 3.1 Subject Public Key Info 138 The certificate identifies the ECDSA algorithm, conveys optional 139 parameters, and specifies the ECDSA public key in the 140 subjectPublicKeyInfo field. The subjectPublicKeyInfo field is a 141 SEQUENCE of an algorithm identifier and the subjectPublicKey field. 143 The certificate indicates the algorithm through an algorithm 144 identifier. This algorithm identifier consists of an object 145 identifier (OID) and optional associated parameters. Section 3.1.1 146 identifies the preferred OID and parameters for the ECDSA algorithm. 147 Conforming CAs shall use the identified OID when issuing certificates 148 containing public keys for the ECDSA algorithm. Conforming 149 applications supporting the ECDSA algorithm shall, at a minimum, 150 recognize the OID identified in section 3.1.1. 152 The certificate conveys the ECDSA public key through the 153 subjectPublicKey field. This subjectPublicKey field is a BIT STRING. 154 Section 3.1.2 specifies the method for encoding a ECDSA public key as 155 a BIT STRING. Conforming CAs shall encode the ECDSA public key as 156 described in Section 3.1.2 when issuing certificates containing 157 public keys for the ECDSA algorithm. Conforming applications 158 supporting the ECDSA algorithm shall decode the subjectPublicKey as 159 described in section 3.1.2 when the algorithm identifier is the one 160 presented in 3.1.1. 162 3.1.1 Algorithm Identifier and Parameters 164 When certificates contain an ECDSA public key, the id-ecPublicKey 165 algorithm identifier shall be used. The id-ecPublicKey algorithm 166 identifier is defined as follows: 168 id-public-key-type OBJECT IDENTIFIER ::= { ansi-X9.62 2 } 170 id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 } 172 ECDSA requires use of certain parameters with the public key. The 173 parameters may be inherited from the issuer, implicitly included 174 through reference to a "named curve," or explicitly included in the 175 certificate. 177 Parameters ::= CHOICE { 178 ecParameters ECParameters, 179 namedCurve CURVES.&id({CurveNames}), 180 implicitlyCA NULL } 182 When the parameters are inherited, the parameters field shall contain 183 implictlyCA, which is the ASN.1 value NULL. When parameters are 184 specified by reference, the parameters field shall contain the 185 namedCurve choice, which is an an object identifier. When the 186 parameters are explicitly included, they shall be encoded in the 187 ASN.1 structure ECParameters: 189 ECParameters ::= SEQUENCE { 190 version INTEGER { ecpVer1(1) } (ecpVer1), 191 -- version is always 1 192 fieldID FieldID { {FieldTypes} }, 193 -- identifies the finite field over 194 -- which the curve is defined 195 curve Curve, -- coefficients a and b of the 196 -- elliptic curve 197 base ECPoint, -- specifies the base point P 198 -- on the elliptic curve 199 order INTEGER, -- the order n of the base point 200 cofactor INTEGER OPTIONAL, 201 ... } 203 FieldElement ::= OCTET STRING 205 The value of FieldElement shall be the octet string representation of 206 a field element following the conversion routine in [X9.62, Section 207 4.3.1] 209 Curve ::= SEQUENCE { 210 a FieldElement, 211 b FieldElement, 212 seed BIT STRING OPTIONAL 213 } 215 ECPoint ::= OCTET STRING 217 The value of ECPoint shall be the octet string representation of an 218 elliptic curve point following the conversion routine in [X9.62, 219 Section 4.4.3.b] 221 The components of type ECParameters have the following meanings: 223 * version specifies the version number of the elliptic curve 224 parameters. It shall have the value 1 for this version of the 225 Standard. The notation above creates an INTEGER named ecpVer1 and 226 gives it a value of one. It is used to constrain version to a single 227 value. 229 * fieldID identifies the finite field over which the elliptic curve 230 is defined. Finite fields are represented by values of the 231 parameterized type FieldID, constrained to the values of the objects 232 defined in the information object set FieldTypes. Additional detail 233 regarding fieldID is provided below. 235 * curve specifies the coefficients a and b of the elliptic curve E. 236 Each coefficient shall be represented as a value of type 237 FieldElement, an OCTET STRING. seed is an optional parameter used to 238 derive the coefficients of a randomly generated elliptic curve. 240 * base specifies the base point P on the elliptic curve. The base 241 point shall be represented as a value of type ECPoint, an OCTET 242 STRING. 244 * order specifies the order n of the base point. 246 * cofactor is the integer h = #E(Fq)/n. Note: This optional parameter 247 is not used in ECDSA, except in parameter validation. Parameter 248 validation is not required by this specification. It is included for 249 compatibility with Elliptic Curve Key Agreement public key 250 parameters, and to support parameter validation. 252 The AlgorithmIdentifier within subjectPublicKeyInfo is the only place 253 within a certificate where the parameters may be used. If the ECDSA 254 algorithm parameters are absent from the subjectPublicKeyInfo 255 AlgorithmIdentifier and the CA signed the subject certificate using 256 ECDSA, then the certificate issuer's ECDSA parameters apply to the 257 subject's ECDSA key. If the ECDSA algorithm parameters are absent 258 from the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed 259 the certificate using a signature algorithm other than ECDSA, then 260 clients shall not validate the certificate. 262 FieldID { FIELD-ID:IOSet } ::= SEQUENCE { 263 fieldType FIELD-ID.&id({IOSet}), 264 parameters FIELD-ID.&Type({IOSet}{@fieldType}) OPTIONAL 265 } 266 FieldTypes FIELD-ID ::= { 267 { Prime-p IDENTIFIED BY prime-field } | 268 { Characteristic-two IDENTIFIED BY characteristic-two-field }, 269 ... 270 } 271 FIELD-ID ::= TYPE-IDENTIFIER 273 FieldID is a parameterized type composed of two components, fieldType 274 and parameters. These components are specified by the fields &id and 275 &Type, which form a template for defining sets of information 276 objects, instances of the class FIELD-ID. This class is based on the 277 useful information object class TYPE-IDENTIFIER, described in X.681 278 Annex A. In an instance of FieldID, "fieldType" will contain an 279 object identifier value that uniquely identifies the type contained 280 in "parameters". The effect of referencing "fieldType" in both 281 components of the fieldID sequence is to tightly bind the object 282 identifier and its type. 284 The information object set FieldTypes is used as the single parameter 285 in a reference to type FieldID. FieldTypes contains two objects 286 followed by the extension marker ("..."). Each object, which 287 represents a finite field, contains a unique object identifier and 288 its associated type. The values of these objects define all of the 289 valid values that may appear in an instance of fieldID. The extension 290 marker allows backward compatibility with future versions of this 291 standard which may define objects to represent additional kinds of 292 finite fields. 294 The object identifier id-fieldType represents the root of a tree 295 containing the object identifiers of each field type. It has the 296 following value: 298 id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) } 300 The object identifiers prime-field and characteristic-two-field name 301 the two kinds of fields defined in this Standard. They have the 302 following values: 304 prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 } 306 characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 } 308 Prime-p ::= INTEGER -- Field size p (p in bits) 310 Characteristic-two ::= SEQUENCE { 311 m INTEGER, -- Field size 2^m (m in bits) 312 basis CHARACTERISTIC-TWO.&id({BasisTypes}), 313 parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) 314 } 316 BasisTypes CHARACTERISTIC-TWO::= { 317 { NULL IDENTIFIED BY gnBasis } | 318 { Trinomial IDENTIFIED BY tpBasis } | 319 { Pentanomial IDENTIFIED BY ppBasis }, 320 ... 321 } 323 Trinomial ::= INTEGER 325 Pentanomial ::= SEQUENCE { 326 k1 INTEGER, 327 k2 INTEGER, 328 k3 INTEGER 329 } 331 CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER 332 The object identifier id-characteristic-two-basis represents the root 333 of a tree containing the object identifiers for each type of basis 334 for the characteristic-two finite fields. It has the following value: 336 id-characteristic-two-basis OBJECT IDENTIFIER ::= { 337 characteristic-two-field basisType(1) } 339 The object identifiers gnBasis, tpBasis and ppBasis name the three 340 kinds of basis for characteristic-two finite fields defined by 341 [X9.62]. They have the following values: 343 gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 } 344 tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 } 345 ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 } 347 3.1.2 Encoding of ECDSA Public Keys 349 The elliptic curve public key (an ECPoint which is an OCTET STRING) 350 is mapped to a subjectPublicKey (a BIT STRING) as follows: the most 351 significant bit of the OCTET STRING becomes the most significant bit 352 of the BIT STRING, etc.; the least significant bit of the OCTET 353 STRING becomes the least significant bit of the BIT STRING. 355 3.1.3 Key Usage Extension in ECDSA certificates 357 The key usage extension may optionally appear in certificates which 358 convey an ECDSA public key. If a certificate containing an ECDSA 359 public key includes the keyUsage extension, only the following values 360 may be asserted: 362 digitalSignature; 363 nonRepudiation; 364 keyCertSign; and 365 cRLSign. 367 The keyCertSign and cRLSign values may only be asserted if the 368 basicConstraints extension is present and cA is TRUE. 370 3.2 Representation of ECDSA Signatures 372 When used to sign certificates, CRLs, or PKI messages, the ECDSA 373 shall be used with the SHA-1 hash algorithm. The ASN.1 object 374 identifier used to identify the ECDSA algorithm with SHA-1 shall be: 376 id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) } 377 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 } 379 When the ecdsa-with-SHA1 algorithm identifier is used in the SIGNED 380 parameterized TYPE (e.g., in the signature on a certificate or CRL) 381 it shall have NULL parameters. The ECDSA parameters in the 382 certificate of the issuer shall apply to the verification of the 383 signature. When signing, the ECDSA algorithm generates two values. 384 These values are commonly referred to as r and s. To easily transfer 385 these two values as one signature, they shall be ASN.1 encoded using 386 the following ASN.1 structure: 388 Ecdsa-Sig-Value ::= SEQUENCE { 389 r INTEGER, 390 s INTEGER } 392 4 ASN.1 Module 394 ANSI-X9-62 { iso(1) member-body(2) us(840) 10045 module(4) 1 } 395 DEFINITIONS EXPLICIT TAGS ::= BEGIN 397 -- EXPORTS All; 399 -- IMPORTS None; 401 ansi-X9-62 OBJECT IDENTIFIER ::= { 402 iso(1) member-body(2) us(840) 10045 } 404 FieldID { FIELD-ID:IOSet } ::= SEQUENCE { -- Finite field 405 fieldType FIELD-ID.&id({IOSet}), 406 parameters FIELD-ID.&Type({IOSet}{@fieldType}) 407 } 409 FieldTypes FIELD-ID ::= { 410 { Prime-p IDENTIFIED BY prime-field } | 411 { Characteristic-two IDENTIFIED BY characteristic-two-field }, 412 ... 413 } 415 FIELD-ID ::= TYPE-IDENTIFIER -- ISO/IEC 8824-2:1995(E), Annex A 417 id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) } 419 prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 } 421 characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 } 423 Prime-p ::= INTEGER -- Finite field F(p), where p is an odd prime 425 Characteristic-two ::= SEQUENCE { 426 m INTEGER, -- Field size 2^m 427 basis CHARACTERISTIC-TWO.&id({BasisTypes}), 428 parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) 429 } 431 BasisTypes CHARACTERISTIC-TWO::= { 432 { NULL IDENTIFIED BY gnBasis } | 433 { Trinomial IDENTIFIED BY tpBasis } | 434 { Pentanomial IDENTIFIED BY ppBasis }, 435 ... 436 } 438 -- Trinomial basis representation of F2^m 439 -- Integer k for reduction polynomial xm + xk + 1 440 -- 441 Trinomial ::= INTEGER 443 Pentanomial ::= SEQUENCE { 444 -- 445 -- Pentanomial basis representation of F2^m 446 -- reduction polynomial integers k1, k2, k3 447 -- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1 448 -- 449 k1 INTEGER, 450 k2 INTEGER, 451 k3 INTEGER 452 } 454 CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER 456 id-characteristic-two-basis OBJECT IDENTIFIER ::= { 457 characteristic-two-field basisType(3) } 459 -- The object identifiers gnBasis, tpBasis and ppBasis name 460 -- three kinds of basis for characteristic-two finite fields 462 gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 } 464 tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 } 466 ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 } 468 FieldElement ::= OCTET STRING -- Finite field element 470 ECPoint ::= OCTET STRING -- Elliptic curve point 472 ECParameters ::= SEQUENCE { -- Elliptic curve parameters 473 version INTEGER { ecpVer1(1) } (ecpVer1), 474 fieldID FieldID {{FieldTypes}}, 475 curve Curve, 476 base ECPoint, -- Base point G 477 order INTEGER, -- Order n of the base point 478 cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n 479 ... 480 } 482 Curve ::= SEQUENCE { 483 a FieldElement, -- Elliptic curve coefficient a 484 b FieldElement, -- Elliptic curve coefficient b 485 seed BIT STRING OPTIONAL 486 } 488 ECDSA-Sig-Value ::= SEQUENCE { 489 r INTEGER, 490 s INTEGER 491 } 493 id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) } 495 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 } 497 SubjectPublicKeyInfo ::= SEQUENCE { 498 algorithm AlgorithmIdentifier {{ECPKAlgorithms}}, 499 subjectPublicKey BIT STRING 500 } 502 AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { 503 algorithm ALGORITHM.&id({IOSet}), 504 parameters ALGORITHM.&Type({IOSet}{@algorithm}) 505 } 507 ECPKAlgorithms ALGORITHM ::= { 508 ecPublicKeyType, 509 ... 510 } 512 ecPublicKeyType ALGORITHM ::= { 513 Parameters IDENTIFIED BY id-ecPublicKey 514 } 516 ALGORITHM ::= TYPE-IDENTIFIER 518 id-publicKeyType OBJECT IDENTIFIER ::= { ansi-X9-62 keyType(2) } 520 id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 } 521 Parameters ::= CHOICE { 522 ecParameters ECParameters, 523 namedCurve CURVES.&id({CurveNames}), 524 implicitlyCA NULL 525 } 527 -- The following OIDS are defined in ANSI X9.62. ANSI, and 528 -- other standards bodies, may define other OIDs to represent 529 -- other elliptic curve parameters. Users are encouraged 530 -- to consult relevant standards and specifications to 531 -- determine which OIDs (if any) are appropriate for their 532 -- applications. 534 CurveNames CURVES ::= { 535 { ID c2pnb163v1 } | -- J.4.1, example 1 -- 536 { ID c2pnb163v2 } | -- J.4.1, example 2 -- 537 { ID c2pnb163v3 } | -- J.4.1, example 3 -- 538 { ID c2pnb176w1 } | -- J.4.2, example 1 -- 539 { ID c2tnb191v1 } | -- J.4.3, example 1 -- 540 { ID c2tnb191v2 } | -- J.4.3, example 2 -- 541 { ID c2tnb191v3 } | -- J.4.3, example 3 -- 542 { ID c2onb191v4 } | -- J.4.3, example 4 -- 543 { ID c2onb191v5 } | -- J.4.3, example 5 -- 544 { ID c2pnb208w1 } | -- J.4.4, example 1 -- 545 { ID c2tnb239v1 } | -- J.4.5, example 1 -- 546 { ID c2tnb239v2 } | -- J.4.5, example 2 -- 547 { ID c2tnb239v3 } | -- J.4.5, example 3 -- 548 { ID c2onb239v4 } | -- J.4.5, example 4 -- 549 { ID c2onb239v5 } | -- J.4.5, example 5 -- 550 { ID c2pnb272w1 } | -- J.4.6, example 1 -- 551 { ID c2pnb304w1 } | -- J.4.7, example 1 -- 552 { ID c2tnb359v1 } | -- J.4.8, example 1 -- 553 { ID c2pnb368w1 } | -- J.4.9, example 1 -- 554 { ID c2tnb431r1 } | -- J.4.10, example 1 -- 555 { ID prime192v1 } | -- J.5.1, example 1 -- 556 { ID prime192v2 } | -- J.5.1, example 2 -- 557 { ID prime192v3 } | -- J.5.1, example 3 -- 558 { ID prime239v1 } | -- J.5.2, example 1 -- 559 { ID prime239v2 } | -- J.5.2, example 2 -- 560 { ID prime239v3 } | -- J.5.2, example 3 -- 561 { ID prime256v1 }, -- J.5.3, example 1 -- 562 ... -- others -- 563 } 565 CURVES ::= CLASS { 566 &id OBJECT IDENTIFIER UNIQUE 567 } 568 WITH SYNTAX { ID &id } 570 ellipticCurve OBJECT IDENTIFIER ::= { ansi-X9-62 curves(3) } 572 c-TwoCurve OBJECT IDENTIFIER ::= { 573 ellipticCurve characteristicTwo(0) } 575 primeCurve OBJECT IDENTIFIER ::= { ellipticCurve prime(1) } 577 c2pnb163v1 OBJECT IDENTIFIER ::= { c-TwoCurve 1 } 578 c2pnb163v2 OBJECT IDENTIFIER ::= { c-TwoCurve 2 } 579 c2pnb163v3 OBJECT IDENTIFIER ::= { c-TwoCurve 3 } 580 c2pnb176w1 OBJECT IDENTIFIER ::= { c-TwoCurve 4 } 581 c2tnb191v1 OBJECT IDENTIFIER ::= { c-TwoCurve 5 } 582 c2tnb191v2 OBJECT IDENTIFIER ::= { c-TwoCurve 6 } 583 c2tnb191v3 OBJECT IDENTIFIER ::= { c-TwoCurve 7 } 584 c2onb191v4 OBJECT IDENTIFIER ::= { c-TwoCurve 8 } 585 c2onb191v5 OBJECT IDENTIFIER ::= { c-TwoCurve 9 } 586 c2pnb208w1 OBJECT IDENTIFIER ::= { c-TwoCurve 10 } 587 c2tnb239v1 OBJECT IDENTIFIER ::= { c-TwoCurve 11 } 588 c2tnb239v2 OBJECT IDENTIFIER ::= { c-TwoCurve 12 } 589 c2tnb239v3 OBJECT IDENTIFIER ::= { c-TwoCurve 13 } 590 c2onb239v4 OBJECT IDENTIFIER ::= { c-TwoCurve 14 } 591 c2onb239v5 OBJECT IDENTIFIER ::= { c-TwoCurve 15 } 592 c2pnb272w1 OBJECT IDENTIFIER ::= { c-TwoCurve 16 } 593 c2pnb304w1 OBJECT IDENTIFIER ::= { c-TwoCurve 17 } 594 c2tnb359v1 OBJECT IDENTIFIER ::= { c-TwoCurve 18 } 595 c2pnb368w1 OBJECT IDENTIFIER ::= { c-TwoCurve 19 } 596 c2tnb431r1 OBJECT IDENTIFIER ::= { c-TwoCurve 20 } 598 prime192v1 OBJECT IDENTIFIER ::= { primeCurve 1 } 599 prime192v2 OBJECT IDENTIFIER ::= { primeCurve 2 } 600 prime192v3 OBJECT IDENTIFIER ::= { primeCurve 3 } 601 prime239v1 OBJECT IDENTIFIER ::= { primeCurve 4 } 602 prime239v2 OBJECT IDENTIFIER ::= { primeCurve 5 } 603 prime239v3 OBJECT IDENTIFIER ::= { primeCurve 6 } 604 prime256v1 OBJECT IDENTIFIER ::= { primeCurve 7 } 606 END 608 5 References 610 [X9.62] X9.62-1999, "Public Key Cryptography For The Financial 611 Services Industry: The Elliptic Curve Digital Signature 612 Algorithm (ECDSA)". 614 [P1363] IEEE P1363, "Standard for Public-Key Cryptography", draft 615 standard, 1997. 617 [RFC 2459] R. Housley, W. Ford, W. Polk and D. Solo "Internet X.509 618 Public Key Infrastructure: Certificate and CRL Profile", 619 January, 1999. 621 6 Intellectual Property Rights 623 The IETF has been notified of intellectual property rights claimed in 624 regard to some or all of the specification contained in this 625 document. For more information, consult the online list of claimed 626 rights. 628 The IETF takes no position regarding the validity or scope of any 629 intellectual property or other rights that might be claimed to 630 pertain to the implementation or use of the technology described in 631 this document or the extent to which any license under such rights 632 might or might not be available; neither does it represent that it 633 has made any effort to identify any such rights. Information on the 634 IETF's procedures with respect to rights in standards-track and 635 standards-related documentation can be found in BCP-11. Copies of 636 claims of rights made available for publication and any assurances of 637 licenses to be made available, or the result of an attempt made to 638 obtain a general license or permission for the use of such 639 proprietary rights by implementors or users of this specification can 640 be obtained from the IETF Secretariat. 642 7 Security Considerations 644 This specification does not constrain the key sizes or identify 645 particular elliptic curves for use in the Internet PKI. However, 646 both the key size and the particular curve selected impact the the 647 strength of the digital signatures. Some curves are cryptographically 648 stronger than others! 650 In general, use of "well-known" curves, such as the "named curves" 651 from ANSI X9.62 is a sound strategy. For additional information, 652 refer to X9.62 Appendix D.4, "Key Length Considerations" and Appendix 653 F.1, "Avoiding Cryptographically Weak Keys". 655 This specification is a profile of RFC 2459. The security 656 considerations section of that document applies to this specification 657 as well. 659 8 Author Addresses: 661 Larry Bassham 662 NIST 663 100 Bureau Drive, Stop 8930 664 Gaithersburg, MD 20899-8930 665 USA 666 lbassham@nist.gov 668 Don Johnson 669 Certicom 670 4253 Sleepy Lake Drive 671 Fairfax, VA 22033 672 USA 673 djohnson@certicom.com 675 Tim Polk 676 NIST 677 100 Bureau Drive, Stop 8930 678 Gaithersburg, MD 20899-8930 679 USA 680 wpolk@nist.gov