idnits 2.17.1 draft-ietf-pkix-ecc-subpubkeyinfo-03.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 819. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 830. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 837. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 843. 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 2 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 (February 21, 2008) is 5899 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: August 21, 2008 Tim Polk, NIST 6 February 21, 2008 8 Elliptic Curve Cryptography Subject Public Key Information 9 draft-ietf-pkix-ecc-subpubkeyinfo-03.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 August 21, 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..........................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......................................13 62 2.1.2. Restricted Algorithm Identifiers and Parameters.....15 63 2.2. Subject Public Key.......................................15 64 3. KeyUsage Bits.................................................16 65 4. Security Considerations.......................................16 66 5. IANA Considerations...........................................16 67 6. References....................................................17 68 6.1. Normative References.....................................17 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 ... -- Extensible 350 } 352 SpecfifiedCurveVersion is ecdpVer1, ecdpVer2, or ecdpVer3. If 353 version is ecdpVer1, then the elliptic curve may or may not be 354 verifiably pseudorandomly according to whether curve.seed (see 355 paragraph 2.1.1.2.3) is present, and the base point P (see paragraph 356 2.1.1.2.4) is not generated verifiably pseudorandomly. If version is 357 ecdpVer2, then the curve and the base point P shall be generated 358 verifiably pseudorandomly, and curve.seed shall be present. If 359 version is ecdpVer3, then the curve is not generated verifiably 360 pseudorandomly but the base point P shall be generated verifiably 361 pseudorandomly from curve.seed, which shall be present. 363 SpecifiedCurveVersion is extensible and other documents can specify 364 additional values for SpecifiedCurveVersion. 366 Implementations of this document MUST support ecpVer1. 368 2.1.1.2.2. Field Identifiers 370 The fieldID field in SpecifiedCurve is of FieldID type. Finite fields 371 are represented by values of the parameterized type FieldID, 372 constrained to the values of the objects defined in the information 373 object set FieldTypes. 375 The type FIELD-ID is defined by the following: 377 FIELD-ID ::= TYPE-IDENTIFIER 379 The FieldID parameterized type is defined as follows: 381 FieldID { FIELD-ID:IOSet } ::= SEQUENCE { 382 fieldType FIELD-ID.&id({IOSet}), 383 parameters FIELD-ID.&Type({IOSet}{@fieldType}) 384 } 386 Field types are given in the following information object set: 388 FieldTypes FIELD-ID ::= { 389 { Prime-p IDENTIFIED BY prime-field } | 390 { Characteristic-two IDENTIFIED BY characteristic-two-field } | 391 ... -- Extensible 392 } 394 Two FieldTypes are defined herein: prime-p (see paragraph 395 2.1.1.2.2.1) and characteristic-two (see paragraph 2.1.1.2.2.2). 396 Implementations claiming conformance to this specification MUST 397 support the prime-p field type and MAY support the characteristic-two 398 field type. FieldTypes is extensible and other documents can specify 399 additional values for FieldTypes. 401 2.1.1.2.2.1. Prime-p 403 A prime finite field is specified in FieldID.fieldType by the 404 following object identifier: 406 prime-field OBJECT IDENTIFIER ::= { 407 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } 409 The prime finite field parameters specified in FIELD-ID parameters 410 has the following ASN.1 structure: 412 Prime-p ::= INTEGER 414 Prime-p is an integer which is the size of the field. 416 2.1.1.2.2.2. Characteristic-two 418 A characteristic-two finite field is specified in FieldID.fieldType 419 by the following object identifier: 421 characteristic-two-field OBJECT IDENTIFIER ::= { 422 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } 424 The characteristic-two finite field parameters specified in 425 FieldID.parameters have the following ASN.1 structure: 427 Characteristic-two ::= SEQUENCE { 428 m INTEGER, -- Field size 2^m 429 basis CHARACTERISTIC-TWO.&id({BasisTypes}), 430 parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) 431 } 433 The fields in Characteristic-two have the following meanings: 435 m is the size of the field. 437 basis is the type of basis used to express elements of the field. 439 parameters is the polynomial used to generate the field. The 440 parameters vary based on the basis. 442 The type CHARACTERISTIC-TWO is defined by the following: 444 CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER 446 The characteristic-two field basis types are given in the following 447 information object set: 449 BasisTypes CHARACTERISTIC-TWO ::= { 450 { NULL IDENTIFIED BY gnBasis } | 451 { Trinomial IDENTIFIED BY tpBasis } | 452 { Pentanomial IDENTIFIED BY ppBasis } | 453 ... -- Extensible 454 } 456 Three basis types are defined herein: normal bases, trinomial bases, 457 and pentanomial bases. Implementation claiming conformance to this 458 document MUST support normal basis and MAY support trimonial and 459 pentanomial bases. BasisTypes is extensible and other documents can 460 specify additional values for BasisTypes. 462 Normal bases are specified in the basis field by the object 463 identifier: 465 gnBasis OBJECT IDENTIFIER ::= { 466 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) 467 characteristic-two-basis(2) 1 } 469 A normal base has NULL parameters. 471 A trinomial base specifies the degree of the middle term in the 472 defining trinomial. A trinomial base is identified in the basis field 473 by the object identifier: 475 tpBasis OBJECT IDENTIFIER ::= { 476 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) 477 characteristic-two-basis(2) 2 } 479 A trinomial base has the following parameters: 481 Trinomial ::= INTEGER 483 A pentanomial base specifies the degrees of the three middle terms in 484 the defining pentanomial. A pentanomial base is identified in the 485 basis field by the object identifier: 487 ppBasis OBJECT IDENTIFIER ::= { 488 iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) 489 characteristic-two-basis(2) 3 } 491 A pentanomial base has the following parameters: 493 Pentanomial ::= SEQUENCE { 494 k1 INTEGER, -- k1 > 0 495 k2 INTEGER, -- k2 > k1 496 k3 INTEGER -- k3 > k2 497 } 499 2.1.1.2.3. Curve 501 The curve field in SpecifiedCurve is of Curve type. Curve uses the 502 following ASN.1 structure: 504 Curve ::= SEQUENCE { 505 a FieldElement, 506 b FieldElement, 507 seed BIT STRING OPTIONAL 508 -- Shall be present if used in SpecifiedCurve 509 -- with version of ecdpVer2 or ecdpVer3 510 } 512 FieldElement ::= OCTET STRING 514 The fields in Curve have the following meanings: 516 a and b are the coefficients a and b, respectively, of the 517 elliptic curve E. Each coefficient, a and b, shall be represented 518 as a value of type FieldElement. Conversion routines for field 519 element to octet string are found in [SEC1]. Note that these 520 octet strings may represent an elliptic curve point in compressed 521 or uncompressed form. Implementations that support elliptic 522 curve according to this document MUST support the uncompressed 523 form and MAY support the compressed form. 525 seed is an optional parameter that is used to derive the 526 coefficients of a randomly generated elliptic curve. seed MUST 527 be present if SpecifiedECDomain is either ecdpVer2 or ecdpVer3. 529 2.1.1.2.4. Base 531 The base field in SpecifiedCurve is of ECPoint type. ECPoint uses 532 the following ASN.1 syntax: 534 ECPoint ::= OCTET STRING 536 The contents of ECPoint is the octet string representation of an 537 elliptic curve point. Conversion routines for point to octet string 538 are found in [SEC1]. Note that these octet strings may represent an 539 elliptic curve point in compressed or uncompressed form. 540 Implementations that support elliptic curve according to this 541 document MUST support the uncompressed form and MAY support the 542 compressed form. 544 2.1.1.2.5. Hash 546 The hash field in SpecifiedCurve is of HashAlgorithm type. 547 HashAlgorithm uses the following ASN.1 syntax: 549 HashAlgorithm ::= AlgorithmIdentifier {{HashFunctions}} 551 HashAlgorithm is restricted to the HashFunctions parameterized type, 552 which uses the following ASN.1 structure: 554 HashFunctions ALGORITHM ::= { 555 sha1 | 556 sha224 | 557 sha256 | 558 sha384 | 559 sha512 | 560 ... -- Extensible 561 } 563 The SHA1 [SHS] algorithm is defined as follows: 565 sha1 ALGORITHM ::= { 566 OID id-sha1 PARMS NULL } 568 The algorithm identifier is: 570 id-sha1 OBJECT IDENTIFIER ::= { 571 iso(1) identified-organization(3) oiw(14) secsig(3) 572 algorithm(2) 26 } 574 The SHA224 [SHS] algorithm is defined as follows: 576 sha224 ALGORITHM ::= { 577 OID id-sha224 PARMS NULL } 579 It has the following object identifier: 581 id-sha224 OBJECT IDENTIFIER ::= { 582 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 583 csor(3) nistalgorithm(4) hashalgs(2) 4 } 585 The SHA256 [SHS] algorithm is defined as follows: 587 sha256 ALGORITHM ::= { 588 OID id-sha256 PARMS NULL } 590 The algorithm identifier is: 592 id-sha256 OBJECT IDENTIFIER ::= { 593 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 594 csor(3) nistalgorithm(4) hashalgs(2) 1 } 596 The SHA384 [SHS] algorithm is defined as follows: 598 sha384 ALGORITHM ::= { 599 OID id-sha384 PARMS NULL } 601 The algorithm identifier is: 603 id-sha384 OBJECT IDENTIFIER ::= { 604 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 605 csor(3) nistalgorithm(4) hashalgs(2) 2 } 607 The SHA512 [SHS] algorithm is defined as follows: 609 sha512 ALGORITHM ::= { 610 OID id-sha512 PARMS NULL } 612 The algorithm identifier is: 614 id-sha512 OBJECT IDENTIFIER ::= { 615 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 616 csor(3) nistalgorithm(4) hashalgs(2) 3 } 618 An implementation of this document SHOULD accept values of the 619 parameterized type HashAlgorithm that have no parameters (also called 620 absent) and values that have NULL parameters. These values SHALL be 621 treated equally. (Of course, future extensions to the type parameter 622 HashFunctions might include information objects whose parameters 623 field is more meaningful.) An implementation of this document SHOULD 624 omit (leave absent) the parameters unless the recipient 625 implementation is unable to process absent parameters correctly. 627 2.1.2. Restricted Algorithm Identifiers and Parameters 629 Algorithms used with elliptic curve cryptography fall in to different 630 categories: signature and key agreement algorithms. ECDSA uses the 631 ecPublicKey described in 2.1.1. Two sets of key agreement algorithms 632 are identified herein: the Elliptic Curve Diffie-Hellman (ECDH) key 633 agreement scheme and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) 634 key agreement scheme. All algorithms are identified by an OID and 635 have PARMS. The OID varies based on the algorithm but the PARMS are 636 always ECParameters (see paragraph 2.1.1). 638 The ECDH is defined as follows: 640 ecDH ALGORITHM ::= { 641 OID TBD PARMS ECParameters } 643 The algorithm identifier is: 645 TBD OBJECT IDENTIFIER ::= { 646 TBD } 648 The ECMQV is defined as follows: 650 ecMQV ALGORITHM ::= { 651 OID TBD PARMS ECParameters } 653 The algorithm identifier is: 655 TBD OBJECT IDENTIFIER ::= { 656 TBD } 658 2.2. Subject Public Key 660 The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key. 661 Implementations of elliptic curve cryptography according to this 662 document MUST support the uncompressed form and MAY support the 663 compressed form of the ECC public key. As specified in [SEC1]: 665 The first two bytes of the key indicate whether the key is 666 compressed or uncompressed. 668 The elliptic curve public key (a value of type ECPoint which is 669 an OCTET STRING) is mapped to a subjectPublicKey (a value of type 670 BIT STRING) as follows: the most significant bit of the OCTET 671 STRING value becomes the most significant bit of the BIT STRING 672 value, and so on; the least significant bit of the OCTET STRING 673 becomes the least significant bit of the BIT STRING. 675 3. KeyUsage Bits 677 If the keyUsage extension is present in a CA certificate that 678 indicates id-ecPublicKey in subjectPublicKeyInfo, any combination of 679 the following values MAY be present: 681 digitalSignature; 682 nonRepudiation; 683 keyAgreement; 684 keyCertSign; and 685 cRLSign. 687 If the CA certificate keyUsage extension asserts keyAgreement then it 688 MAY assert either encipherOnly or decipherOnly. However, this 689 specification RECOMMENDS that if keyCertSign or cRLSign is present, 690 keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present. 692 If the keyUsage extension is present in an EE certificate that 693 indicates id-ecPublicKey in subjectPublicKeyInfo, any combination of 694 the following values MAY be present: 696 digitalSignature; 697 nonRepudiation; and 698 keyAgreement. 700 If the EE certificate keyUsage extension asserts keyAgreement then it 701 MAY assert either encipherOnly or decipherOnly. 703 If the keyUsage extension is present in a certificate that indicates 704 ecDH or ecMQV in subjectPublicKeyInfo, keyAgreement MUST be present 705 and digitalSignature, nonRepudiation, keyTransport, keyCertSign, and 706 cRLSign MUST NOT be present. If this certificate keyUsage extension 707 asserts keyAgreement then it MAY assert either encipherOnly or 708 decipherOnly. 710 4. Security Considerations 712 The security considerations in [RFC3279] apply. No new security 713 considerations are introduced by this document. 715 5. IANA Considerations 717 None. Please remove this section prior to publication as an RFC. 719 6. References 721 6.1. Normative References 723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, March 1997. 726 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 727 X.509 Public Key Infrastructure Certificate and 728 Certification Revocation List (CRL) Profile", RFC 3280, 729 April 2002. 731 [SHS] National Institute of Standards and Technology (NIST), 732 FIPS Publication 180-3: Secure Hash Standard, June 2007. 734 [SEC1] Standards for Efficient Cryptography, "SEC 1: Elliptic 735 Curve Cryptography", Version 1.0, September 2000. 737 [X.680] ITU-T Recommendation X.680: Information Technology - 738 Abstract Syntax Notation One, 1997. 740 [X.681] ITU-T Recommendation X.680: Information Technology - 741 Abstract Syntax Notation One: Information Object 742 Spcification, 1997. 744 6.2. Informative References 746 [RFC3279] Polk, W., Housley, R. and L. Bassham, "Algorithm 747 Identifiers for the Internet X.509 Public Key 748 Infrastructure", RFC 3279, April 2002. 750 Appendix A. ASN.1 Module 752 Appendix A.1 provides the normative ASN.1 definitions for the 753 structures described in this specification using ASN.1 as defined in 754 [X.680,X.681]. 756 To Be Supplied Later 758 Authors' Addresses 760 Sean Turner 762 IECA, Inc. 763 3057 Nutley Street, Suite 106 764 Fairfax, VA 22031 765 USA 767 EMail: turners@ieca.com 769 Kelvin Yiu 771 Microsoft 772 One Microsoft Way 773 Redmond, WA 98052-6399 774 USA 776 Email: kelviny@microsoft.com 778 Daniel R. L. Brown 780 Certicom Corp 781 5520 Explorer Drive #400 782 Mississauga, ON L4W 5L1 783 CANADA 785 EMail: dbrown@certicom.com 787 Russ Housley 789 Vigil Security, LLC 790 918 Spring Knoll Drive 791 Herndon, VA 20170 792 USA 794 EMail: housley@vigilsec.com 796 Tim Polk 798 NIST 799 Building 820, Room 426 800 Gaithersburg, MD 20899 801 USA 803 EMail: wpolk@nist.gov 805 Full Copyright Statement 807 Copyright (C) The IETF Trust (2008). 809 This document is subject to the rights, licenses and restrictions 810 contained in BCP 78, and except as set forth therein, the authors 811 retain all their rights. 813 This document and the information contained herein are provided on an 814 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 815 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 816 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 817 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 818 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 819 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 821 Intellectual Property 823 The IETF takes no position regarding the validity or scope of any 824 Intellectual Property Rights or other rights that might be claimed to 825 pertain to the implementation or use of the technology described in 826 this document or the extent to which any license under such rights 827 might or might not be available; nor does it represent that it has 828 made any independent effort to identify any such rights. Information 829 on the procedures with respect to rights in RFC documents can be 830 found in BCP 78 and BCP 79. 832 Copies of IPR disclosures made to the IETF Secretariat and any 833 assurances of licenses to be made available, or the result of an 834 attempt made to obtain a general license or permission for the use of 835 such proprietary rights by implementers or users of this 836 specification can be obtained from the IETF on-line IPR repository at 837 http://www.ietf.org/ipr. 839 The IETF invites any interested party to bring to its attention any 840 copyrights, patents or patent applications, or other proprietary 841 rights that may cover technology that may be required to implement 842 this standard. Please address the information to the IETF at 843 ietf-ipr@ietf.org. 845 Acknowledgment 847 Funding for the RFC Editor function is provided by the IETF 848 Administrative Support Activity (IASA).