idnits 2.17.1 draft-ietf-pkix-ecc-subpubkeyinfo-01.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 815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 826. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 833. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 839. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3279]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The abstract seems to indicate that this document updates RFC3279, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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. 'SHA2' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group Sean Turner, IECA 2 Internet Draft Daniel Brown, Certicom 3 Intended Status: Standard Track Kelvin Yiu, Microsoft 4 Expires: July 2, 2008 Russ Housley, Vigil Security 5 Tim Polk, NIST 6 22 January, 2008 8 Elliptic Curve Cryptography Subject Public Key Information 9 draft-ietf-pkix-ecc-subpubkeyinfo-01.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 July 22, 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 [RFC3279]. 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.................... 9 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). This document specifies the encoding formats for public keys 77 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 Elliptic Curve Menezes-Qu-Vanstone (ECMQV) family 84 schemes. 86 Two methods for specifying the algorithms that can be used with the 87 subjectPublicKey are defined. One method does not restrict the 88 algorithms the key can be used with while the other method does 89 restrict the algorithms the key can be used with. To promote 90 interoperability, this document indicates which is required. 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. 99 Specification of all EC parameters is complicated with many options. 100 To promote interoperability, this document indicates which options 101 are required. 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 subjectPublilcKeyInfo 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 are 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 Public Key Algorithm Identifier 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 ECPKCAlgorithms parameterized type, which uses the following ASN.1 163 structure: 165 ECPKAlgorithms ALGORITHM ::= { 166 ecPublicKeyType | 167 ecDH | 168 ecMQV 169 } 171 The algorithms defined are as follows: 173 ecPublicKeyType indicates that the algorithms that can be used 174 with the subject public key are not restricted (i.e., they are 175 unrestricted). The key is only restricted by the values 176 indicated in the key usage certificate extension. The 177 ecPublicKeyType MUST be supported. See paragraph 2.1.1. This 178 value is also used when a key is used with ECDSA. 180 ecDH and ecMQV MAY be supported. See paragraph 2.1.2. 182 2.1.1. Unrestricted Identifiers and Parameters 184 The "unrestricted" algorithm is defined as follows: 186 ecPublicKeyType ALGORITHM ::= { 187 OID id-ecPublicKey PARMS ECParameters } 189 The algorithm identifier is: 191 id-ecPublicKey OBJECT IDENTIFIER ::= { 192 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } 194 The parameters for id-ecPublicKey are as follows: 196 ECParameters ::= CHOICE { 197 namedCurve CURVE.&id({NamedCurve}), 198 specifiedCuve SpecifiedCurve, 199 implicitCurve NULL 200 } 202 The fields in ECParameters have the following meanings: 204 namedCurve allows all the required values for a particular set of 205 elliptic curve domain parameters to be represented by an object 206 identifier. This choice MUST be supported. See paragraph 207 2.1.1.1. 209 specifiedCurve allows all of the required values to be explicitly 210 specified. This choice MAY be supported, and if it is 211 implicitCurve MUST also be supported. See paragraph 2.1.1.2. 213 implicitCurve allows the elliptic curve parameters to be 214 inherited from the issuer's certificate. This choice MAY be 215 supported, but if subordinate certificates use the same 216 namedCurve as their superior, then the subordinate certificate 217 MUST use the namedCurve option. That is implicitCurve is only 218 supported if the superior doesn't use the namedCurve option. 220 2.1.1.1. Named Curve 222 The namedCurve field in ECParamaters uses the class CURVE to 223 constrain the set of legal values from NamedCurve, which are object 224 identifiers: 226 CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } 227 WITH SYNTAX { ID &id } 229 The NamedCurve parameterized type is defined as follows: 231 NamedCurve CURVE ::= { 232 { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | 233 { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | 234 { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | 235 { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | 236 { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | 237 ... -- Extensible 238 } 240 The curve identifiers are the fifteen NIST recommended curves: 242 secp192r1 OBJECT IDENTIFIER ::= { 243 ansi-x9-62 curves(3) prime(1) 1 } 245 sect163k1 OBJECT IDENTIFIER ::= { 246 iso(1) identified-organization(3) certicom(132) curve(0) 1 } 248 sect163r2 OBJECT IDENTIFIER ::= { 249 iso(1) identified-organization(3) certicom(132) curve(0) 15 } 251 secp224r1 OBJECT IDENTIFIER ::= { 252 iso(1) identified-organization(3) certicom(132) curve(0) 33 } 254 sect233k1 OBJECT IDENTIFIER ::= { 255 iso(1) identified-organization(3) certicom(132) curve(0) 26 } 257 sect233r1 OBJECT IDENTIFIER ::= { 258 iso(1) identified-organization(3) certicom(132) curve(0) 27 } 260 secp256r1 OBJECT IDENTIFIER ::= { 261 ansi-x9-62 curves(3) prime(1) 7 } 263 sect283k1 OBJECT IDENTIFIER ::= { 264 iso(1) identified-organization(3) certicom(132) curve(0) 16 } 266 sect283r1 OBJECT IDENTIFIER ::= { 267 iso(1) identified-organization(3) certicom(132) curve(0) 17 } 269 secp384r1 OBJECT IDENTIFIER ::= { 270 iso(1) identified-organization(3) certicom(132) curve(0) 34 } 272 sect409k1 OBJECT IDENTIFIER ::= { 273 iso(1) identified-organization(3) certicom(132) curve(0) 36 } 275 sect409r1 OBJECT IDENTIFIER ::= { 276 iso(1) identified-organization(3) certicom(132) curve(0) 37 } 278 secp521r1 OBJECT IDENTIFIER ::= { 279 iso(1) identified-organization(3) certicom(132) curve(0) 35 } 281 sect571k1 OBJECT IDENTIFIER ::= { 282 iso(1) identified-organization(3) certicom(132) curve(0) 38 } 284 sect571r1 OBJECT IDENTIFIER ::= { 285 iso(1) identified-organization(3) certicom(132) curve(0) 39 } 287 2.1.1.2. Specified Curve 289 The specified field in ECParameters is the SpecifiedCurve type. 290 SpecifiedCurve uses the following ASN.1 structure: 292 SpecifiedCurve ::= SEQUENCE { 293 version SpecifiedCurveVersion 294 ( ecpVer1 | ecpVer2 | ecpVer3 ), 295 fieldID FieldID {{FieldTypes}}, 296 curve Curve, -- Curve E 297 base ECPoint, -- Base point P 298 order INTEGER, -- Order n of the base point 299 cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n 300 hash HashAlgorithm OPTIONAL, 301 ... -- Extensible 302 } 304 The fields in SpecifiedCurve have the following meaning: 306 version specifies the version number of the elliptic curve 307 parameters. See paragraph 2.1.1.2.1. 309 fieldID identifies the finite field over which the elliptic 310 curve, specified in the curve field, is defined. See paragraph 311 2.1.1.2.2. 313 curve specifies the elliptic curve E. See paragraph 2.1.1.2.3. 315 base specifies the base point P of the elliptic curve E, 316 specified in the curve field. See paragraph 2.1.1.2.4. 318 order specifies the order n of the base point P, specified in 319 base. 321 cofactor is the order of the curve, specified in the curve field, 322 divided by the order, specified in the order field, of the base 323 point, specified in the base field (i.e., h = #E(Fq)/n). 324 Inclusion of the cofactor is optional; however, it is strongly 325 RECOMMENDED that that the cofactor be included in order to 326 facilitate interoperability between implementations. 328 hash is the hash algorithm used to generate the elliptic curve E, 329 specified in the curve field, and/or base point P, specified in 330 the base field, verifiably psuedorandomly. If the hash field is 331 omitted, then the hash algorithm shall be SHA1. See paragraph 332 2.1.1.2.5. 334 SpecifiedCurve is extensible and other documents may specify 335 additional fields for this ASN.1 structure. 337 2.1.1.2.1. Specified Curve Version 339 The version field in SpecifiedCurve is the SpecifiedCurveVersion 340 type. SpecifiedCurveVersion uses the following ASN.1 structure: 342 SpecifiedCurveVersion ::= INTEGER { 343 ecpVer1(1), 344 ecpVer2(2), 345 ecpVer3(3), 346 ... -- Extensible 347 } 349 SpecfifiedCurveVersion is ecdpVer1, ecdpVer2, or ecdpVer3. If 350 version is ecdpVer1, then the elliptic curve may or may not be 351 verifiably psuedorandomly according to whether curve.seed (see 352 paragraph 2.1.1.2.3) is present, and the base point G (see paragraph 353 2.1.1.2.4) is not generated verifiably psuedorandomly. If version is 354 ecdpVer2, then the curve and the base point G shall be generated 355 verifiably psuedorandomly, and curve.seed shall be present. If 356 version is ecdpVer3, then the curve is not generated verifiably 357 psuedorandomly but the base point G shall be generated verifiably 358 psuedorandomly from curve.seed, which shall be present. 360 SpecifiedCurveVersion is extensible and other documents can specify 361 additional values for SpecifiedCurveVersion. 363 Implementations of this document MUST support ecpVer1. 365 2.1.1.2.2. Field Identifiers 367 The fieldID field in SpecifiedCurve is the FieldID type. Finite 368 fields are represented by values of the parameterized type FieldID, 369 constrained to the values of the objects defined in the information 370 object set FieldTypes. 372 The type FIELD-ID is defined by the following: 374 FIELD-ID ::= TYPE-IDENTIFIER 376 The FieldID parameterized type is defined as follows: 378 FieldID { FIELD-ID:IOSet } ::= SEQUENCE { 379 fieldType FIELD-ID.&id({IOSet}), 380 parameters FIELD-ID.&Type({IOSet}{@fieldType}) 381 } 383 Field types are given in the following information object set: 385 FieldTypes FIELD-ID ::= { 386 { Prime-p IDENTIFIED BY prime-field } | 387 { Characteristic-two IDENTIFIED BY characteristic-two-field } | 388 ... -- Extensible 389 } 391 Two FieldTypes defined herein: prime-p (see paragraph 2.1.1.2.2.1) 392 and characteristic-two (see paragraph 2.1.1.2.2.2). Implementations 393 claiming conformance to this specification MUST support the prime-p 394 field type and MAY support the characteristic-two field type. 395 FieldTypes is extensible and other documents can specify additional 396 values for FieldTypes. 398 2.1.1.2.2.1. Prime-p 400 A prime finite field is specified in FieldID.fieldType by the 401 following object identifier: 403 prime-field OBJECT IDENTIFIER ::= { 404 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } 406 The prime finite field parameters specified in FIELD-ID parameters 407 has the following ASN.1 structure: 409 Prime-p ::= INTEGER 411 Prime-p is an integer which is the size of the field. 413 2.1.1.2.2.2. Characteristic-two 415 A characteristic-two finite field is specified in FieldID.fieldType 416 by the following object identifier: 418 characteristic-two-field OBJECT IDENTIFIER ::= { 419 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } 421 The characteristic-two finite field parameters specified in 422 FieldID.parameters have the following ASN.1 structure: 424 Characteristic-two ::= SEQUENCE { 425 m INTEGER, -- Field size 2^m 426 basis CHARACTERISTIC-TWO.&id({BasisTypes}), 427 parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) 428 } 430 The fields in Characteristic-two have the following meanings: 432 m is the size of the field. 434 basis is the type of basis used to express elements of the field. 436 parameters is the polynomial used to generate the field. The 437 parameters vary based on the basis. 439 The type CHARACTERISTIC-TWO is defined by the following: 441 CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER 443 The characteristic-two field basis types are given in the following 444 information object set: 446 BasisTypes CHARACTERISTIC-TWO ::= { 447 { NULL IDENTIFIED BY gnBasis } | 448 { Trinomial IDENTIFIED BY tpBasis } | 449 { Pentanomial IDENTIFIED BY ppBasis } | 450 ... -- Extensible 451 } 453 Three basis types are defined herein: normal bases, trinomial bases, 454 and pentanomial bases. Implementation claiming conformance to this 455 document MUST support normal basis and MAY support trimonial and 456 pentanomial bases. BasisTypes is extensible and other documents can 457 specify additional values for BasisTypes. 459 Normal bases are specified in the basis field by the object 460 identifier: 462 gnBasis OBJECT IDENTIFIER ::= { 463 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) 464 characteristic-two-basis(2) 1 } 466 A normal base has NULL parameters. 468 A trinomial base specifies the degree of the middle term in the 469 defining trinomial. A trinomial base is identified in the basis field 470 by the object identifier: 472 tpBasis OBJECT IDENTIFIER ::= { 473 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) 474 characteristic-two-basis(2) 2 } 476 A trinomial base has the following parameters: 478 Trinomial ::= INTEGER 480 A pentanomial base specifies the degrees of the three middle terms in 481 the defining pentanomial. A pentaomial base is identified in the 482 basis field by the object identifier: 484 ppBasis OBJECT IDENTIFIER ::= { 485 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) 486 characteristic-two-basis(2) 3 } 488 A pentanomial base has the following parameters: 490 Pentanomial ::= SEQUENCE { 491 k1 INTEGER, -- k1 > 0 492 k2 INTEGER, -- k2 > k1 493 k3 INTEGER -- k3 > k2 494 } 496 2.1.1.2.3. Curve 498 The curve field in SpecifiedCurve is the Curve type. Curve uses the 499 following ASN.1 structure: 501 Curve ::= SEQUENCE { 502 a FieldElement, 503 b FieldElement, 504 seed BIT STRING OPTIONAL 505 -- Shall be present if used in SpecifiedCurve 506 -- with version of ecdpVer2 or ecdpVer3 507 } 509 FieldElement ::= OCTET STRING 511 The fields in Curve have the following meanings: 513 a and b are the coefficients a and b, respectively, of the 514 elliptic curve E. Each coefficient, a and b, shall be represented 515 as a value of type FieldElement. Conversion routines for field 516 element to octet string are found in [SEC1]. Note that these 517 octet strings may represent an elliptic curve point in compressed 518 or uncompressed form. Implementations that support elliptic 519 curve according to this document MUST support the uncompressed 520 form and MAY support the compressed form. 522 seed is an optional parameter that is used to derive the 523 coefficients of a randomly generated elliptic curve. seed MUST 524 be present if SpecifiedECDomain is either ecdpVer2 or ecdpVer3. 526 2.1.1.2.4. Base 528 The base field in SpecifiedCurve is the ECPoint type. ECPoint uses 529 the following ASN.1 syntax: 531 ECPoint ::= OCTET STRING 533 The contents of ECPoint is the octet string representation of an 534 elliptic curve point. Conversion routines for point to octet string 535 are found in [SEC1]. 537 2.1.1.2.5. Hash 539 The hash field in SpecifiedCurve is the HashAlgorithm type. 540 HashAlgorithm use the following ASN.1 syntax: 542 HashAlgorithm ::= AlgorithmIdentifier {{HashFunctions}} 544 HashAlgorithm is restricted to the HashFunctions parameterized type, 545 which uses the following ASN.1 structure: 547 HashFunctions ALGORITHM ::= { 548 sha1 | 549 sha224 | 550 sha256 | 551 sha384 | 552 sha512 | 553 ... -- Extensible 554 } 556 The SHA1 [SHA2] algorithm is defined as follows: 558 sha1 ALGORITHM ::= { 559 OID id-sha1 PARMS NULL } 561 The algorithm identifier is: 563 id-sha1 OBJECT IDENTIFIER ::= { 564 iso(1) identified-organization(3) oiw(14) secsig(3) 565 algorithm(2) 26 } 567 The SHA224 [SHA2] algorithm is defined as follows: 569 sha224 ALGORITHM ::= { 570 OID id-sha224 PARMS NULL } 572 It has the following object identifier: 574 id-sha224 OBJECT IDENTIFIER ::= { 575 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 576 csor(3) nistalgorithm(4) hashalgs(2) 4 } 578 The SHA256 [SHA2] algorithm is defined as follows: 580 sha256 ALGORITHM ::= { 581 OID id-sha256 PARMS NULL } 583 The algorithm identifier is: 585 id-sha256 OBJECT IDENTIFIER ::= { 586 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 587 csor(3) nistalgorithm(4) hashalgs(2) 1 } 589 The SHA384 [SHA2] algorithm is defined as follows: 591 sha384 ALGORITHM ::= { 592 OID id-sha384 PARMS NULL } 594 The algorithm identifier is: 596 id-sha384 OBJECT IDENTIFIER ::= { 597 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 598 csor(3) nistalgorithm(4) hashalgs(2) 2 } 600 The SHA512 [SHA2] algorithm is defined as follows: 602 sha512 ALGORITHM ::= { 603 OID id-sha512 PARMS NULL } 605 The algorithm identifier is: 607 id-sha512 OBJECT IDENTIFIER ::= { 608 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 609 csor(3) nistalgorithm(4) hashalgs(2) 3 } 611 An implementation of this document SHOULD accept values of the 612 parameterized type HashAlgorithm that have no parameters (also called 613 absent) and values that have NULL parameters. These values SHALL be 614 treated equally. (Of course, future extensions to the type parameter 615 HashFunctions might include information objects whose parameters 616 field is more meaningful.) An implementation of this document SHOULD 617 omit (leave absent) the parameters unless the recipient 618 implementation is unable to process absent parameters correctly. 620 2.1.2. Restricted Algorithm Identifiers and Parameters 622 Algorithms used with EC fall in to different categories: signature 623 and key agreement algorithms. ECDSA uses the ecPublicKey described 624 in 2.1.1. Two sets of key agreement algorithms are identified herein: 625 Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme and 626 Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement scheme. All 627 algorithms are identified by an OID and have PARMS. The OID varies 628 based on the algorithm but the PARMS are always ECParameters (see 629 paragraph 2.1.1). 631 The ECDH is defined as follows: 633 ecDH ALGORITHM ::= { 634 OID TBD PARMS ECParameters } 636 The algorithm identifier is: 638 TBD OBJECT IDENTIFIER ::= { 639 TBD } 641 The ECMQV is defined as follows: 643 ecMQV ALGORITHM ::= { 644 OID TBD PARMS ECParameters } 646 The algorithm identifier is: 648 TBD OBJECT IDENTIFIER ::= { 649 TBD } 651 2.2. Subject Public Key 653 The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key. 654 Implementations that support elliptic curve according to this 655 document MUST support the uncompressed form and MAY support the 656 compressed form of the ECC public key. As specified in [SEC1]: 658 The first two bytes of the key indicate whether the key is 659 compressed or uncompressed. 661 The elliptic curve public key (a value of type ECPoint which is 662 an OCTET STRING) is mapped to a subjectPublicKey (a value of type 663 BIT STRING) as follows: the most significant bit of the OCTET 664 STRING value becomes the most significant bit of the BIT STRING 665 value, and so on; the least significant bit of the OCTET STRING 666 becomes the least significant bit of the BIT STRING. 668 3. KeyUsage Bits 670 If the keyUsage extension is present in a CA certificate that 671 indicates id-ecPublicKey in subjectPublicKeyInfo, any combination of 672 the following values MAY be present: 674 digitalSignature; 675 nonRepudiation; 676 keyAgreement; 677 keyCertSign; and 678 cRLSign. 680 If the CA certificate keyUsage extension asserts keyAgreement then it 681 MAY assert either encipherOnly or decipherOnly. However, this 682 specification RECOMMENDS that if keyCertSign or cRLSign is present, 683 keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present. 685 If the keyUsage extension is present in an EE certificate that 686 indicates id-ecPublicKey in subjectPublicKeyInfo, any combination of 687 the following values MAY be present: 689 digitalSignature; 690 nonRepudiation; and 691 keyAgreement. 693 If the EE certificate keyUsage extension asserts keyAgreement then it 694 MAY assert either encipherOnly or decipherOnly. However, this 695 specification RECOMMENDS that if cRLSign is present, then 696 keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present. 698 If the keyUsage extension is present in a certificate that indicates 699 ecDH or ecMQV in subjectPublicKeyInfo, keyAgreement MUST be present 700 and digitalSignature, nonRepudiation, keyTransport, keyCertSign, and 701 cRLSign MUST NOT be present. If this certificate keyUsage extension 702 asserts keyAgreement then it MAY assert either encipherOnly or 703 decipherOnly. 705 4. Security Considerations 707 The security considerations in [RFC3279] apply. No new security 708 considerations are introduced by this document. 710 5. IANA Considerations 712 None. Please remove this section prior to publication as an RFC. 714 6. References 716 6.1. Normative References 718 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 719 Requirement Levels", BCP 14, RFC 2119, March 1997. 721 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 722 X.509 Public Key Infrastructure Certificate and 723 Certification Revocation List (CRL) Profile", RFC 3280, 724 April 2002. 726 [SHA2] National Institute of Standards and Technology (NIST), 727 FIPS Publication 180-2: Secure Hash Standard, 1 August 728 2002. 730 [SEC1] Standards for Efficient Cryptography, "SEC 1: Elliptic 731 Curve Cryptography", Version 1.0, September 2000. 733 [X.680] ITU-T Recommendation X.680: Information Technology - 734 Abstract Syntax Notation One, 1997. 736 [X.681] ITU-T Recommendation X.680: Information Technology - Abstract 737 Syntax Notation One: Information Object Spcification, 738 1997. 740 6.2. Informative References 742 [RFC3279] Polk, W., Housley, R. and L. Bassham, "Algorithm 743 Identifiers for the Internet X.509 Public Key 744 Infrastructure", RFC 3279, April 2002. 746 Appendix A. ASN.1 Module 748 Appendix A.1 provides the normative ASN.1 definitions for the 749 structures described in this specification using ASN.1 as defined in 750 [X.680,X.681]. 752 To Be Supplied Later 754 Author's Addresses 756 Sean Turner 758 IECA, Inc. 759 3057 Nutley Street, Suite 106 760 Fairfax, VA 22031 761 USA 763 EMail: turners@ieca.com 765 Kelvin Yiu 767 Microsoft 768 One Microsoft Way 769 Redmond, WA 98052-6399 770 USA 772 Email: kelviny@microsoft.com 774 Daniel R. L. Brown 776 Certicom Corp 777 5520 Explorer Drive #400 778 Mississauga, ON L4W 5L1 779 CANADA 781 EMail: dbrown@certicom.com 783 Russ Housley 785 Vigil Security, LLC 786 918 Spring Knoll Drive 787 Herndon, VA 20170 788 USA 790 EMail: housley@vigilsec.com 792 Tim Polk 794 NIST 795 Building 820, Room 426 796 Gaithersburg, MD 20899 797 USA 799 EMail: wpolk@nist.gov 801 Full Copyright Statement 803 Copyright (C) The IETF Trust (2008). 805 This document is subject to the rights, licenses and restrictions 806 contained in BCP 78, and except as set forth therein, the authors 807 retain all their rights. 809 This document and the information contained herein are provided on an 810 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 811 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 812 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 813 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 814 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 815 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 817 Intellectual Property 819 The IETF takes no position regarding the validity or scope of any 820 Intellectual Property Rights or other rights that might be claimed to 821 pertain to the implementation or use of the technology described in 822 this document or the extent to which any license under such rights 823 might or might not be available; nor does it represent that it has 824 made any independent effort to identify any such rights. Information 825 on the procedures with respect to rights in RFC documents can be 826 found in BCP 78 and BCP 79. 828 Copies of IPR disclosures made to the IETF Secretariat and any 829 assurances of licenses to be made available, or the result of an 830 attempt made to obtain a general license or permission for the use of 831 such proprietary rights by implementers or users of this 832 specification can be obtained from the IETF on-line IPR repository at 833 http://www.ietf.org/ipr. 835 The IETF invites any interested party to bring to its attention any 836 copyrights, patents or patent applications, or other proprietary 837 rights that may cover technology that may be required to implement 838 this standard. Please address the information to the IETF at 839 ietf-ipr@ietf.org. 841 Acknowledgment 843 Funding for the RFC Editor function is provided by the IETF 844 Administrative Support Activity (IASA).