idnits 2.17.1 draft-ietf-dnsext-ecc-key-05.txt: -(287): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(386): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(424): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(451): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 514. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (August 2004) is 7191 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 343 == Missing Reference: 'P-1' is mentioned on line 343, but not defined == Unused Reference: 'RFC 1034' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 521, but no explicit reference was found in the text == Unused Reference: 'Schneier' is defined on line 538, but no explicit reference was found in the text == Unused Reference: 'Silverman' is defined on line 544, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ��� 3 INTERNET-DRAFT ECC Keys in the DNS 4 Expires: February 2005 August 2004 6 Elliptic Curve KEYs in the DNS 7 -------- ----- ---- -- --- --- 8 10 Richard C. Schroeppel 11 Donald Eastlake 3rd 13 Status of This Document 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 or will be disclosed, and any of which I become aware will be 18 disclosed, in accordance with RFC 3668. 20 This draft is intended to be become a Proposed Standard RFC. 21 Distribution of this document is unlimited. Comments should be sent 22 to the DNS mailing list . 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than a "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Abstract 42 The standard method for storing elliptic curve cryptographic keys in 43 the Domain Name System is specified. 45 Copyright Notice 47 Copyright (C) The Internet Society. All Rights Reserved. 49 Acknowledgement 51 The assistance of Hilarie K. Orman in the production of this document 52 is greatfully acknowledged. 54 Table of Contents 56 Status of This Document....................................1 57 Abstract...................................................1 58 Copyright Notice...........................................1 60 Acknowledgement............................................2 61 Table of Contents..........................................2 63 1. Introduction............................................3 64 2. Elliptic Curve Data in Resource Records.................3 65 3. The Elliptic Curve Equation.............................9 66 4. How do I Compute Q, G, and Y?..........................10 67 5. Performance Considerations.............................11 68 6. Security Considerations................................11 69 7. IANA Considerations....................................11 70 Copyright and Disclaimer..................................12 72 Informational References..................................13 73 Normative Refrences.......................................13 75 Authors Addresses.........................................14 76 Expiration and File Name..................................14 78 1. Introduction 80 The Domain Name System (DNS) is the global hierarchical replicated 81 distributed database system for Internet addressing, mail proxy, and 82 other information. The DNS has been extended to include digital 83 signatures and cryptographic keys as described in [RFC intro, 84 protocol, records]. 86 This document describes how to store elliptic curve cryptographic 87 (ECC) keys in the DNS so they can be used for a variety of security 88 purposes. A DNS elliptic curve SIG resource record is not defined. 89 Familiarity with ECC cryptography is assumed [Menezes]. 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC 2119]. 95 2. Elliptic Curve Data in Resource Records 97 Elliptic curve public keys are stored in the DNS within the RDATA 98 portions of key RRs with the structure shown below [RFC records]. 100 The period of key validity may not be in the RR with the key but 101 could be indicated by RR(s) with signatures that authenticates the 102 RR(s) containing the key. 104 The research world continues to work on the issue of which is the 105 best elliptic curve system, which finite field to use, and how to 106 best represent elements in the field. So, representations are 107 defined for every type of finite field, and every type of elliptic 108 curve. The reader should be aware that there is a unique finite 109 field with a particular number of elements, but many possible 110 representations of that field and its elements. If two different 111 representations of a field are given, they are interconvertible with 112 a tedious but practical precomputation, followed by a fast 113 computation for each field element to be converted. It is perfectly 114 reasonable for an algorithm to work internally with one field 115 representation, and convert to and from a different external 116 representation. 118 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 |S M -FMT- A B Z| 122 +-+-+-+-+-+-+-+-+ 123 | LP | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | P (length determined from LP) .../ 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | LF | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | F (length determined from LF) .../ 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | DEG | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | DEGH | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | DEGI | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | DEGJ | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | TRDV | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 |S| LH | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | H (length determined from LH) .../ 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 |S| LK | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | K (length determined from LK) .../ 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | LQ | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Q (length determined from LQ) .../ 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | LA | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | A (length determined from LA) .../ 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | ALTA | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | LB | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | B (length determined from LB) .../ 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | LC | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | C (length determined from LC) .../ 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | LG | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | G (length determined from LG) .../ 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | LY | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Y (length determined from LY) .../ 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 SMFMTABZ is a flags octet as follows: 178 S = 1 indicates that the remaining 7 bits of the octet selects 179 one of 128 predefined choices of finite field, element 180 representation, elliptic curve, and signature parameters. 181 MFMTABZ are omitted, as are all parameters from LP through G. 182 LY and Y are retained. 184 If S = 0, the remaining parameters are as in the picture and 185 described below. 187 M determines the type of field underlying the elliptic curve. 189 M = 0 if the field is a GF[2^N] field; 191 M = 1 if the field is a (mod P) or GF[P^D] field with P>2. 193 FMT is a three bit field describing the format of the field 194 representation. 196 FMT = 0 for a (mod P) field. 197 > 0 for an extension field, either GF[2^D] or GF[P^D]. 198 The degree D of the extension, and the field polynomial 199 must be specified. The field polynomial is always monic 200 (leading coefficient 1.) 202 FMT = 1 The field polynomial is given explicitly; D is implied. 204 If FMT >=2, the degree D is given explicitly. 206 = 2 The field polynomial is implicit. 207 = 3 The field polynomial is a binomial. P>2. 208 = 4 The field polynomial is a trinomial. 209 = 5 The field polynomial is the quotient of a trinomial by a 210 short polynomial. P=2. 211 = 6 The field polynomial is a pentanomial. P=2. 213 Flags A and B apply to the elliptic curve parameters. 215 A = 1 When P>=5, the curve parameter A is negated. If P=2, then 216 A=1 indicates that the A parameter is special. See the 217 ALTA parameter below, following A. The combination A=1, 218 P=3 is forbidden. 220 B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3, 221 then B=1 indicates an alternate elliptic curve equation is 222 used. When P=2 and B=1, an additional curve parameter C 223 is present. 225 The Z bit SHOULD be set to zero on creation of an RR and MUST be 226 ignored when processing an RR (when S=0). 228 Most of the remaining parameters are present in some formats and 229 absent in others. The presence or absence of a parameter is 230 determined entirely by the flags. When a parameter occurs, it is in 231 the order defined by the picture. 233 Of the remaining parameters, PFHKQABCGY are variable length. When 234 present, each is preceded by a one-octet length field as shown in the 235 diagram above. The length field does not include itself. The length 236 field may have values from 0 through 110. The parameter length in 237 octets is determined by a conditional formula: If LL<=64, the 238 parameter length is LL. If LL>64, the parameter length is 16 times 239 (LL-60). In some cases, a parameter value of 0 is sensible, and MAY 240 be represented by an LL value of 0, with the data field omitted. A 241 length value of 0 represents a parameter value of 0, not an absent 242 parameter. (The data portion occupies 0 space.) There is no 243 requirement that a parameter be represented in the minimum number of 244 octets; high-order 0 octets are allowed at the front end. Parameters 245 are always right adjusted, in a field of length defined by LL. The 246 octet-order is always most-significant first, least-significant last. 247 The parameters H and K may have an optional sign bit stored in the 248 unused high-order bit of their length fields. 250 LP defines the length of the prime P. P must be an odd prime. The 251 parameters LP,P are present if and only if the flag M=1. If M=0, the 252 prime is 2. 254 LF,F define an explicit field polynomial. This parameter pair is 255 present only when FMT = 1. The length of a polynomial coefficient is 256 ceiling(log2 P) bits. Coefficients are in the numerical range 257 [0,P-1]. The coefficients are packed into fixed-width fields, from 258 higher order to lower order. All coefficients must be present, 259 including any 0s and also the leading coefficient (which is required 260 to be 1). The coefficients are right justified into the octet string 261 of length specified by LF, with the low-order "constant" coefficient 262 at the right end. As a concession to storage efficiency, the higher 263 order bits of the leading coefficient may be elided, discarding high- 264 order 0 octets and reducing LF. The degree is calculated by 265 determining the bit position of the left most 1-bit in the F data 266 (counting the right most bit as position 0), and dividing by 267 ceiling(log2 P). The division must be exact, with no remainder. In 268 this format, all of the other degree and field parameters are 269 omitted. The next parameters will be LQ,Q. 271 If FMT>=2, the degree of the field extension is specified explicitly, 272 usually along with other parameters to define the field polynomial. 274 DEG is a two octet field that defines the degree of the field 275 extension. The finite field will have P^DEG elements. DEG is 276 present when FMT>=2. 278 When FMT=2, the field polynomial is specified implicitly. No other 279 parameters are required to define the field; the next parameters 280 present will be the LQ,Q pair. The implicit field poynomial is the 281 lexicographically smallest irreducible (mod P) polynomial of the 282 correct degree. The ordering of polynomials is by highest-degree 283 coefficients first -- the leading coefficient 1 is most important, 284 and the constant term is least important. Coefficients are ordered 285 by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of 286 degree D is X^D (which is not irreducible). The next is X^D+1, which 287 is sometimes irreducible, followed by X^D-1, which isn���t. Assuming 288 odd P, this series continues to X^D - (P-1)/2, and then goes to X^D + 289 X, X^D + X + 1, X^D + X - 1, etc. 291 When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be 292 odd. The polynomial is determined by the degree and the low order 293 term K. Of all the field parameters, only the LK,K parameters are 294 present. The high-order bit of the LK octet stores on optional sign 295 for K; if the sign bit is present, the field polynomial is X^DEG - K. 297 When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH + 298 K. When P=2, the H and K parameters are implicitly 1, and are 299 omitted from the representation. Only DEG and DEGH are present; the 300 next parameters are LQ,Q. When P>2, then LH,H and LK,K are 301 specified. Either or both of LH, LK may contain a sign bit for its 302 parameter. 304 When FMT=5, then P=2 (only). The field polynomial is the exact 305 quotient of a trinomial divided by a small polynomial, the trinomial 306 divisor. The small polynomial is right-adjusted in the two octet 307 field TRDV. DEG specifies the degree of the field. The degree of 308 TRDV is calculated from the position of the high-order 1 bit. The 309 trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If 310 DEGH is 0, the middle term is omitted from the trinomial. The 311 quotient must be exact, with no remainder. 313 When FMT=6, then P=2 (only). The field polynomial is a pentanomial, 314 with the degrees of the middle terms given by the three 2-octet 315 values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI + 316 X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI 317 > DEGJ > 0. 319 DEGH, DEGI, DEGJ are two-octet fields that define the degree of 320 a term in a field polynomial. DEGH is present when FMT = 4, 321 5, or 6. DEGI and DEGJ are present only when FMT = 6. 323 TRDV is a two-octet right-adjusted binary polynomial of degree < 324 16. It is present only for FMT=5. 326 LH and H define the H parameter, present only when FMT=4 and P 327 is odd. The high bit of LH is an optional sign bit for H. 329 LK and K define the K parameter, present when FMT = 3 or 4, and 330 P is odd. The high bit of LK is an optional sign bit for K. 332 The remaining parameters are concerned with the elliptic curve and 333 the signature algorithm. 335 LQ defines the length of the prime Q. Q is a prime > 2^159. 337 In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data 338 member of the pair is an element from the finite field defined 339 earlier. The length field defines a long octet string. Field 340 elements are represented as (mod P) polynomials of degree < DEG, with 341 DEG or fewer coefficients. The coefficients are stored from left to 342 right, higher degree to lower, with the constant term last. The 343 coefficients are represented as integers in the range [0,P-1]. Each 344 coefficient is allocated an area of ceiling(log2 P) bits. The field 345 representation is right-justified; the "constant term" of the field 346 element ends at the right most bit. The coefficients are fitted 347 adjacently without regard for octet boundaries. (Example: if P=5, 348 three bits are used for each coefficient. If the field is GF[5^75], 349 then 225 bits are required for the coefficients, and as many as 29 350 octets may be needed in the data area. Fewer octets may be used if 351 some high-order coefficients are 0.) If a flag requires a field 352 element to be negated, each non-zero coefficient K is replaced with 353 P-K. To save space, 0 bits may be removed from the left end of the 354 element representation, and the length field reduced appropriately. 355 This would normally only happen with A,B,C, because the designer 356 chose curve parameters with some high-order 0 coefficients or bits. 358 If the finite field is simply (mod P), then the field elements are 359 simply numbers (mod P), in the usual right-justified notation. If 360 the finite field is GF[2^D], the field elements are the usual right- 361 justified polynomial basis representation. 363 LA,A is the first parameter of the elliptic curve equation. 364 When P>=5, the flag A = 1 indicates A should be negated (mod 365 P). When P=2 (indicated by the flag M=0), the flag A = 1 366 indicates that the parameter pair LA,A is replaced by the two 367 octet parameter ALTA. In this case, the parameter A in the 368 curve equation is x^ALTA, where x is the field generator. 369 Parameter A often has the value 0, which may be indicated by 370 LA=0 (with no A data field), and sometimes A is 1, which may 371 be represented with LA=1 and a data field of 1, or by setting 372 the A flag and using an ALTA value of 0. 374 LB,B is the second parameter of the elliptic curve equation. 375 When P>=5, the flag B = 1 indicates B should be negated (mod 376 P). When P=2 or 3, the flag B selects an alternate curve 377 equation. 379 LC,C is the third parameter of the elliptic curve equation, 380 present only when P=2 (indicated by flag M=0) and flag B=1. 382 LG,G defines a point on the curve, of order Q. The W-coordinate 383 of the curve point is given explicitly; the Z-coordinate is 384 implicit. 386 LY,Y is the user���s public signing key, another curve point of 387 order Q. The W-coordinate is given explicitly; the Z- 388 coordinate is implicit. The LY,Y parameter pair is always 389 present. 391 3. The Elliptic Curve Equation 393 (The coordinates of an elliptic curve point are named W,Z instead of 394 the more usual X,Y to avoid confusion with the Y parameter of the 395 signing key.) 397 The elliptic curve equation is determined by the flag octet, together 398 with information about the prime P. The primes 2 and 3 are special; 399 all other primes are treated identically. 401 If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3 402 + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D]. 403 If A and/or B is negative (i.e., in the range from P/2 to P), and 404 P>=5, space may be saved by putting the sign bit(s) in the A and B 405 bits of the flags octet, and the magnitude(s) in the parameter 406 fields. 408 If M=1 and P=3, the B flag has a different meaning: it specifies an 409 alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of 410 the right-hand-side is different. When P=3, this equation is more 411 commonly used. 413 If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 + 414 A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A 415 parameter can often be 0 or 1, or be chosen as a single-1-bit value. 416 The flag B is used to select an alternate curve equation, Z^2 + C*Z = 417 W^3 + A*W + B. This is the only time that the C parameter is used. 419 4. How do I Compute Q, G, and Y? 421 The number of points on the curve is the number of solutions to the 422 curve equation, + 1 (for the "point at infinity"). The prime Q must 423 divide the number of points. Usually the curve is chosen first, then 424 the number of points is determined with Schoof���s algorithm. This 425 number is factored, and if it has a large prime divisor, that number 426 is taken as Q. 428 G must be a point of order Q on the curve, satisfying the equation 430 Q * G = the point at infinity (on the elliptic curve) 432 G may be chosen by selecting a random [RFC 1750] curve point, and 433 multiplying it by (number-of-points-on-curve/Q). G must not itself 434 be the "point at infinity"; in this astronomically unlikely event, a 435 new random curve point is recalculated. 437 G is specified by giving its W-coordinate. The Z-coordinate is 438 calculated from the curve equation. In general, there will be two 439 possible Z values. The rule is to choose the "positive" value. 441 In the (mod P) case, the two possible Z values sum to P. The smaller 442 value is less than P/2; it is used in subsequent calculations. In 443 GF[P^D] fields, the highest-degree non-zero coefficient of the field 444 element Z is used; it is chosen to be less than P/2. 446 In the GF[2^N] case, the two possible Z values xor to W (or to the 447 parameter C with the alternate curve equation). The numerically 448 smaller Z value (the one which does not contain the highest-order 1 449 bit of W (or C)) is used in subsequent calculations. 451 Y is specified by giving the W-coordinate of the user���s public 452 signature key. The Z-coordinate value is determined from the curve 453 equation. As with G, there are two possible Z values; the same rule 454 is followed for choosing which Z to use. 456 During the key generation process, a random [RFC 1750] number X must 457 be generated such that 1 <= X <= Q-1. X is the private key and is 458 used in the final step of public key generation where Y is computed 459 as 461 Y = X * G (as points on the elliptic curve) 463 If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2 464 in the (mod P) case, or the high-order non-zero coefficient of Z > 465 P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the 466 GF[2^N] case), then X must be replaced with Q-X. This will 467 correspond to the correct Z-coordinate. 469 5. Performance Considerations 471 Elliptic curve signatures use smaller moduli or field sizes than RSA 472 and DSA. Creation of a curve is slow, but not done very often. Key 473 generation is faster than RSA or DSA. 475 DNS implementations have been optimized for small transfers, 476 typically less than 512 octets including DNS overhead. Larger 477 transfers will perform correctly and and extensions have been 478 standardized to make larger transfers more efficient [RFC 2671]. 479 However, it is still advisable at this time to make reasonable 480 efforts to minimize the size of RR sets stored within the DNS 481 consistent with adequate security. 483 6. Security Considerations 485 Keys retrieved from the DNS should not be trusted unless (1) they 486 have been securely obtained from a secure resolver or independently 487 verified by the user and (2) this secure resolver and secure 488 obtainment or independent verification conform to security policies 489 acceptable to the user. As with all cryptographic algorithms, 490 evaluating the necessary strength of the key is essential and 491 dependent on local policy. 493 Some specific key generation considerations are given in the body of 494 this document. 496 7. IANA Considerations 498 Assignment of meaning to the remaining ECC data flag bits or to 499 values of ECC fields outside the ranges for which meaning in defined 500 in this document requires an IETF consensus as defined in [RFC 2434]. 502 Copyright and Disclaimer 504 Copyright (C) The Internet Society 2004. This document is subject to 505 the rights, licenses and restrictions contained in BCP 78 and except 506 as set forth therein, the authors retain all their rights. 508 This document and the information contained herein are provided on an 509 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 510 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 511 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 512 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 513 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 514 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 516 Informational References 518 [RFC 1034] - P. Mockapetris, "Domain names - concepts and 519 facilities", 11/01/1987. 521 [RFC 1035] - P. Mockapetris, "Domain names - implementation and 522 specification", 11/01/1987. 524 [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness 525 Recommendations for Security", 12/29/1994. 527 [RFC intro] - "DNS Security Introduction and Requirements", R. 528 Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress, 529 draft-ietf-dnsext-dnssec-intro-*.txt. 531 [RFC protocol] - "Protocol Modifications for the DNS Security 532 Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose, 533 work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt. 535 [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August 536 1999. 538 [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, 539 Algorithms, and Source Code in C", 1996, John Wiley and Sons 541 [Menezes] - Alfred Menezes, "Elliptic Curve Public Key 542 Cryptosystems", 1993 Kluwer. 544 [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves", 545 1986, Springer Graduate Texts in mathematics #106. 547 Normative Refrences 549 [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate 550 Requirement Levels", March 1997. 552 [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an 553 IANA Considerations Section in RFCs", October 1998. 555 [RFC records] - "Resource Records for the DNS Security Extensions", 556 R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in 557 progress, draft-ietf-dnsext-dnssec-records- *.txt. 559 Authors Addresses 561 Rich Schroeppel 562 500 S. Maple Drive 563 Woodland Hills, UT 84653 USA 565 Telephone: 1-801-423-7998(h) 566 1-505-844-9079(w) 567 Email: rschroe@sandia.gov 569 Donald E. Eastlake 3rd 570 Motorola Laboratories 571 155 Beaver Street 572 Milford, MA 01757 USA 574 Telephone: +1 508-634-2066 (h) 575 +1 508-786-7554 (w) 576 EMail: Donald.Eastlake@motorola.com 578 Expiration and File Name 580 This draft expires in February 2004. 582 Its file name is draft-ietf-dnsext-ecc-key-05.txt.