idnits 2.17.1 draft-ietf-pkix-ecc-subpubkeyinfo-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1077. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1088. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1095. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1101. 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 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (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 (March 11, 2008) is 5890 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) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 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: September 11, 2008 Tim Polk, NIST 6 March 11, 2008 8 Elliptic Curve Cryptography Subject Public Key Information 9 draft-ietf-pkix-ecc-subpubkeyinfo-04.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 September 11, 2008. 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 RFC 3279. 46 Table of Contents 48 1. Introduction...................................................2 49 1.1. Terminology...............................................3 50 2. Subject Public Key Information Fields..........................3 51 2.1. Elliptic Curve Public Key Algorithm Identifier............4 52 2.1.1. Unrestricted Identifiers and Parameters..............5 53 2.1.1.1. Named Curve.....................................5 54 2.1.1.2. Specified Curve.................................7 55 2.1.1.2.1. Specified Curve Version....................8 56 2.1.1.2.2. Field Identifiers..........................8 57 2.1.1.2.2.1. Prime-p...............................9 58 2.1.1.2.2.2. Characteristic-two...................10 59 2.1.1.2.3. Curve.....................................12 60 2.1.1.2.4. Base......................................12 61 2.1.1.2.5. Hash......................................12 62 2.1.2. Restricted Algorithm Identifiers and Parameters.....14 63 2.2. Subject Public Key.......................................15 64 3. KeyUsage Bits.................................................15 65 4. Security Considerations.......................................16 66 5. IANA Considerations...........................................16 67 6. References....................................................16 68 6.1. Normative References.....................................16 69 6.2. Informative References...................................17 70 Appendix A. ASN.1 Module.........................................17 72 1. Introduction 74 This document specifies the format of the subjectPublicKeyInfo field 75 in X.509 certificates [RFC3280] that use Elliptic Curve Cryptography 76 (ECC). It updates [RFC3279]. This document specifies the encoding 77 formats for public keys used with the following ECC algorithms: 79 Elliptic Curve Digital Signature Algorithm (ECDSA); 81 Elliptic Curve Diffie-Hellman (ECDH) family schemes; and, 83 Elliptic Curve Menezes-Qu-Vanstone (ECMQV) family schemes. 85 Two methods for specifying the algorithms that can be used with the 86 subjectPublicKey are defined. One method does not restrict the 87 algorithms the key can be used with while the other method does 88 restrict the algorithms the key can be used with. To promote 89 interoperability, this document indicates which is required to 90 implement. 92 Three methods for specifying the algorithm's parameters are also 93 defined. One allows for complete specification of the Elliptic Curve 94 (EC), one allows for the EC to be identified by an object identifier, 95 and one allows for the EC to be inherited from the issuer's 96 certificate. To promote interoperability, this document indicates 97 which options are required to implement. 99 Specification of all EC parameters is complicated with many options. 100 To promote interoperability, this document indicates which options 101 are required to implement. 103 1.1. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Subject Public Key Information Fields 111 In the X.509 certificate, the subjectPublicKeyInfo field has the 112 SubjectPublicKeyInfo type, which has the following ASN.1 syntax: 114 SubjectPublicKeyInfo ::= SEQUENCE { 115 algorithm AlgorithmIdentifier {{ECPKAlgorithms}}, 116 subjectPublicKey BIT STRING 117 } 119 The fields in SubjectPublicKeyInfo have the following meanings: 121 algorithm is the algorithm identifier and algorithm parameters 122 for the ECC public key. See paragraph 2.1. 124 subjectPublicKey is the ECC public key. See paragraph 2.2. 126 The class ALGORITHM parameterizes the AlgorithmIdentifier type with 127 sets of legal values (this class is used in many places in this 128 document): 130 ALGORITHM ::= CLASS { 131 &id OBJECT IDENTIFIER UNIQUE, 132 &Type OPTIONAL 133 } 134 WITH SYNTAX { OID &id [PARMS &Type] } 136 The type AlgorithmIdentifier is parameterized to allow legal sets of 137 values to be specified by constraining the type with an information 138 object set. There are two parameterized types for AlgorithmIdentifier 139 defined in this document: ECPKAlgorithms (see paragraph 2.1) and 140 HashFunctions (see paragraph 2.1.1.2.5). 142 AlgorithmIdentifier {ALGORITHM:IOSet} ::= SEQUENCE { 143 algorithm ALGORITHM.&id({IOSet}), 144 parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL 145 } 147 The fields in AlgorithmIdentifier have the following meaning: 149 algorithm identifies a cryptographic algorithm. The OBJECT 150 IDENTIFIER component identifies the algorithm. The contents of 151 the optional parameters field will vary according to the 152 algorithm identified. 154 parameters, which is optional, varies based on the algorithm 155 identified. 157 2.1. Elliptic Curve Cryptography Public Key Algorithm Identifiers 159 The algorithm field in the SubjectPublicKeyInfo structure indicates 160 the algorithms and any associated parameters for the ECC public key 161 (see paragraph 2.2). The algorithms are restricted to the 162 ECPKAlgorithms parameterized type, which uses the following ASN.1 163 structure: 165 ECPKAlgorithms ALGORITHM ::= { 166 ecPublicKeyType | 167 ecDH | 168 ecMQV, 169 ... -- Extensible 170 } 172 The algorithms defined are as follows: 174 ecPublicKeyType indicates that the algorithms that can be used 175 with the subject public key are not restricted (i.e., they are 176 unrestricted). The key is only restricted by the values 177 indicated in the key usage certificate extension. The 178 ecPublicKeyType MUST be supported. See paragraph 2.1.1. This 179 value is also used when a key is used with ECDSA. 181 ecDH and ecMQV MAY be supported. See paragraph 2.1.2. 183 2.1.1. Unrestricted Identifiers and Parameters 185 The "unrestricted" algorithm is defined as follows: 187 ecPublicKeyType ALGORITHM ::= { 188 OID id-ecPublicKey PARMS ECParameters } 190 The algorithm identifier is: 192 id-ecPublicKey OBJECT IDENTIFIER ::= { 193 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } 195 The parameters for id-ecPublicKey are as follows: 197 ECParameters ::= CHOICE { 198 namedCurve CURVE.&id({NamedCurve}), 199 specifiedCurve SpecifiedCurve, 200 implicitCurve NULL 201 } 203 The fields in ECParameters have the following meanings: 205 namedCurve allows all the required values for a particular set of 206 elliptic curve domain parameters to be represented by an object 207 identifier. This choice MUST be supported. See paragraph 208 2.1.1.1. 210 specifiedCurve allows all of the required values to be explicitly 211 specified. This choice MAY be supported, and if it is, 212 implicitCurve MUST also be supported. See paragraph 2.1.1.2. 214 implicitCurve allows the elliptic curve parameters to be 215 inherited from the issuer's certificate. This choice MAY be 216 supported, but if subordinate certificates use the same 217 namedCurve as their superior, then the subordinate certificate 218 MUST use the namedCurve option. That is, implicitCurve is only 219 supported if the superior doesn't use the namedCurve option. 221 2.1.1.1. Named Curve 223 The namedCurve field in ECParameters uses the class CURVE to 224 constrain the set of legal values from NamedCurve, which are object 225 identifiers: 227 CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } 228 WITH SYNTAX { ID &id } 230 The NamedCurve parameterized type is defined as follows: 232 NamedCurve CURVE ::= { 233 { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | 234 { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | 235 { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | 236 { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | 237 { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 }, 238 ... -- Extensible 239 } 241 The curve identifiers are the fifteen NIST recommended curves: 243 secp192r1 OBJECT IDENTIFIER ::= { 244 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 245 curves(3) prime(1) 1 } 247 sect163k1 OBJECT IDENTIFIER ::= { 248 iso(1) identified-organization(3) certicom(132) curve(0) 1 } 250 sect163r2 OBJECT IDENTIFIER ::= { 251 iso(1) identified-organization(3) certicom(132) curve(0) 15 } 253 secp224r1 OBJECT IDENTIFIER ::= { 254 iso(1) identified-organization(3) certicom(132) curve(0) 33 } 256 sect233k1 OBJECT IDENTIFIER ::= { 257 iso(1) identified-organization(3) certicom(132) curve(0) 26 } 259 sect233r1 OBJECT IDENTIFIER ::= { 260 iso(1) identified-organization(3) certicom(132) curve(0) 27 } 262 secp256r1 OBJECT IDENTIFIER ::= { 263 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 264 curves(3) prime(1) 7 } 266 sect283k1 OBJECT IDENTIFIER ::= { 267 iso(1) identified-organization(3) certicom(132) curve(0) 16 } 269 sect283r1 OBJECT IDENTIFIER ::= { 270 iso(1) identified-organization(3) certicom(132) curve(0) 17 } 272 secp384r1 OBJECT IDENTIFIER ::= { 273 iso(1) identified-organization(3) certicom(132) curve(0) 34 } 275 sect409k1 OBJECT IDENTIFIER ::= { 276 iso(1) identified-organization(3) certicom(132) curve(0) 36 } 278 sect409r1 OBJECT IDENTIFIER ::= { 279 iso(1) identified-organization(3) certicom(132) curve(0) 37 } 281 secp521r1 OBJECT IDENTIFIER ::= { 282 iso(1) identified-organization(3) certicom(132) curve(0) 35 } 284 sect571k1 OBJECT IDENTIFIER ::= { 285 iso(1) identified-organization(3) certicom(132) curve(0) 38 } 287 sect571r1 OBJECT IDENTIFIER ::= { 288 iso(1) identified-organization(3) certicom(132) curve(0) 39 } 290 2.1.1.2. Specified Curve 292 The specifiedCurve field in ECParameters is of SpecifiedCurve type. 293 SpecifiedCurve uses the following ASN.1 structure: 295 SpecifiedCurve ::= SEQUENCE { 296 version SpecifiedCurveVersion 297 ( ecpVer1 | ecpVer2 | ecpVer3 ), 298 fieldID FieldID {{FieldTypes}}, 299 curve Curve, -- Curve E 300 base ECPoint, -- Base point P 301 order INTEGER, -- Order n of the base point 302 cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n 303 hash HashAlgorithm OPTIONAL, 304 ... -- Extensible 305 } 307 The fields in SpecifiedCurve have the following meaning: 309 version specifies the version number of the elliptic curve 310 parameters. See paragraph 2.1.1.2.1. 312 fieldID identifies the finite field over which the elliptic 313 curve, specified in the curve field, is defined. See paragraph 314 2.1.1.2.2. 316 curve specifies the elliptic curve E. See paragraph 2.1.1.2.3. 318 base specifies the base point P on the elliptic curve E, 319 specified in the curve field. See paragraph 2.1.1.2.4. 321 order specifies the order n of the base point P, specified in 322 base. 324 cofactor is the order of the curve, specified in the curve field, 325 divided by the order, specified in the order field, of the base 326 point, specified in the base field (i.e., h = #E(Fq)/n). 327 Inclusion of the cofactor is optional; however, it is strongly 328 RECOMMENDED that that the cofactor be included in order to 329 facilitate interoperability between implementations. 331 hash is the hash algorithm used to generate the elliptic curve E, 332 specified in the curve field, and/or base point P, specified in 333 the base field, verifiably pseudorandomly. If the hash field is 334 omitted, then the hash algorithm shall be SHA1. See paragraph 335 2.1.1.2.5. 337 SpecifiedCurve is extensible and other documents may specify 338 additional fields for this ASN.1 structure. 340 2.1.1.2.1. Specified Curve Version 342 The version field in SpecifiedCurve is of SpecifiedCurveVersion type. 343 SpecifiedCurveVersion uses the following ASN.1 structure: 345 SpecifiedCurveVersion ::= INTEGER { 346 ecpVer1(1), 347 ecpVer2(2), 348 ecpVer3(3) 349 } 351 SpecfifiedCurveVersion is ecdpVer1, ecdpVer2, or ecdpVer3. If 352 version is ecdpVer1, then the elliptic curve may or may not be 353 verifiably pseudorandomly according to whether curve.seed (see 354 paragraph 2.1.1.2.3) is present, and the base point P (see paragraph 355 2.1.1.2.4) is not generated verifiably pseudorandomly. If version is 356 ecdpVer2, then the curve and the base point P shall be generated 357 verifiably pseudorandomly, and curve.seed shall be present. If 358 version is ecdpVer3, then the curve is not generated verifiably 359 pseudorandomly but the base point P shall be generated verifiably 360 pseudorandomly from curve.seed, which shall be present. 362 SpecifiedCurveVersion is extensible and other documents can specify 363 additional values for SpecifiedCurveVersion. 365 Implementations of this document MUST support ecpVer1. 367 2.1.1.2.2. Field Identifiers 369 The fieldID field in SpecifiedCurve is of FieldID type. Finite fields 370 are represented by values of the parameterized type FieldID, 371 constrained to the values of the objects defined in the information 372 object set FieldTypes. 374 The type FIELD-ID is defined by the following: 376 FIELD-ID ::= TYPE-IDENTIFIER 378 The FieldID parameterized type is defined as follows: 380 FieldID { FIELD-ID:IOSet } ::= SEQUENCE { 381 fieldType FIELD-ID.&id({IOSet}), 382 parameters FIELD-ID.&Type({IOSet}{@fieldType}) 383 } 385 Field types are given in the following information object set: 387 FieldTypes FIELD-ID ::= { 388 { Prime-p IDENTIFIED BY prime-field } | 389 { Characteristic-two IDENTIFIED BY characteristic-two-field }, 390 ... -- Extensible 391 } 393 Two FieldTypes are defined herein: prime-p (see paragraph 394 2.1.1.2.2.1) and characteristic-two (see paragraph 2.1.1.2.2.2). 395 Implementations claiming conformance to this specification MUST 396 support the prime-p field type and MAY support the characteristic-two 397 field type. FieldTypes is extensible and other documents can specify 398 additional values for FieldTypes. 400 2.1.1.2.2.1. Prime-p 402 A prime finite field is specified in FieldID.fieldType by the 403 following object identifier: 405 prime-field OBJECT IDENTIFIER ::= { 406 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } 408 The prime finite field parameters specified in FIELD-ID parameters 409 has the following ASN.1 structure: 411 Prime-p ::= INTEGER 413 Prime-p is an integer which is the size of the field. 415 2.1.1.2.2.2. Characteristic-two 417 A characteristic-two finite field is specified in FieldID.fieldType 418 by the following object identifier: 420 characteristic-two-field OBJECT IDENTIFIER ::= { 421 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } 423 The characteristic-two finite field parameters specified in 424 FieldID.parameters have the following ASN.1 structure: 426 Characteristic-two ::= SEQUENCE { 427 m INTEGER, -- Field size 2^m 428 basis CHARACTERISTIC-TWO.&id({BasisTypes}), 429 parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) 430 } 432 The fields in Characteristic-two have the following meanings: 434 m is the size of the field. 436 basis is the type of basis used to express elements of the field. 438 parameters is the polynomial used to generate the field. The 439 parameters vary based on the basis. 441 The type CHARACTERISTIC-TWO is defined by the following: 443 CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER 445 The characteristic-two field basis types are given in the following 446 information object set: 448 BasisTypes CHARACTERISTIC-TWO ::= { 449 { NULL IDENTIFIED BY gnBasis } | 450 { Trinomial IDENTIFIED BY tpBasis } | 451 { Pentanomial IDENTIFIED BY ppBasis }, 452 ... -- Extensible 453 } 455 Three basis types are defined herein: normal bases, trinomial bases, 456 and pentanomial bases. Implementation claiming conformance to this 457 document MUST support normal basis and MAY support trimonial and 458 pentanomial bases. BasisTypes is extensible and other documents can 459 specify additional values for BasisTypes. 461 Normal bases are specified in the basis field by the object 462 identifier: 464 gnBasis OBJECT IDENTIFIER ::= { 465 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) 466 characteristic-two-basis(2) 1 } 468 A normal base has NULL parameters. 470 A trinomial base specifies the degree of the middle term in the 471 defining trinomial. A trinomial base is identified in the basis field 472 by the object identifier: 474 tpBasis OBJECT IDENTIFIER ::= { 475 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) 476 characteristic-two-basis(2) 2 } 478 A trinomial base has the following parameters: 480 Trinomial ::= INTEGER 482 A pentanomial base specifies the degrees of the three middle terms in 483 the defining pentanomial. A pentanomial base is identified in the 484 basis field by the object identifier: 486 ppBasis OBJECT IDENTIFIER ::= { 487 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) 488 characteristic-two-basis(2) 3 } 490 A pentanomial base has the following parameters: 492 Pentanomial ::= SEQUENCE { 493 k1 INTEGER, -- k1 > 0 494 k2 INTEGER, -- k2 > k1 495 k3 INTEGER -- k3 > k2 496 } 498 2.1.1.2.3. Curve 500 The curve field in SpecifiedCurve is of Curve type. Curve uses the 501 following ASN.1 structure: 503 Curve ::= SEQUENCE { 504 a FieldElement, 505 b FieldElement, 506 seed BIT STRING OPTIONAL 507 -- Shall be present if used in SpecifiedCurve 508 -- with version of ecdpVer2 or ecdpVer3 509 } 511 FieldElement ::= OCTET STRING 513 The fields in Curve have the following meanings: 515 a and b are the coefficients a and b, respectively, of the 516 elliptic curve E. Each coefficient, a and b, shall be represented 517 as a value of type FieldElement. Conversion routines for field 518 element to octet string are found in [SEC1]. 520 seed is an optional parameter that is used to derive the 521 coefficients of a randomly generated elliptic curve. seed MUST 522 be present if SpecifiedECDomain is either ecdpVer2 or ecdpVer3. 524 2.1.1.2.4. Base 526 The base field in SpecifiedCurve is of ECPoint type. ECPoint uses 527 the following ASN.1 syntax: 529 ECPoint ::= OCTET STRING 531 The contents of ECPoint is the octet string representation of an 532 elliptic curve point. Conversion routines for point to octet string 533 are found in [SEC1]. Note that these octet strings may represent an 534 elliptic curve point in compressed or uncompressed form. 535 Implementations that support elliptic curve according to this 536 document MUST support the uncompressed form and MAY support the 537 compressed form. 539 2.1.1.2.5. Hash 541 The hash field in SpecifiedCurve is of HashAlgorithm type. 542 HashAlgorithm uses the following ASN.1 syntax: 544 HashAlgorithm ::= AlgorithmIdentifier {{HashFunctions}} 546 HashAlgorithm is restricted to the HashFunctions parameterized type, 547 which uses the following ASN.1 structure: 549 HashFunctions ALGORITHM ::= { 550 sha1 | 551 sha224 | 552 sha256 | 553 sha384 | 554 sha512, 555 ... -- Extensible 556 } 558 The SHA1 [SHS] algorithm is defined as follows: 560 sha1 ALGORITHM ::= { 561 OID id-sha1 PARMS NULL } 563 The algorithm identifier is: 565 id-sha1 OBJECT IDENTIFIER ::= { 566 iso(1) identified-organization(3) oiw(14) secsig(3) 567 algorithm(2) 26 } 569 The SHA224 [SHS] algorithm is defined as follows: 571 sha224 ALGORITHM ::= { 572 OID id-sha224 PARMS NULL } 574 It has the following object identifier: 576 id-sha224 OBJECT IDENTIFIER ::= { 577 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 578 csor(3) nistalgorithm(4) hashalgs(2) 4 } 580 The SHA256 [SHS] algorithm is defined as follows: 582 sha256 ALGORITHM ::= { 583 OID id-sha256 PARMS NULL } 585 The algorithm identifier is: 587 id-sha256 OBJECT IDENTIFIER ::= { 588 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 589 csor(3) nistalgorithm(4) hashalgs(2) 1 } 591 The SHA384 [SHS] algorithm is defined as follows: 593 sha384 ALGORITHM ::= { 594 OID id-sha384 PARMS NULL } 596 The algorithm identifier is: 598 id-sha384 OBJECT IDENTIFIER ::= { 599 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 600 csor(3) nistalgorithm(4) hashalgs(2) 2 } 602 The SHA512 [SHS] algorithm is defined as follows: 604 sha512 ALGORITHM ::= { 605 OID id-sha512 PARMS NULL } 607 The algorithm identifier is: 609 id-sha512 OBJECT IDENTIFIER ::= { 610 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 611 csor(3) nistalgorithm(4) hashalgs(2) 3 } 613 An implementation of this document SHOULD accept values of the 614 parameterized type HashAlgorithm that have no parameters (also called 615 absent) and values that have NULL parameters. These values SHALL be 616 treated equally. (Of course, future extensions to the type parameter 617 HashFunctions might include information objects whose parameters 618 field is more meaningful.) An implementation of this document SHOULD 619 omit (leave absent) the parameters unless the recipient 620 implementation is unable to process absent parameters correctly. 622 2.1.2. Restricted Algorithm Identifiers and Parameters 624 Algorithms used with elliptic curve cryptography fall in to different 625 categories: signature and key agreement algorithms. ECDSA uses the 626 ecPublicKey described in 2.1.1. Two sets of key agreement algorithms 627 are identified herein: the Elliptic Curve Diffie-Hellman (ECDH) key 628 agreement scheme and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) 629 key agreement scheme. All algorithms are identified by an OID and 630 have PARMS. The OID varies based on the algorithm but the PARMS are 631 always ECParameters (see paragraph 2.1.1). 633 The ECDH is defined as follows: 635 ecDH ALGORITHM ::= { 636 OID id-ecDH PARMS ECParameters } 638 The algorithm identifier is: 640 id-ecDH OBJECT IDENTIFIER ::= { 641 iso(1) identified-organization(3) certicom(132) schemes(1) 642 ecdh(12) } 644 The ECMQV is defined as follows: 646 ecMQV ALGORITHM ::= { 647 OID id-ecMQV PARMS ECParameters } 649 The algorithm identifier is: 651 id-ecMQV OBJECT IDENTIFIER ::= { 652 iso(1) identified-organization(3) certicom(132) schemes(1) 653 ecmqv(13) } 655 2.2. Subject Public Key 657 The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key. 658 Implementations of elliptic curve cryptography according to this 659 document MUST support the uncompressed form and MAY support the 660 compressed form of the ECC public key. As specified in [SEC1]: 662 The first byte of the key indicates whether the key is compressed 663 or uncompressed. 665 The elliptic curve public key (a value of type ECPoint which is 666 an OCTET STRING) is mapped to a subjectPublicKey (a value of type 667 BIT STRING) as follows: the most significant bit of the OCTET 668 STRING value becomes the most significant bit of the BIT STRING 669 value, and so on; the least significant bit of the OCTET STRING 670 becomes the least significant bit of the BIT STRING. 672 3. KeyUsage Bits 674 If the keyUsage extension is present in a CA certificate that 675 indicates id-ecPublicKey in subjectPublicKeyInfo, any combination of 676 the following values MAY be present: 678 digitalSignature; 679 nonRepudiation; 680 keyAgreement; 681 keyCertSign; and 682 cRLSign. 684 If the CA certificate keyUsage extension asserts keyAgreement then it 685 MAY assert either encipherOnly or decipherOnly. However, this 686 specification RECOMMENDS that if keyCertSign or cRLSign is present, 687 keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present. 689 If the keyUsage extension is present in an EE certificate that 690 indicates id-ecPublicKey in subjectPublicKeyInfo, any combination of 691 the following values MAY be present: 693 digitalSignature; 694 nonRepudiation; and 695 keyAgreement. 697 If the EE certificate keyUsage extension asserts keyAgreement then it 698 MAY assert either encipherOnly or decipherOnly. 700 If the keyUsage extension is present in a certificate that indicates 701 ecDH or ecMQV in subjectPublicKeyInfo, keyAgreement MUST be present 702 and digitalSignature, nonRepudiation, keyTransport, keyCertSign, and 703 cRLSign MUST NOT be present. If this certificate keyUsage extension 704 asserts keyAgreement then it MAY assert either encipherOnly or 705 decipherOnly. 707 4. Security Considerations 709 The security considerations in [RFC3279] apply. No new security 710 considerations are introduced by this document. 712 5. IANA Considerations 714 None. Please remove this section prior to publication as an RFC. 716 6. References 718 6.1. Normative References 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, March 1997. 723 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 724 X.509 Public Key Infrastructure Certificate and 725 Certification Revocation List (CRL) Profile", RFC 3280, 726 April 2002. 728 [SHS] National Institute of Standards and Technology (NIST), 729 FIPS Publication 180-2: Secure Hash Standard, 2002. 731 [SEC1] Standards for Efficient Cryptography, "SEC 1: Elliptic 732 Curve Cryptography", Version 1.0, September 2000. 734 [X.680] ITU-T Recommendation X.680: Information Technology - 735 Abstract Syntax Notation One, 1997. 737 [X.681] ITU-T Recommendation X.680: Information Technology - 738 Abstract Syntax Notation One: Information Object 739 Spcification, 1997. 741 6.2. Informative References 743 [RFC3279] Polk, W., Housley, R. and L. Bassham, "Algorithm 744 Identifiers for the Internet X.509 Public Key 745 Infrastructure", RFC 3279, April 2002. 747 Appendix A. ASN.1 Module 749 Appendix A.1 provides the normative ASN.1 definitions for the 750 structures described in this specification using ASN.1 as defined in 751 [X.680,X.681]. 753 PKIXECCSubPubKeyInfo { iso(1) identified-organization(3) dod(6) 754 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) TBD } 756 DEFINITIONS EXPLICIT TAGS ::= 758 BEGIN 760 -- EXPORTS ALL 762 -- IMPORTS NONE 764 SubjectPublicKeyInfo ::= SEQUENCE { 765 algorithm AlgorithmIdentifier {{ECPKAlgorithms}}, 766 subjectPublicKey BIT STRING 767 } 768 ALGORITHM ::= CLASS { 769 &id OBJECT IDENTIFIER UNIQUE, 770 &Type OPTIONAL 771 } 772 WITH SYNTAX { OID &id [PARMS &Type] } 774 AlgorithmIdentifier {ALGORITHM:IOSet} ::= SEQUENCE { 775 algorithm ALGORITHM.&id({IOSet}), 776 parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL 777 } 779 ECPKAlgorithms ALGORITHM ::= { 780 ecPublicKeyType | 781 ecDH | 782 ecMQV, 783 ... -- Extensible 784 } 786 -- Sec 2.1.1 Unrestricted Algorithms and Parameters (including ECDSA) 788 ecPublicKeyType ALGORITHM ::= { 789 OID id-ecPublicKey PARMS ECParameters } 791 id-ecPublicKey OBJECT IDENTIFIER ::= { 792 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } 794 -- Sec 2.1.2 Restricted Algorithms and Parameters 796 ecDH ALGORITHM ::= { 797 OID id-ecDH PARMS ECParameters } 799 id-ecDH OBJECT IDENTIFIER ::= { 800 iso(1) identified-organization(3) certicom(132) schemes(1) 801 ecdh(12) } 803 -- Sec 2.1.2 Restricted Algorithms and Parameters 805 ecMQV ALGORITHM ::= { 806 OID id-ecMQV PARMS ECParameters } 808 id-ecMQV OBJECT IDENTIFIER ::= { 809 iso(1) identified-organization(3) certicom(132) schemes(1) 810 ecmqv(13) } 812 -- Parameters for both Restricted and Unrestricted 814 ECParameters ::= CHOICE { 815 namedCurve CURVE.&id({NamedCurve}), 816 specifiedCurve SpecifiedCurve, 817 implicitCurve NULL 818 } 820 -- Sec 2.1.1.1 Named Curve 822 CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } 823 WITH SYNTAX { ID &id } 825 NamedCurve CURVE ::= { 826 { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | 827 { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | 828 { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | 829 { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | 830 { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 }, 831 ... -- Extensible 832 } 834 secp192r1 OBJECT IDENTIFIER ::= { 835 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 836 curves(3) prime(1) 1 } 838 sect163k1 OBJECT IDENTIFIER ::= { 839 iso(1) identified-organization(3) certicom(132) curve(0) 1 } 841 sect163r2 OBJECT IDENTIFIER ::= { 842 iso(1) identified-organization(3) certicom(132) curve(0) 15 } 844 secp224r1 OBJECT IDENTIFIER ::= { 845 iso(1) identified-organization(3) certicom(132) curve(0) 33 } 847 sect233k1 OBJECT IDENTIFIER ::= { 848 iso(1) identified-organization(3) certicom(132) curve(0) 26 } 850 sect233r1 OBJECT IDENTIFIER ::= { 851 iso(1) identified-organization(3) certicom(132) curve(0) 27 } 853 secp256r1 OBJECT IDENTIFIER ::= { 854 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 855 curves(3) prime(1) 7 } 857 sect283k1 OBJECT IDENTIFIER ::= { 858 iso(1) identified-organization(3) certicom(132) curve(0) 16 } 860 sect283r1 OBJECT IDENTIFIER ::= { 861 iso(1) identified-organization(3) certicom(132) curve(0) 17 } 863 secp384r1 OBJECT IDENTIFIER ::= { 864 iso(1) identified-organization(3) certicom(132) curve(0) 34 } 866 sect409k1 OBJECT IDENTIFIER ::= { 867 iso(1) identified-organization(3) certicom(132) curve(0) 36 } 869 sect409r1 OBJECT IDENTIFIER ::= { 870 iso(1) identified-organization(3) certicom(132) curve(0) 37 } 872 secp521r1 OBJECT IDENTIFIER ::= { 873 iso(1) identified-organization(3) certicom(132) curve(0) 35 } 875 sect571k1 OBJECT IDENTIFIER ::= { 876 iso(1) identified-organization(3) certicom(132) curve(0) 38 } 878 sect571r1 OBJECT IDENTIFIER ::= { 879 iso(1) identified-organization(3) certicom(132) curve(0) 39 } 881 -- Sec 2.1.1.2 Specified Curve 883 SpecifiedCurve ::= SEQUENCE { 884 version SpecifiedCurveVersion 885 ( ecpVer1 | ecpVer2 | ecpVer3 ), 886 fieldID FieldID {{FieldTypes}}, 887 curve Curve, -- Curve E 888 base ECPoint, -- Base point P 889 order INTEGER, -- Order n of the base point 890 cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n 891 hash HashAlgorithm OPTIONAL, 892 ... -- Extensible 893 } 895 SpecifiedCurveVersion ::= INTEGER { 896 ecpVer1(1), 897 ecpVer2(2), 898 ecpVer3(3) 899 } 901 FIELD-ID ::= TYPE-IDENTIFIER 903 FieldID { FIELD-ID:IOSet } ::= SEQUENCE { 904 fieldType FIELD-ID.&id({IOSet}), 905 parameters FIELD-ID.&Type({IOSet}{@fieldType}) 906 } 907 FieldTypes FIELD-ID ::= { 908 { Prime-p IDENTIFIED BY prime-field } | 909 { Characteristic-two IDENTIFIED BY characteristic-two-field }, 910 ... -- Extensible 911 } 913 prime-field OBJECT IDENTIFIER ::= { 914 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } 916 Prime-p ::= INTEGER 918 characteristic-two-field OBJECT IDENTIFIER ::= { 919 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } 921 Characteristic-two ::= SEQUENCE { 922 m INTEGER, -- Field size 2^m 923 basis CHARACTERISTIC-TWO.&id({BasisTypes}), 924 parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) 925 } 927 CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER 929 BasisTypes CHARACTERISTIC-TWO ::= { 930 { NULL IDENTIFIED BY gnBasis } | 931 { Trinomial IDENTIFIED BY tpBasis } | 932 { Pentanomial IDENTIFIED BY ppBasis }, 933 ... -- Extensible 934 } 936 gnBasis OBJECT IDENTIFIER ::= { 937 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) 938 characteristic-two-basis(2) 1 } 940 tpBasis OBJECT IDENTIFIER ::= { 941 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) 942 characteristic-two-basis(2) 2 } 944 Trinomial ::= INTEGER 946 ppBasis OBJECT IDENTIFIER ::= { 947 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) 948 characteristic-two-basis(2) 3 } 950 Pentanomial ::= SEQUENCE { 951 k1 INTEGER, -- k1 > 0 952 k2 INTEGER, -- k2 > k1 953 k3 INTEGER -- k3 > k2 954 } 956 Curve ::= SEQUENCE { 957 a FieldElement, 958 b FieldElement, 959 seed BIT STRING OPTIONAL 960 -- Shall be present if used in SpecifiedCurve 961 -- with version of ecdpVer2 or ecdpVer3 962 } 964 FieldElement ::= OCTET STRING 966 ECPoint ::= OCTET STRING 968 HashAlgorithm ::= AlgorithmIdentifier {{HashFunctions}} 970 HashFunctions ALGORITHM ::= { 971 sha1 | 972 sha224 | 973 sha256 | 974 sha384 | 975 sha512, 976 ... -- Extensible 977 } 979 sha1 ALGORITHM ::= { 980 OID id-sha1 PARMS NULL } 982 id-sha1 OBJECT IDENTIFIER ::= { 983 iso(1) identified-organization(3) oiw(14) secsig(3) 984 algorithm(2) 26 } 986 sha224 ALGORITHM ::= { 987 OID id-sha224 PARMS NULL } 989 id-sha224 OBJECT IDENTIFIER ::= { 990 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 991 csor(3) nistalgorithm(4) hashalgs(2) 4 } 993 sha256 ALGORITHM ::= { 994 OID id-sha256 PARMS NULL } 996 id-sha256 OBJECT IDENTIFIER ::= { 997 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 998 csor(3) nistalgorithm(4) hashalgs(2) 1 } 1000 sha384 ALGORITHM ::= { 1001 OID id-sha384 PARMS NULL } 1003 id-sha384 OBJECT IDENTIFIER ::= { 1004 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1005 csor(3) nistalgorithm(4) hashalgs(2) 2 } 1007 sha512 ALGORITHM ::= { 1008 OID id-sha512 PARMS NULL } 1010 id-sha512 OBJECT IDENTIFIER ::= { 1011 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1012 csor(3) nistalgorithm(4) hashalgs(2) 3 } 1014 END 1016 Authors' Addresses 1018 Sean Turner 1020 IECA, Inc. 1021 3057 Nutley Street, Suite 106 1022 Fairfax, VA 22031 1023 USA 1025 EMail: turners@ieca.com 1027 Kelvin Yiu 1029 Microsoft 1030 One Microsoft Way 1031 Redmond, WA 98052-6399 1032 USA 1034 Email: kelviny@microsoft.com 1036 Daniel R. L. Brown 1038 Certicom Corp 1039 5520 Explorer Drive #400 1040 Mississauga, ON L4W 5L1 1041 CANADA 1043 EMail: dbrown@certicom.com 1045 Russ Housley 1047 Vigil Security, LLC 1048 918 Spring Knoll Drive 1049 Herndon, VA 20170 1050 USA 1052 EMail: housley@vigilsec.com 1054 Tim Polk 1056 NIST 1057 Building 820, Room 426 1058 Gaithersburg, MD 20899 1059 USA 1061 EMail: wpolk@nist.gov 1063 Full Copyright Statement 1065 Copyright (C) The IETF Trust (2008). 1067 This document is subject to the rights, licenses and restrictions 1068 contained in BCP 78, and except as set forth therein, the authors 1069 retain all their rights. 1071 This document and the information contained herein are provided on an 1072 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1073 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1074 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1075 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1076 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1077 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1079 Intellectual Property 1081 The IETF takes no position regarding the validity or scope of any 1082 Intellectual Property Rights or other rights that might be claimed to 1083 pertain to the implementation or use of the technology described in 1084 this document or the extent to which any license under such rights 1085 might or might not be available; nor does it represent that it has 1086 made any independent effort to identify any such rights. Information 1087 on the procedures with respect to rights in RFC documents can be 1088 found in BCP 78 and BCP 79. 1090 Copies of IPR disclosures made to the IETF Secretariat and any 1091 assurances of licenses to be made available, or the result of an 1092 attempt made to obtain a general license or permission for the use of 1093 such proprietary rights by implementers or users of this 1094 specification can be obtained from the IETF on-line IPR repository at 1095 http://www.ietf.org/ipr. 1097 The IETF invites any interested party to bring to its attention any 1098 copyrights, patents or patent applications, or other proprietary 1099 rights that may cover technology that may be required to implement 1100 this standard. Please address the information to the IETF at 1101 ietf-ipr@ietf.org. 1103 Acknowledgment 1105 Funding for the RFC Editor function is provided by the IETF 1106 Administrative Support Activity (IASA).