idnits 2.17.1 draft-ietf-dnsext-ecc-key-03.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? == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (December 2002) is 7802 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) -- Looks like a reference, but probably isn't: '0' on line 336 == Missing Reference: 'P-1' is mentioned on line 336, but not defined == Unused Reference: 'RFC 1034' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'Schneier' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'Silverman' is defined on line 526, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' -- Possible downref: Non-RFC (?) normative reference: ref. 'Menezes' -- Possible downref: Non-RFC (?) normative reference: ref. 'Silverman' Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT ECC Keys in the DNS 2 Expires: June 2003 December 2002 4 Elliptic Curve KEYs in the DNS 5 -------- ----- ---- -- --- --- 6 8 Richard C. Schroeppel 9 Donald Eastlake 3rd 11 Status of This Document 13 This draft is intended to be become a Proposed Standard RFC. 14 Distribution of this document is unlimited. Comments should be sent 15 to the DNS mailing list or to the 16 authors. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC 2026. Internet-Drafts are 20 working documents of the Internet Engineering Task Force (IETF), its 21 areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 A standard method for storing elliptic curve cryptographic keys in 38 the Domain Name System is described which utilizes DNS KEY resource 39 record. 41 Acknowledgement 43 The assistance of Hilarie K. Orman in the production of this document 44 is greatfully acknowledged. 46 Table of Contents 48 Status of This Document....................................1 49 Abstract...................................................1 51 Acknowledgement............................................2 52 Table of Contents..........................................2 54 1. Introduction............................................3 55 2. Elliptic Curve KEY Resource Records.....................3 56 3. The Elliptic Curve Equation.............................9 57 4. How do I Compute Q, G, and Y?..........................10 58 5. Performance Considerations.............................11 59 6. Security Considerations................................11 60 7. IANA Considerations....................................11 62 References................................................13 64 Authors' Addresses........................................14 65 Expiration and File Name..................................14 67 1. Introduction 69 The Domain Name System (DNS) is the global hierarchical replicated 70 distributed database system for Internet addressing, mail proxy, and 71 other information. The DNS has been extended to include digital 72 signatures and cryptographic keys as described in [RFC 2535]. 74 This document describes how to store elliptic curve cryptographic 75 (ECC) keys in the DNS so they can be used for a variety of security 76 purposes. A DNS elliptic curve SIG resource record is not defined. 77 Familiarity with ECC cryptography is assumed [Menezes]. 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC 2119]. 83 2. Elliptic Curve KEY Resource Records 85 Elliptic curve public keys are stored in the DNS as KEY RRs using 86 algorithm number 4 (see [RFC 2535]). The structure of the RDATA 87 portion of this RR is as shown below. The first 4 octets, including 88 the flags, protocol, and algorithm fields are common to all KEY RRs. 89 The remainder is the "public key" part of the KEY RR. 91 The period of key validity is not in the KEY RR but is indicated by 92 the SIG RR(s) which signs and authenticates the KEY RR(s) at that 93 domain name and class. 95 The research world continues to work on the issue of which is the 96 best elliptic curve system, which finite field to use, and how to 97 best represent elements in the field. So, we have defined 98 representations for every type of finite field, and every type of 99 elliptic curve. The reader should be aware that there is a unique 100 finite field with a particular number of elements, but many possible 101 representations of that field and its elements. If two different 102 representations of a field are given, they are interconvertible with 103 a tedious but practical precomputation, followed by a fast 104 computation for each field element to be converted. It is perfectly 105 reasonable for an algorithm to work internally with one field 106 representation, and convert to and from a different external 107 representation. 109 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 110 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | KEY flags | protocol | algorithm=4 | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 |S M -FMT- A B Z| 115 +-+-+-+-+-+-+-+-+ 116 | LP | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | P (length determined from LP) .../ 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | LF | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | F (length determined from LF) .../ 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | DEG | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | DEGH | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | DEGI | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | DEGJ | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | TRDV | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 |S| LH | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | H (length determined from LH) .../ 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 |S| LK | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | K (length determined from LK) .../ 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | LQ | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Q (length determined from LQ) .../ 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | LA | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | A (length determined from LA) .../ 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | ALTA | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | LB | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | B (length determined from LB) .../ 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | LC | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | C (length determined from LC) .../ 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | LG | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | G (length determined from LG) .../ 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | LY | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Y (length determined from LY) .../ 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 SMFMTABZ is a flags octet as follows: 171 S = 1 indicates that the remaining 7 bits of the octet selects 172 one of 128 predefined choices of finite field, element 173 representation, elliptic curve, and signature parameters. 174 MFMTABZ are omitted, as are all parameters from LP through G. 175 LY and Y are retained. 177 If S = 0, the remaining parameters are as in the picture and 178 described below. 180 M determines the type of field underlying the elliptic curve. 182 M = 0 if the field is a GF[2^N] field; 184 M = 1 if the field is a (mod P) or GF[P^D] field with P>2. 186 FMT is a three bit field describing the format of the field 187 representation. 189 FMT = 0 for a (mod P) field. 190 > 0 for an extension field, either GF[2^D] or GF[P^D]. 191 The degree D of the extension, and the field polynomial 192 must be specified. The field polynomial is always monic 193 (leading coefficient 1.) 195 FMT = 1 The field polynomial is given explicitly; D is implied. 197 If FMT >=2, the degree D is given explicitly. 199 = 2 The field polynomial is implicit. 200 = 3 The field polynomial is a binomial. P>2. 201 = 4 The field polynomial is a trinomial. 202 = 5 The field polynomial is the quotient of a trinomial by a 203 short polynomial. P=2. 204 = 6 The field polynomial is a pentanomial. P=2. 206 Flags A and B apply to the elliptic curve parameters. 208 A = 1 When P>=5, the curve parameter A is negated. If P=2, then 209 A=1 indicates that the A parameter is special. See the 210 ALTA parameter below, following A. The combination A=1, 211 P=3 is forbidden. 213 B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3, 214 then B=1 indicates an alternate elliptic curve equation is 215 used. When P=2 and B=1, an additional curve parameter C 216 is present. 218 The Z bit SHOULD be set to zero on creation of KEY RR and MUST 219 be ignored when processing a KEY RR (when S=0). 221 Most of the remaining parameters are present in some formats and 222 absent in others. The presence or absence of a parameter is 223 determined entirely by the flags. When a parameter occurs, it is in 224 the order defined by the picture. 226 Of the remaining parameters, PFHKQABCGY are variable length. When 227 present, each is preceded by a one-octet length field as shown in the 228 diagram above. The length field does not include itself. The length 229 field may have values from 0 through 110. The parameter length in 230 octets is determined by a conditional formula: If LL<=64, the 231 parameter length is LL. If LL>64, the parameter length is 16 times 232 (LL-60). In some cases, a parameter value of 0 is sensible, and MAY 233 be represented by an LL value of 0, with the data field omitted. A 234 length value of 0 represents a parameter value of 0, not an absent 235 parameter. (The data portion occupies 0 space.) There is no 236 requirement that a parameter be represented in the minimum number of 237 octets; high-order 0 octets are allowed at the front end. Parameters 238 are always right adjusted, in a field of length defined by LL. The 239 octet-order is always most-significant first, least-significant last. 240 The parameters H and K may have an optional sign bit stored in the 241 unused high-order bit of their length fields. 243 LP defines the length of the prime P. P must be an odd prime. The 244 parameters LP,P are present if and only if the flag M=1. If M=0, the 245 prime is 2. 247 LF,F define an explicit field polynomial. This parameter pair is 248 present only when FMT = 1. The length of a polynomial coefficient is 249 ceiling(log2 P) bits. Coefficients are in the numerical range 250 [0,P-1]. The coefficients are packed into fixed-width fields, from 251 higher order to lower order. All coefficients must be present, 252 including any 0s and also the leading coefficient (which is required 253 to be 1). The coefficients are right justified into the octet string 254 of length specified by LF, with the low-order "constant" coefficient 255 at the right end. As a concession to storage efficiency, the higher 256 order bits of the leading coefficient may be elided, discarding high- 257 order 0 octets and reducing LF. The degree is calculated by 258 determining the bit position of the left most 1-bit in the F data 259 (counting the right most bit as position 0), and dividing by 260 ceiling(log2 P). The division must be exact, with no remainder. In 261 this format, all of the other degree and field parameters are 262 omitted. The next parameters will be LQ,Q. 264 If FMT>=2, the degree of the field extension is specified explicitly, 265 usually along with other parameters to define the field polynomial. 267 DEG is a two octet field that defines the degree of the field 268 extension. The finite field will have P^DEG elements. DEG is 269 present when FMT>=2. 271 When FMT=2, the field polynomial is specified implicitly. No other 272 parameters are required to define the field; the next parameters 273 present will be the LQ,Q pair. The implicit field poynomial is the 274 lexicographically smallest irreducible (mod P) polynomial of the 275 correct degree. The ordering of polynomials is by highest-degree 276 coefficients first -- the leading coefficient 1 is most important, 277 and the constant term is least important. Coefficients are ordered 278 by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial 279 of degree D is X^D (which is not irreducible). The next is X^D+1, 280 which is sometimes irreducible, followed by X^D-1, which isn't. 281 Assuming odd P, this series continues to X^D - (P-1)/2, and then goes 282 to X^D + X, X^D + X + 1, X^D + X - 1, etc. 284 When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be 285 odd. The polynomial is determined by the degree and the low order 286 term K. Of all the field parameters, only the LK,K parameters are 287 present. The high-order bit of the LK octet stores on optional sign 288 for K; if the sign bit is present, the field polynomial is X^DEG - K. 290 When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH + 291 K. When P=2, the H and K parameters are implicitly 1, and are 292 omitted from the representation. Only DEG and DEGH are present; the 293 next parameters are LQ,Q. When P>2, then LH,H and LK,K are 294 specified. Either or both of LH, LK may contain a sign bit for its 295 parameter. 297 When FMT=5, then P=2 (only). The field polynomial is the exact 298 quotient of a trinomial divided by a small polynomial, the trinomial 299 divisor. The small polynomial is right-adjusted in the two octet 300 field TRDV. DEG specifies the degree of the field. The degree of 301 TRDV is calculated from the position of the high-order 1 bit. The 302 trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If 303 DEGH is 0, the middle term is omitted from the trinomial. The 304 quotient must be exact, with no remainder. 306 When FMT=6, then P=2 (only). The field polynomial is a pentanomial, 307 with the degrees of the middle terms given by the three 2-octet 308 values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI + 309 X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI 310 > DEGJ > 0. 312 DEGH, DEGI, DEGJ are two-octet fields that define the degree of 313 a term in a field polynomial. DEGH is present when FMT = 4, 314 5, or 6. DEGI and DEGJ are present only when FMT = 6. 316 TRDV is a two-octet right-adjusted binary polynomial of degree < 317 16. It is present only for FMT=5. 319 LH and H define the H parameter, present only when FMT=4 and P 320 is odd. The high bit of LH is an optional sign bit for H. 322 LK and K define the K parameter, present when FMT = 3 or 4, and 323 P is odd. The high bit of LK is an optional sign bit for K. 325 The remaining parameters are concerned with the elliptic curve and 326 the signature algorithm. 328 LQ defines the length of the prime Q. Q is a prime > 2^159. 330 In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data 331 member of the pair is an element from the finite field defined 332 earlier. The length field defines a long octet string. Field 333 elements are represented as (mod P) polynomials of degree < DEG, with 334 DEG or fewer coefficients. The coefficients are stored from left to 335 right, higher degree to lower, with the constant term last. The 336 coefficients are represented as integers in the range [0,P-1]. Each 337 coefficient is allocated an area of ceiling(log2 P) bits. The field 338 representation is right-justified; the "constant term" of the field 339 element ends at the right most bit. The coefficients are fitted 340 adjacently without regard for octet boundaries. (Example: if P=5, 341 three bits are used for each coefficient. If the field is GF[5^75], 342 then 225 bits are required for the coefficients, and as many as 29 343 octets may be needed in the data area. Fewer octets may be used if 344 some high-order coefficients are 0.) If a flag requires a field 345 element to be negated, each non-zero coefficient K is replaced with 346 P-K. To save space, 0 bits may be removed from the left end of the 347 element representation, and the length field reduced appropriately. 348 This would normally only happen with A,B,C, because the designer 349 chose curve parameters with some high-order 0 coefficients or bits. 351 If the finite field is simply (mod P), then the field elements are 352 simply numbers (mod P), in the usual right-justified notation. If 353 the finite field is GF[2^D], the field elements are the usual right- 354 justified polynomial basis representation. 356 LA,A is the first parameter of the elliptic curve equation. 357 When P>=5, the flag A = 1 indicates A should be negated (mod 358 P). When P=2 (indicated by the flag M=0), the flag A = 1 359 indicates that the parameter pair LA,A is replaced by the two 360 octet parameter ALTA. In this case, the parameter A in the 361 curve equation is x^ALTA, where x is the field generator. 362 Parameter A often has the value 0, which may be indicated by 363 LA=0 (with no A data field), and sometimes A is 1, which may 364 be represented with LA=1 and a data field of 1, or by setting 365 the A flag and using an ALTA value of 0. 367 LB,B is the second parameter of the elliptic curve equation. 368 When P>=5, the flag B = 1 indicates B should be negated (mod 369 P). When P=2 or 3, the flag B selects an alternate curve 370 equation. 372 LC,C is the third parameter of the elliptic curve equation, 373 present only when P=2 (indicated by flag M=0) and flag B=1. 375 LG,G defines a point on the curve, of order Q. The W-coordinate 376 of the curve point is given explicitly; the Z-coordinate is 377 implicit. 379 LY,Y is the user's public signing key, another curve point of 380 order Q. The W-coordinate is given explicitly; the Z- 381 coordinate is implicit. The LY,Y parameter pair is always 382 present. 384 3. The Elliptic Curve Equation 386 (The coordinates of an elliptic curve point are named W,Z instead of 387 the more usual X,Y to avoid confusion with the Y parameter of the 388 signing key.) 390 The elliptic curve equation is determined by the flag octet, together 391 with information about the prime P. The primes 2 and 3 are special; 392 all other primes are treated identically. 394 If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3 395 + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D]. 396 If A and/or B is negative (i.e., in the range from P/2 to P), and 397 P>=5, space may be saved by putting the sign bit(s) in the A and B 398 bits of the flags octet, and the magnitude(s) in the parameter 399 fields. 401 If M=1 and P=3, the B flag has a different meaning: it specifies an 402 alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of 403 the right-hand-side is different. When P=3, this equation is more 404 commonly used. 406 If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 + 407 A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A 408 parameter can often be 0 or 1, or be chosen as a single-1-bit value. 409 The flag B is used to select an alternate curve equation, Z^2 + C*Z = 410 W^3 + A*W + B. This is the only time that the C parameter is used. 412 4. How do I Compute Q, G, and Y? 414 The number of points on the curve is the number of solutions to the 415 curve equation, + 1 (for the "point at infinity"). The prime Q must 416 divide the number of points. Usually the curve is chosen first, then 417 the number of points is determined with Schoof's algorithm. This 418 number is factored, and if it has a large prime divisor, that number 419 is taken as Q. 421 G must be a point of order Q on the curve, satisfying the equation 423 Q * G = the point at infinity (on the elliptic curve) 425 G may be chosen by selecting a random [RFC 1750] curve point, and 426 multiplying it by (number-of-points-on-curve/Q). G must not itself 427 be the "point at infinity"; in this astronomically unlikely event, a 428 new random curve point is recalculated. 430 G is specified by giving its W-coordinate. The Z-coordinate is 431 calculated from the curve equation. In general, there will be two 432 possible Z values. The rule is to choose the "positive" value. 434 In the (mod P) case, the two possible Z values sum to P. The smaller 435 value is less than P/2; it is used in subsequent calculations. In 436 GF[P^D] fields, the highest-degree non-zero coefficient of the field 437 element Z is used; it is chosen to be less than P/2. 439 In the GF[2^N] case, the two possible Z values xor to W (or to the 440 parameter C with the alternate curve equation). The numerically 441 smaller Z value (the one which does not contain the highest-order 1 442 bit of W (or C)) is used in subsequent calculations. 444 Y is specified by giving the W-coordinate of the user's public 445 signature key. The Z-coordinate value is determined from the curve 446 equation. As with G, there are two possible Z values; the same rule 447 is followed for choosing which Z to use. 449 During the key generation process, a random [RFC 1750] number X must 450 be generated such that 1 <= X <= Q-1. X is the private key and is 451 used in the final step of public key generation where Y is computed 452 as 454 Y = X * G (as points on the elliptic curve) 456 If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2 457 in the (mod P) case, or the high-order non-zero coefficient of Z > 458 P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the 459 GF[2^N] case), then X must be replaced with Q-X. This will 460 correspond to the correct Z-coordinate. 462 5. Performance Considerations 464 Elliptic curve signatures use smaller moduli or field sizes than RSA 465 and DSA. Creation of a curve is slow, but not done very often. Key 466 generation is faster than RSA or DSA. 468 DNS implementations have been optimized for small transfers, 469 typically less than 512 octets including DNS overhead. Larger 470 transfers will perform correctly and and extensions have been 471 standardized to make larger transfers more efficient [RFC 2671]. 472 However, it is still advisable at this time to make reasonable 473 efforts to minimize the size of KEY RR sets stored within the DNS 474 consistent with adequate security. Keep in mind that in a secure 475 zone, an authenticating SIG RRset will also be returned. 477 6. Security Considerations 479 Many of the general security consideration in [RFC 2535] apply. Some 480 specific key generation considerations are given above. Of course, 481 the elliptic curve key stored in the DNS for an entity should not be 482 trusted unless it has been obtain via a trusted DNS resolver that 483 vouches for its security or unless the application using the key has 484 done a similar authentication. 486 7. IANA Considerations 488 Assignment of meaning to the remaining ECC KEY flag bits or to values 489 of ECC fields outside the ranges for which meaning in defined in this 490 document requires an IETF consensus as defined in [RFC 2434]. 492 This specification uses algorithm number 4 for DNS elliptic curve KEY 493 RRs that was reserved for this purpose in [RFC 2535]. An elliptic 494 curve (algorithm = 4) SIG RR is not defined. Assignment of a meaning 495 to it requires an IETF Standards action. 497 References 499 [RFC 1034] - P. Mockapetris, "Domain names - concepts and 500 facilities", 11/01/1987. 502 [RFC 1035] - P. Mockapetris, "Domain names - implementation and 503 specification", 11/01/1987. 505 [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness 506 Recommendations for Security", 12/29/1994. 508 [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate 509 Requirement Levels", March 1997. 511 [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an 512 IANA Considerations Section in RFCs", October 1998. 514 [RFC 2535] - D. Eastlake,"Domain Name System Security Extensions", 515 March 1999. 517 [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August 518 1999. 520 [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, 521 Algorithms, and Source Code in C", 1996, John Wiley and Sons 523 [Menezes] - Alfred Menezes, "Elliptic Curve Public Key 524 Cryptosystems", 1993 Kluwer. 526 [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves", 527 1986, Springer Graduate Texts in mathematics #106. 529 Authors' Addresses 531 Rich Schroeppel 532 500 S. Maple Drive 533 Woodland Hills, UT 84653 USA 535 Telephone: 1-801-423-7998(h) 536 1-505-844-9079(w) 537 Email: rcs@cs.arizona.edu 538 rschroe@sandia.gov 540 Donald E. Eastlake 3rd 541 Motorola 542 155 Beaver Street 543 Milford, MA 01757 USA 545 Telephone: +1 508-634-2066 (h) 546 +1 508-851-8280 (w) 547 FAX: +1 508-851-8507 (w) 548 EMail: Donald.Eastlake@motorola.com 550 Expiration and File Name 552 This draft expires in June 2003. 554 Its file name is draft-ietf-dnsext-ecc-key-03.txt.