 1/draftietfdnsextecckey04.txt 20060204 23:10:34.000000000 +0100
+++ 2/draftietfdnsextecckey05.txt 20060204 23:10:34.000000000 +0100
@@ 1,112 +1,123 @@
+©À
INTERNETDRAFT ECC Keys in the DNS
Expires: February 2004 August 2003
+Expires: February 2005 August 2004
Elliptic Curve KEYs in the DNS
     

+
Richard C. Schroeppel
Donald Eastlake 3rd
Status of This Document
+ By submitting this InternetDraft, 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.
+
This draft is intended to be become a Proposed Standard RFC.
Distribution of this document is unlimited. Comments should be sent
 to the DNS mailing list or to the
 authors.
+ to the DNS mailing list .
 This document is an Internet Draft and is in full conformance with
 all provisions of Section 10 of RFC 2026. Internet Drafts are
 working documents of the Internet Engineering Task Force (IETF), its
 areas, and its working groups. Note that other groups may also
 distribute working documents as Internet Drafts.
+ InternetDrafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet
+ Drafts.
InternetDrafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
 time. It is inappropriate to use Internet Drafts as reference
 material or to cite them other than as "work in progress."
+ time. It is inappropriate to use InternetDrafts as reference
+ material or to cite them other than a "work in progress."
The list of current InternetDrafts can be accessed at
 http://www.ietf.org/ietf/1idabstracts.txt
+ http://www.ietf.org/1idabstracts.html
The list of InternetDraft Shadow Directories can be accessed at
 http://www.ietf.org/shadow.html.
+ http://www.ietf.org/shadow.html
Abstract
 A standard method for storing elliptic curve cryptographic keys in
 the Domain Name System is described.
+ The standard method for storing elliptic curve cryptographic keys in
+ the Domain Name System is specified.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society. All Rights Reserved.
INTERNETDRAFT ECC Keys in the DNS
Acknowledgement
The assistance of Hilarie K. Orman in the production of this document
is greatfully acknowledged.
Table of Contents
Status of This Document....................................1
Abstract...................................................1
+ Copyright Notice...........................................1
Acknowledgement............................................2
Table of Contents..........................................2
1. Introduction............................................3
2. Elliptic Curve Data in Resource Records.................3
3. The Elliptic Curve Equation.............................9
4. How do I Compute Q, G, and Y?..........................10
5. Performance Considerations.............................11
6. Security Considerations................................11
7. IANA Considerations....................................11
+ Copyright and Disclaimer..................................12
 Informational References..................................12
 Normative Refrences.......................................12
+ Informational References..................................13
+ Normative Refrences.......................................13
 Authors' Addresses........................................13
 Expiration and File Name..................................13
+ Authors Addresses.........................................14
+ Expiration and File Name..................................14
INTERNETDRAFT ECC Keys in the DNS
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information. The DNS has been extended to include digital
 signatures and cryptographic keys as described in [RFC 2535].
+ signatures and cryptographic keys as described in [RFC intro,
+ protocol, records].
This document describes how to store elliptic curve cryptographic
(ECC) keys in the DNS so they can be used for a variety of security
purposes. A DNS elliptic curve SIG resource record is not defined.
Familiarity with ECC cryptography is assumed [Menezes].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
2. Elliptic Curve Data in Resource Records
Elliptic curve public keys are stored in the DNS within the RDATA
 portions of RRs with the structure shown below.
+ portions of key RRs with the structure shown below [RFC records].
The period of key validity may not be in the RR with the key but
could be indicated by RR(s) with signatures that authenticates the
RR(s) containing the key.
The research world continues to work on the issue of which is the
best elliptic curve system, which finite field to use, and how to
 best represent elements in the field. So, we have defined
 representations for every type of finite field, and every type of
 elliptic curve. The reader should be aware that there is a unique
 finite field with a particular number of elements, but many possible
+ best represent elements in the field. So, representations are
+ defined for every type of finite field, and every type of elliptic
+ curve. The reader should be aware that there is a unique finite
+ field with a particular number of elements, but many possible
representations of that field and its elements. If two different
representations of a field are given, they are interconvertible with
a tedious but practical precomputation, followed by a fast
computation for each field element to be converted. It is perfectly
reasonable for an algorithm to work internally with one field
representation, and convert to and from a different external
representation.
INTERNETDRAFT ECC Keys in the DNS
@@ 278,25 +289,25 @@
extension. The finite field will have P^DEG elements. DEG is
present when FMT>=2.
When FMT=2, the field polynomial is specified implicitly. No other
parameters are required to define the field; the next parameters
present will be the LQ,Q pair. The implicit field poynomial is the
lexicographically smallest irreducible (mod P) polynomial of the
correct degree. The ordering of polynomials is by highestdegree
coefficients first  the leading coefficient 1 is most important,
and the constant term is least important. Coefficients are ordered
 by signmagnitude: 0 < 1 < 1 < 2 < 2 < ... The first polynomial
 of degree D is X^D (which is not irreducible). The next is X^D+1,
 which is sometimes irreducible, followed by X^D1, which isn't.
 Assuming odd P, this series continues to X^D  (P1)/2, and then goes
 to X^D + X, X^D + X + 1, X^D + X  1, etc.
+ by signmagnitude: 0 < 1 < 1 < 2 < 2 < ... The first polynomial of
+ degree D is X^D (which is not irreducible). The next is X^D+1, which
+ is sometimes irreducible, followed by X^D1, which isn‚ÇÖt. Assuming
+ odd P, this series continues to X^D  (P1)/2, and then goes to X^D +
+ X, X^D + X + 1, X^D + X  1, etc.
When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be
odd. The polynomial is determined by the degree and the low order
term K. Of all the field parameters, only the LK,K parameters are
present. The highorder bit of the LK octet stores on optional sign
for K; if the sign bit is present, the field polynomial is X^DEG  K.
When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
K. When P=2, the H and K parameters are implicitly 1, and are
omitted from the representation. Only DEG and DEGH are present; the
@@ 384,21 +395,21 @@
P). When P=2 or 3, the flag B selects an alternate curve
equation.
LC,C is the third parameter of the elliptic curve equation,
present only when P=2 (indicated by flag M=0) and flag B=1.
LG,G defines a point on the curve, of order Q. The Wcoordinate
of the curve point is given explicitly; the Zcoordinate is
implicit.
 LY,Y is the user's public signing key, another curve point of
+ LY,Y is the user‚ÇÖs public signing key, another curve point of
order Q. The Wcoordinate is given explicitly; the Z
coordinate is implicit. The LY,Y parameter pair is always
present.
3. The Elliptic Curve Equation
(The coordinates of an elliptic curve point are named W,Z instead of
the more usual X,Y to avoid confusion with the Y parameter of the
signing key.)
@@ 425,21 +436,21 @@
A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A
parameter can often be 0 or 1, or be chosen as a single1bit value.
The flag B is used to select an alternate curve equation, Z^2 + C*Z =
W^3 + A*W + B. This is the only time that the C parameter is used.
4. How do I Compute Q, G, and Y?
The number of points on the curve is the number of solutions to the
curve equation, + 1 (for the "point at infinity"). The prime Q must
divide the number of points. Usually the curve is chosen first, then
 the number of points is determined with Schoof's algorithm. This
+ the number of points is determined with Schoof‚ÇÖs algorithm. This
number is factored, and if it has a large prime divisor, that number
is taken as Q.
G must be a point of order Q on the curve, satisfying the equation
Q * G = the point at infinity (on the elliptic curve)
G may be chosen by selecting a random [RFC 1750] curve point, and
multiplying it by (numberofpointsoncurve/Q). G must not itself
be the "point at infinity"; in this astronomically unlikely event, a
@@ 452,21 +463,21 @@
In the (mod P) case, the two possible Z values sum to P. The smaller
value is less than P/2; it is used in subsequent calculations. In
GF[P^D] fields, the highestdegree nonzero coefficient of the field
element Z is used; it is chosen to be less than P/2.
In the GF[2^N] case, the two possible Z values xor to W (or to the
parameter C with the alternate curve equation). The numerically
smaller Z value (the one which does not contain the highestorder 1
bit of W (or C)) is used in subsequent calculations.
 Y is specified by giving the Wcoordinate of the user's public
+ Y is specified by giving the Wcoordinate of the user‚ÇÖs public
signature key. The Zcoordinate value is determined from the curve
equation. As with G, there are two possible Z values; the same rule
is followed for choosing which Z to use.
INTERNETDRAFT ECC Keys in the DNS
During the key generation process, a random [RFC 1750] number X must
be generated such that 1 <= X <= Q1. X is the private key and is
used in the final step of public key generation where Y is computed
as
@@ 488,48 +499,74 @@
DNS implementations have been optimized for small transfers,
typically less than 512 octets including DNS overhead. Larger
transfers will perform correctly and and extensions have been
standardized to make larger transfers more efficient [RFC 2671].
However, it is still advisable at this time to make reasonable
efforts to minimize the size of RR sets stored within the DNS
consistent with adequate security.
6. Security Considerations
 Many of the general security consideration in [RFC 2535] apply. Some
 specific key generation considerations are given above. Of course,
 the elliptic curve key stored in the DNS for an entity should not be
 trusted unless it has been obtain via a trusted DNS resolver that
 vouches for its security or unless the application using the key has
 done a similar authentication.
+ Keys retrieved from the DNS should not be trusted unless (1) they
+ have been securely obtained from a secure resolver or independently
+ verified by the user and (2) this secure resolver and secure
+ obtainment or independent verification conform to security policies
+ acceptable to the user. As with all cryptographic algorithms,
+ evaluating the necessary strength of the key is essential and
+ dependent on local policy.
+
+ Some specific key generation considerations are given in the body of
+ this document.
7. IANA Considerations
Assignment of meaning to the remaining ECC data flag bits or to
values of ECC fields outside the ranges for which meaning in defined
+
+INTERNETDRAFT ECC Keys in the DNS
+
in this document requires an IETF consensus as defined in [RFC 2434].
+Copyright and Disclaimer
+
+ Copyright (C) The Internet Society 2004. This document is subject to
+ the rights, licenses and restrictions contained in BCP 78 and except
+ as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
INTERNETDRAFT ECC Keys in the DNS
Informational References
[RFC 1034]  P. Mockapetris, "Domain names  concepts and
facilities", 11/01/1987.
[RFC 1035]  P. Mockapetris, "Domain names  implementation and
specification", 11/01/1987.
[RFC 1750]  D. Eastlake, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", 12/29/1994.
 [RFC 2535]  D. Eastlake,"Domain Name System Security Extensions",
 March 1999.
+ [RFC intro]  "DNS Security Introduction and Requirements", R.
+ Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress,
+ draftietfdnsextdnssecintro*.txt.
+
+ [RFC protocol]  "Protocol Modifications for the DNS Security
+ Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose,
+ work in progress, draftietfdnsextdnssecprotocol*.txt.
[RFC 2671]  P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August
1999.
[Schneier]  Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons
[Menezes]  Alfred Menezes, "Elliptic Curve Public Key
Cryptosystems", 1993 Kluwer.
@@ 537,37 +574,40 @@
1986, Springer Graduate Texts in mathematics #106.
Normative Refrences
[RFC 2119]  S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2434]  T. Narten, H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", October 1998.
+ [RFC records]  "Resource Records for the DNS Security Extensions",
+ R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in
+ progress, draftietfdnsextdnssecrecords *.txt.
+
INTERNETDRAFT ECC Keys in the DNS
Authors' Addresses
+Authors Addresses
Rich Schroeppel
500 S. Maple Drive
Woodland Hills, UT 84653 USA
Telephone: 18014237998(h)
15058449079(w)
 Email: rcs@cs.arizona.edu
 rschroe@sandia.gov
+ Email: rschroe@sandia.gov
Donald E. Eastlake 3rd
 Motorola
+ Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1 5086342066 (h)
 +1 5088518280 (w)
+ +1 5087867554 (w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in February 2004.
 Its file name is draftietfdnsextecckey04.txt.
+ Its file name is draftietfdnsextecckey05.txt.