idnits 2.17.00 (12 Aug 2021) /tmp/idnits56122/draft-ietf-pkix-ecc-pkalgs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. 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 RFC 3978 Section 5.4 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.) -- The document date (July 2004) is 6519 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SEC1' is mentioned on line 90, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 101, but not defined == Unused Reference: 'FIPS 186-2' is defined on line 680, but no explicit reference was found in the text == Unused Reference: 'RFC 3278' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'SEC2' is defined on line 693, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 180-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 186-2' ** Obsolete normative reference: RFC 3278 (Obsoleted by RFC 5753) -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP 800-56' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group Daniel R. L. Brown, 2 INTERNET-DRAFT Certicom Corp. 3 Expires November 2004 July 2004 5 Additional Algorithms and Identifiers 6 for use of Elliptic Curve Cryptography with PKIX 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or made obsolete by other documents at 19 any time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as work in progress. 22 The list of current Internet-Drafts may be found at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories may be found at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document gives additional algorithms and associated ASN.1 31 identifiers for elliptic curve cryptography (ECC) used with the 32 Internet X.509 Public Key Infrastructure Certificate and 33 Certificate Revocation List (CRL) Profile (PKIX). The algorithms 34 and identifiers here are consistent with both ANSI X9.62-1998 and 35 X9.63-2001, and shall be consistent with the forthcoming revisions 36 of these documents. Consistency shall also be maintained with SEC1 37 and SEC2, and any revisions or successors of such documents. 39 Table of Contents 41 1 Introduction ............................................... 3 42 1.1 Terminology ........................................... 3 43 1.2 Ellipitic Curve Cryptography .......................... 3 44 1.3 Algorithm Identifiers ................................. 4 45 2 Auxiliary Functions ........................................ 4 46 2.1 Hash Functions ........................................ 5 47 2.2 Key Derivation Functions .............................. 6 48 2.3 Key Wrap Functions .................................... 7 49 2.4 Message Authentication Codes .......................... 7 50 2.5 Key Confirmation Methods ... .......................... 7 51 3 Elliptic Curve Domain Parameters ........................... 8 52 4 ECC Algorithms ............................................ 10 53 4.1 Signature Schemes .................................... 11 54 4.1.1 ECDSA ........................................... 11 55 4.2 Key Agreement Schemes ................................ 13 56 4.2.1 1-Pass ECDH ..................................... 13 57 4.2.2 Full and 1-Pass ECMQV ........................... 14 58 4.3 ECC Algorithm Set .................................... 15 59 5 ECC Keys .................................................. 16 60 5.1 Public Keys .......................................... 16 61 5.2 Private Keys ......................................... 17 62 6 ASN.1 Module .............................................. 18 63 7 References ................................................ 20 64 8 Security Considerations ................................... 20 65 9 Intellectual Property Rights .............................. 21 66 10 Acknowledgments ........................................... 21 67 11 Authors' Addresses ........................................ 21 68 12 Full Copyright Statement .................................. 22 70 1 Introduction 72 This document supplements [RFC 3279], "Algorithms and 73 Identifiers for the Internet X.509 Public Key Infrastructure 74 Certificate and Certificate Revocation List (CRL) Profile " 76 This document specifies supplementary algorithm identifiers and 77 ASN.1 [X.680] encoding formats for digital signatures and subject 78 public keys used in the Internet X.509 Public Key Infrastructure 79 (PKIX). 81 The supplementary formats specified are used to indicate the 82 auxiliary functions, such as the new hash functions specified in 83 [FIPS 180-2] including SHA-256, that are to be used with elliptic 84 curve public keys. 86 Furthermore, this document specifies formats to indicate that an 87 elliptic curve public key is to be restricted for use with a an 88 indicated set of elliptic curve cryptography algorithms. 90 Note: Previous standards [X9.62], [X9.63] and [SEC1] suggested that 91 the extended key usage field could be used for purposes above. 92 Because such a practice was regarded as improper, a new means to 93 accomplish the objectives is being introduced both in this document 94 and revisions of the standards above. 96 1.1 Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 100 this document are to be interpreted as described in [RFC 2119]. 102 1.2 Ellipitic Curve Cryptography 104 Elliptic Curve Cryptography (ECC) is a family of cryptographic 105 algorithms. Several algorithms, such as Diffie-Hellman (DH) key 106 agreement and the Digital Signature Algorithm (DSA), have analogues 107 in ECC. The analogy is that the cryptographic group is an elliptic 108 curve group over a finite field rather the multiplicative group of 109 (invertible) integers modulo a large prime. 111 Because an ECC groups and its elements are different from DH and 112 DSA groups and elements, ECC requires a slightly different syntax 113 from DSA and DH. 115 Because a single ECC public key in a certificated might 116 potentially be used for multiple different ECC algorithms, a 117 mechanism for indicating algorithm usage is important. 119 1.3 Algorithm Identifiers 121 The parameters field of the ASN.1 type AlgorithmIdentifier is 122 optional when using ECC. When the parameters field is not used 123 meaningfully, it SHOULD be absent, but MAY be NULL if it is 124 necessary to interoperate with legacy implementaitons that do not 125 support an optional parameters field. Absent and NULL parameters 126 SHOULD both be accepted as valid and MUST then be considered to 127 have the same meaning. 129 The following ASN.1 information object class helps to parameterize 130 the AlgorithmIdentifier type with sets of legal values. 132 ALGORITHM ::= CLASS { 133 &id OBJECT IDENTIFIER UNIQUE, 134 &Type OPTIONAL 135 } 136 WITH SYNTAX { OID &id [PARMS &Type] } 138 The type AlgorithmIdentifier is parameterized to allow legal sets 139 of values to be specified by constraining the type with an 140 information object set. 142 AlgorithmIdentifier {ALGORITHM:IOSet} ::= SEQUENCE { 143 algorithm ALGORITHM.&id({IOSet}), 144 parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL 145 } 147 In practice, AlgorithmIdentifier is a sequence of an OID and an 148 optional second field with syntax depending on the OID. In this 149 document, the use of AlgorithmIdentifier will be constrained form. 150 For example, when a hash function needs to be identified, a 151 constrained form of AlgorithmIdentifier is used that only permits 152 the OIDs for hash functions. The constraints also dictate the 153 syntax for the the parameters field for a given OID. 155 Note: Older syntax for AlgorithmIdentifier had a mandatory 156 parameters field, which was customarily set to NULL when parameters 157 field had nothing to convey. However, in the new syntax, in such 158 situations the abset parameters are preferred to NULL parameters 159 when the paremeters field does not carry any meaning. This 160 document specifies exactly what is permitted in the parameters 161 field. 163 2 Auxiliary Functions 165 A number of different auxiliary functions are used in ECC. When 166 two entities use an ECC algorithm in their communications with each 167 other, they need to use matching auxiliary functions in order to 168 successfully interoperate. Standards for ECC generally recommend 169 or require certain choices of auxiliary functions, usually 170 according to the elliptic curve key size in use. The following 171 syntax helps to indicate, if needed, which auxiliary functions are 172 to be used. 174 2.1 Hash Functions 176 Most notable among the auxiliary functions are hash functions, 177 which are used in several different ways: message digesting for 178 signatures, verifiably random domain parameter generation, building 179 key derivation functions, building message authentication codes, as 180 well as building random number generators. 182 The hash functions that can be used with ECC are SHA-1, SHA-224, 183 SHA-256, SHA-384 and SHA-512. They are specified in FIPS 180-2, 184 Change Notice. 186 Hash functions are identified with the following object 187 identifiers. 189 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 190 oiw(14) secsig(3) algorithm(2) sha1(26) } 192 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 193 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 194 hashalgs(2) 4 } 196 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 197 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 198 hashalgs(2) 1 } 200 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 201 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 202 hashalgs(2) 2 } 204 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 205 us(840) organization(1) gov(101) csor(3) nistalgorithm(4) 206 hashalgs(2) 3 } 208 The following information object set is used to constrain the 209 AlgorithmIdentifer type for hash functions. 211 HashFunctions ALGORITHM ::= { 212 {OID sha-1} | {OID sha-1 PARMS NULL } | 213 {OID id-sha224} | {OID id-sha224 PARMS NULL } | 214 {OID id-sha256} | {OID id-sha256 PARMS NULL } | 215 {OID id-sha384} | {OID id-sha384 PARMS NULL } | 216 {OID id-sha512} | {OID id-sha512 PARMS NULL } , 217 ... -- Additional hashes may be added 218 } 220 The constrained AlgorithmIdentifier syntax to identify a hash 221 function is: 223 HashAlgorithm ::= AlgorithmIdentifer {{HashFunctions}} 225 The parameters SHOULD be absent but MAY be NULL. 227 2.2 Key Derivation Functions 229 <<< Rough version, only. Anticipate using a more flexible 230 syntax in next update of this draft ... >>> 232 Crucial to key establishment, a Key Derivation Function (KDF) takes 233 input of a raw elliptic curve point and other information such as 234 identifiers, and then derives a key. A KDF helps to eliminate any 235 structure from the key. (Elliptic curve points generally have some 236 structure and cannot be regarded as pseudorandom.) 238 The KDF to use with ECC is specified in X9.63, except that the hash 239 function SHA-1 can be replaced by one of SHA-1, SHA-224, SHA-256, 240 SHA-384, or SHA-512. In particular, the KDF is determined entirely 241 by the hash function it is built from, so the following syntax is 242 adopted. 244 KeyDerivationFunction ::= HashAlgorithm 246 That certain protocols might use a different KDF, such as KDF1 in 247 IEEE 1363-2000, only means that the specifications here are 248 overridden in these protocols. Such KDFs ought to be deprecated. 249 No ASN.1 syntax is given here to support such KDFs, making 250 protocols that use such KDFs provide their own mechanisms to 251 indicate use of them. 253 2.3 Key Wrap Functions 255 <<< To be added.>>> 257 Key wrap functions can be used to transform a key agreement scheme 258 into a key transport scheme. 260 2.4 Message Authentication Codes 262 Some ECC algorithms use a Message Authentication Code (MAC), for 263 example, as part of key confirmation. 265 <<< Surely these exist somewhere >>> 267 2.5 Key Confirmation Methods 269 <<< To be added. Unilateral, bilateral, etc.>>> 271 3 Elliptic Curve Domain Parameters 273 Elliptic curve domain parameters include the elliptic curve group 274 used, as well as a particular element of this group, called base 275 point or generator, and further includes the way the finite field 276 elements in the elliptic curve poins are represented. Elliptic 277 domain parameters usually include further information such as order 278 of the base point, a number called the cofactor, a value called 279 seed which is used to select the curve, and possibly the base 280 point, verifiably at random. Verifiably random domain parameters 281 require an auxiliary hash function. 283 A few changes to elliptic curve domain parameters as originally 284 specified in ANSI X9.62-1998 and ANSI X9.63-2001 mean that the 285 corresponding ASN.1 syntax needs the following revisions. 287 The ASN.1 syntax to represent finite field elements and elliptic 288 curve points remains unchanged. 290 The following new ASN.1 type provides the version numbers for 291 explicitly specifying elliptic curve (EC) domain parameters. 293 SpecifiedECDomainVersion ::= INTEGER { 294 ecdpVer1(1), ecdpVer2(2), ecdpVer3(3) 295 } 297 The ASN.1 type for identifying an elliptic curve remains the same 298 except the presence of its optional field is governed by the 299 version number above. 301 Curve ::= SEQUENCE { 302 a FieldElement, 303 b FieldElement, 304 seed BIT STRING OPTIONAL 305 } 307 The ASN.1 type for specifying EC domain paramters has been revised 308 to include a field to identify the hash function used to generate 309 the elliptic domain paramters verifiably at random, as follows. 311 SpecifiedECDomain ::= SEQUENCE { 312 version SpecifiedECDomainVersion ( ecdpVer1 | ecdpVer2 | ecdpVer3 ), 313 fieldID FieldID {{FieldTypes}}, 314 curve Curve, 315 base ECPoint, 316 order INTEGER, 317 cofactor INTEGER OPTIONAL, 318 hash HashAlgorithm OPTIONAL -- New field 319 } 320 A version value of ecdpVer1 is used when either the domain 321 parameters are not verifiably random or when the curve (not the 322 base point) is verfiably random (from curve.seed). A version value 323 of ecdpVer2 is used wehn the curve and the base point are both 324 verifiably random (derived from curve.seed). A version value of 325 ecdpVer3 is used when the base point, but not the curve, is 326 verifiably random (derived from curve.seed). 328 If the hash is omitted then, the hash algorithm to be used is 329 SHA-1. 331 The object identifiers for NIST recommended curves extend the 332 object identifiers primeCurve and secgCurve whose values are 334 primeCurve OBJECT IDENTIFER ::= { 335 iso(1) member-body(2) us(840) 10045 curves(3) prime(1) 336 } 338 secgCurve OBJECT IDENTIFIER ::= { 339 iso(1) identified-organization(3) certicom(132) curve(0) 340 } 342 The values of the object identifiers for the fifteen NIST 343 recommended curves are 345 ansip192r1 OBJECT IDENTIFIER ::= { primeCurve 1 } 346 ansit163k1 OBJECT IDENTIFIER ::= { secgCurve 1 } 347 ansit163r2 OBJECT IDENTIFIER ::= { secgCurve 15 } 348 ansip224r1 OBJECT IDENTIFIER ::= { secgCurve 33 } 349 ansit233k1 OBJECT IDENTIFIER ::= { secgCurve 26 } 350 ansit233r1 OBJECT IDENTIFIER ::= { secgCurve 27 } 351 ansip256r1 OBJECT IDENTIFIER ::= { primeCurve 7 } 352 ansit283k1 OBJECT IDENTIFIER ::= { secgCurve 16 } 353 ansit283r1 OBJECT IDENTIFIER ::= { secgCurve 17 } 354 ansip384r1 OBJECT IDENTIFIER ::= { secgCurve 34 } 355 ansit409k1 OBJECT IDENTIFIER ::= { secgCurve 36 } 356 ansit409r1 OBJECT IDENTIFIER ::= { secgCurve 37 } 357 ansip521r1 OBJECT IDENTIFIER ::= { secgCurve 35 } 358 ansit571k1 OBJECT IDENTIFIER ::= { secgCurve 38 } 359 ansit571r1 OBJECT IDENTIFIER ::= { secgCurve 39 } 361 The following information object class helps to constrain an 362 field below to identify only a certain EC domain parameters. 364 ECDOMAIN ::= CLASS { 365 &id OBJECT IDENTIFIER UNIQUE 366 } 367 WITH SYNTAX { ID &id } 369 The following information object set is used to constrain 370 an AlgorithmIdentifer for identifying EC domain parameters. 372 ANSINamedECDomains ECDOMAIN ::= { 373 { ID ansip192r1 } | { ID ansit163k1 } | { ID ansit163r2 } | 374 { ID ansip224r1 } | { ID ansit233k1 } | { ID ansit233r1 } | 375 { ID ansip256r1 } | { ID ansit283k1 } | { ID ansit283r1 } | 376 { ID ansip384r1 } | { ID ansit409k1 } | { ID ansit409r1 } | 377 { ID ansip521r1 } | { ID ansit571k1 } | { ID ansit571r1 } , 378 ... -- Additional EC domain parameters may be added 379 } 381 The ASN.1 type for specifying elliptic curve domain parameters, 382 whether explicitly, by name, or implicitly, is slightly revised as 383 follows. 385 ECDomainParmaters ::= CHOICE { 386 specified SpecifiedECDomain, 387 named ECDOMAIN.&id({ANSINamedECDomains}), 388 implcitCA NULL 389 } 391 4 ECC Algorithms 393 ECC algorithms can be identified using algorithm identifiers, in 394 places such as PKIX certificates (and also in CMS). 396 In the new syntax here, the parameters field of these algorithm 397 identifiers sometimes identifies the auxiliary functions. 399 4.1 Signature Schemes 401 4.1.1 ECDSA 403 To identify use of ECDSA with ASN.1, the auxiliary hash function 404 for computing the message digest is necessary, which shall be 405 implicit from the object identifeir for ECDSA, and possibly as well 406 as the corresponding public key, or shall be explicitly given in 407 the parameters field, as detailed below. 409 The following object identifier serves as the root for further 410 object identifier in this section. 412 id-ecSigType OBJECT IDENTIFIER ::= { 413 iso(1) member-body(2) us(840) 10045 signatures(4) 414 } 416 The following object identifier identifies SHA1 to be used for 417 message digesting: 419 ecdsa-with-Sha1 OBJECT IDENTIFIER ::= { id-ecSigType sha1(1) } 421 The following new object identifier identifies the hash function to 422 be used for message digesting is the one recommended for the public 423 key size: 425 ecdsa-with-Recommended OBJECT IDENTIFIER ::= { 426 id-ecSigType recommended(2) 427 } 429 The recommended hash functions are given in the draft revision of 430 X9.62, and is determined as follows. Among the hash functions 431 SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, the recommended one has 432 the largest bit size that does not require bit truncation during 433 the signing process. Bit truncation occurs the hash output bit 434 length is greater than the bit length of n, the order of the base 435 point G. (Note: even if bit trunctation does not occur, modular 436 reduction can occur.) 437 The following new object identifier identifies the hash function to 438 be used for message digesting is the one specified in the 439 parameters field of the algorithm identifier: 441 ecdsa-with-Specified OBJECT IDENTIFIER ::= { 442 id-ecSigType specified(3) 443 } 445 The following information object set helps specify the legal set of 446 algorithm identifiers for ECDSA. 448 ECDSAAlgorithmSet ALGORITHM ::= { 449 {OID ecdsa-with-Sha1} | 450 {OID ecdsa-with-Sha1 PARMS NULL} | 451 {OID ecdsa-with-Recommended} | 452 {OID ecdsa-with-Recommended PARMS NULL} | 453 {OID ecdsa-with-Specified PARMS HashAlgorithm} , 454 ... -- Future combinations may be added 455 } 457 The following type is the constrained AlgorithmIdentifier {} that 458 identifies ECDSA: 460 ECDSAAlgorithm ::= AlgorithmIdentifer {{ECDSAAlgorithmSet}} 462 4.2 Key Agreement Schemes 464 The standard [X9.63] and draft standard [SP 800-56] specify some 465 ECC key agreement schemes. The standard [X9.63] also specifies some 466 ASN.1 syntax, but this will be revised, as indicated below, in 467 to accommodate the new hash functions. 469 4.2.1 1-Pass ECDH 471 <<< In progress ... >>> 473 In the 1-Pass Elliptic Curve Diffie-Hellman (ECDH) key agreement 474 scheme, the initiator sends an ephemeral EC public key to the 475 responder who has a static EC public key, typcially in a 476 certificate. 478 The following object identifiers from ANSI X9.63 identify the use 479 of 1-Pass ECDH: 481 dhSinglePass-stdDH-sha1kdf OBJECT IDENTIFIER ::= {} 483 dhSinglePass-stdDH-sha1kdf OBJECT IDENTIFIER ::= {} 485 dhSinglePass-cofactorDH-sha1kdf OBJECT IDENTIFIER ::= {} 487 dhSinglePass-cofactorDH-sha1kdf OBJECT IDENTIFIER ::= {} 489 dhSinglePass-cofactorDH-recommendedKDF OBJECT IDENTIFIER ::= {} 491 dhSinglePass-cofactorDH-specifiedKDF OBJECT IDENTIFIER ::= {} 493 The following information object set helps specify the legal set of 494 algorithm identifiers for ECDH. 496 ECDHAlgorithmSet ALGORITHM ::= { 497 {OID dhSinglePass-stdDH-sha1kdf} | 498 {OID dhSinglePass-stdDH-sha1kdf PARMS NULL} | 499 {OID dhSinglePass-cofactorDH-sha1kdf} | 500 {OID dhSinglePass-cofactorDH-sha1kdf PARMS NULL} | 501 {OID dhSinglePass-cofactorDH-recommendedKDF} | 502 {OID dhSinglePass-cofactorDH-specifiedKDF PARMS KeyDerivationFunction} , 503 ... -- Future combinations may be added 504 } 506 The following type is the constrained AlgorithmIdentifier {} that 507 legally identifies 1-Pass ECDH: 509 ECDHAlgorithm ::= AlgorithmIdentifer {{ECDHAlgorithmSet}} 511 4.2.2 Full and 1-Pass ECMQV 513 <<< In progress.>>> 515 In the Full and 1-Pass Elliptic Curve Menezes-Qu-Vanstone (ECMQV) 516 key agreement schemes, both the initiator and responder have static 517 EC public keys, typically in certificates, and the initiator sends 518 an ephemeral EC public key to the responder. In Full ECMQV, 519 the responder sends the intiator an ephemeral EC publicc key, but 520 in 1-Pass ECQMV the sender does not. 522 The following object identifiers from ANSI X9.63 identify the 524 mqvSinglePass-sha1kdf OBJECT IDENTIFIER ::= {} 526 mqvSinglePass-recommendedKDF OBJECT IDENTIFIER ::= {} 528 mqvSinglePass-specifiedKDF OBJECT IDENTIFIER ::= {} 530 mqvFull-sha1kdf OBJECT IDENTIFIER ::= {} 532 mqvFull-recommendedKDF OBJECT IDENTIFIER ::= {} 534 mqvFull-specifiedKDF OBJECT IDENTIFIER ::= {} 536 The following information object set helps specify the legal set of 537 algorithm identifiers for ECMQV. 539 ECMQVAlgorithmSet ALGORITHM ::= { 540 {OID mqvSinglePass-sha1kdf} | 541 {OID mqvSinglePass-recommendedKDF} | 542 {OID mqvSinglePass-specifiedKDF PARMS KeyDerivationFunction} | 543 {OID mqvFull-sha1kdf} | 544 {OID mqvFull-recommendedKDF} | 545 {OID mqvFull-specifiedKDF PARMS KeyDerivationFunction} , 546 ... -- Future combinations may be added 547 } 549 The following type is the constrained AlgorithmIdentifier {} that 550 legally identifies 1-Pass and Full ECMQV: 552 ECMQVAlgorithm ::= AlgorithmIdentifer {{ECMQVAlgorithmSet}} 554 4.3 ECC Algorithm Set 556 The following information object set helps specify a legal set of 557 ECC algorithms. 559 ECCAlgorithmSet ALGORITHM ::= { 560 ECDSAAlgorithmSet | 561 ECDHAlgorithmSet | 562 ECMQVAlgorithmSet , 563 ... -- Future combinations may be added 564 } 566 The following type is the constrained AlgorithmIdentifier {} that 567 legally identifies an ECC algorithm: 569 ECCAlgorithm ::= AlgorithmIdentifer {{ECCAlgorithmSet}} 571 The following type permits a sequence of ECC algorithm identifier 572 to given. 574 ECCAlgorithms ::= SEQUENCE OF ECCAlgorithm 576 The order of the sequence SHOULD indicate an order of preference 577 for which algorithm to used, where appropriate. 579 5 ECC Keys 581 Keys in ECC generally need to be associated with additional 582 information such as domain parameters as well as, possibly, 583 restrictions or preferrences on algorithms that key can be used 584 with. 586 5.1 Public Keys 588 Public keys are generally contained in certificates or stored in 589 trusted memory, often in self-signed certificated format. 590 Certificates are conveyed between parties or accessed from 591 directories. 593 For certificates containing elliptic curve subject public keys, or 594 certificates signed with elliptic curve issuer public keys using 595 ECDSA, it is often necessary to identify the particular ECC 596 algorithms and elliptic curve domain parameters that are used. 598 Certificates with ECC subject public keys can either restrict or 599 not restrict the set of ECC algorithms with which they are used. 601 Unrestricted public keys are identified by the following OID: 603 id-ecPublicKey OBJECT IDENTIFIER ::= { 604 iso(1) member-body(2) us(840) 10045 keyType(2) unrestricted(1) 605 } 607 This OID is used in an algorithm identifer as follows: 609 ecPublicKeyType ALGORITHM ::= { 610 OID id-ecPublicKey PARMS ECDomainParameters 611 } 613 The following new syntax identifies ECC subject keys restricted to 614 a certain subset of ECC algorithms. Firstly, the following OID is 615 used: 617 id-ecPublicKeyRestricted OBJECT IDENTIFIER ::= { 618 iso(1) member-body(2) us(840) 10045 keyType(2) restricted(2) 619 } 621 The following new syntax permits both elliptic curve domain 622 parameters and a sequence of algorithm restrictions to be 623 associated with an ECC public key: 625 ECPKRestrictions ::= SEQUENCE { 626 ecDomain ECDomainParameters, 627 eccAlgorithms ECCAlgorithms 628 } 629 The new OID and new type are used in an algorithm identifier as 630 follows: 632 ecPublicKeyTypeRestricted ALGORITHM ::= { 633 OID id-ecPublicKeyRestricted PARMS ECPKRestrictions 634 } 636 The following information object set ECPKAlgorithmSet specifies the 637 legal set of algorithm identifiers to identify an ECC public key: 639 ECPKAlgorithmSet ::= { 640 ecPublicKeyType | ecPublicKeyTypeRestricted , 641 ... -- Further ECC public key types might be added 642 } 644 The following type uses the set above to constrain a algorithm 645 identifer accordingly: 647 ECPKAlgorithm ::= AlgorithmIdentifer {ECPKAlgorithmSet} 649 In a PKIX certificate with an ECC subject public key, the 650 SubjectPublicKeyInfo type shall use the following syntax: 652 SubjectPublicKeyInfo ::= SEQUENCE { 653 algorithm ECPKAlgorithm, 654 subjectPublicKey BIT STRING 655 } 657 The elliptic curve public key (a value of type ECPoint which is an 658 OCTET STRING) is mapped to a subjectPublicKey (a value of type BIT 659 STRING) as follows: the most significant bit of the OCTET STRING 660 value becomes the most signficant bit of the BIT STRING value, and 661 so on; the least significant bit of the OCTET STRING becomes the 662 least significant bit of the BIT STRING. 664 5.2 Private Keys 666 <<< To be added. Perhaps unnecessary for PKIX. >>> 668 6 ASN.1 Module(s) 670 <<< To be added. >>> 671 <<< Temporary blank page >>> 673 7 References 675 [FIPS 180-2] U.S. Department of Commerce/National Institute of 676 Standards and Technology. Secure Hash Standard (SHS), FIPS 677 PUB 180-2, [? ? ? Auguest 2001 ? ? ?]. 678 (http://csrc.nist.gov/fips/fips180-2.pdf) 680 [FIPS 186-2] U.S. Department of Commerce/National Institute of 681 Standards and Technology. Digital Signature Standard (DSS), FIPS 682 PUB 186-2, January 2000. 683 (http://csrc.nist.gov/fips/fips186-2.pdf) 685 [RFC 3279] W. Polk, R. Housley and L. Bassham. Algorithms and 686 Identifiers for the Internet X.509 Public Key Infrastructure 687 Certificate and Certificate Revocation List (CRL) Profile, April 688 2002. 690 [RFC 3278] S. Blake-Wilson, D. Brown and P. Lambert. Use of ECC 691 Algorithms in CMS, April 2002. 693 [SEC2] Standards for Efficient Cryptography Group. SEC 2 - 694 Recommended Elliptic Curve Domain Parameters. Working Draft 695 Ver. 0.6., 1999. (http://www.secg.org) 697 [SP 800-56] NIST. Special Publication 800-56, Key Establishment 698 Schemes, 2003. 700 [X9.62] American National Standard for Financial Services. ANSI 701 X9.62-1998, Public Key Cryptography for the Financial Services 702 Industry: The Elliptic Curve Digital Signature Algorithm. 1998. 704 [X9.63] American National Standard for Financial Services. ANSI 705 X9.63-2001, Public Key Cryptography for the Financial Services 706 Industry: Key Agreement and Key Transport using Elliptic Curve 707 Cryptography. November 2001. 709 8 Security Considerations 711 <<< To be added later. >>> 713 9 Intellectual Property Rights 715 The IETF has been notified of intellectual property rights claimed 716 in regard to the specification contained in this document. For more 717 information, consult the online list of claimed rights 718 (http://www.ietf.org/ipr.html). 720 The IETF takes no position regarding the validity or scope of any 721 intellectual property or other rights that might be claimed to 722 pertain to the implementation or use of the technology described in 723 this document or the extent to which any license under such rights 724 might or might not be available; neither does it represent that it 725 has made any effort to identify any such rights. Information on the 726 IETF's procedures with respect to rights in standards-track and 727 standards-related documentation can be found in BCP-11. Copies of 728 claims of rights made available for publication and any assurances 729 of licenses to be made available, or the result of an attempt made 730 to obtain a general license or permission for the use of such 731 proprietary rights by implementors or users of this specification 732 can be obtained from the IETF Secretariat. 734 10 Acknowledgments 736 To be added later. 738 11 Authors' Addresses 740 Authors: 742 Daniel R. L. Brown 743 Certicom Corp. 744 dbrown@certicom.com 746 12 Full Copyright Statement 748 Copyright (C) The Internet Society (2002). All Rights Reserved. 750 This document and translations of it may be copied and furnished to 751 others, and derivative works that comment on or otherwise explain 752 it or assist in its implementation may be prepared, copied, 753 published and distributed, in whole or in part, without restriction 754 of any kind, provided that the above copyright notice and this 755 paragraph are included on all such copies and derivative works. 757 In addition, the ASN.1 module presented in Section 6 may be used in 758 whole or in part without inclusion of the copyright notice. 759 However, this document itself may not be modified in any way, such 760 as by removing the copyright notice or references to the Internet 761 Society or other Internet organizations, except as needed for the 762 purpose of developing Internet standards in which case the 763 procedures for copyrights defined in the Internet Standards process 764 shall be followed, or as required to translate it into languages 765 other than English. 767 The limited permissions granted above are perpetual and will not be 768 revoked by the Internet Society or its successors or assigns. This 769 document and the information contained herein is provided on an "AS 770 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 771 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 772 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 773 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 774 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.