draft-ietf-dnsext-ecc-key-09.txt   draft-ietf-dnsext-ecc-key-10.txt 
INTERNET-DRAFT Richard C. Schroeppel INTERNET-DRAFT Richard C. Schroeppel
Donald E. Eastlake 3rd Intended status: Proposed Standard Donald E. Eastlake 3rd
Elliptic Curve Keys and Signatures in the Domain Name System (DNS) Elliptic Curve Keys and Signatures in the Domain Name System (DNS)
-------- ----- ---- --- ---------- -- --- ------ ---- ------ ----- -------- ----- ---- --- ---------- -- --- ------ ---- ------ -----
<draft-ietf-dnsext-ecc-key-09.txt> <draft-ietf-dnsext-ecc-key-10.txt>
Richard C. Schroeppel Richard C. Schroeppel
Donald Eastlake 3rd Donald Eastlake 3rd
Status of This Document Status of This Document
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
This draft is intended to be become a Proposed Standard RFC.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
to the DNS mailing list <namedroppers@ops.ietf.org>. to the DNS mailing list <namedroppers@ops.ietf.org>.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 1, line 45 skipping to change at page 2, line 5
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
The standard format for storing elliptic curve cryptographic keys and The standard format for storing elliptic curve cryptographic keys and
elliptic curve SHA-1 based signatures in the Domain Name System (DNS) elliptic curve SHA-1 based signatures in the Domain Name System (DNS)
is specified. is specified.
Copyright Notice
Copyright (C) The Internet Society (2006).
INTERNET-DRAFT ECC in the DNS INTERNET-DRAFT ECC in the DNS
Acknowledgement Acknowledgement
The assistance of Hilarie K. Orman in the production of this document The assistance of Hilarie K. Orman in the production of this document
is greatfully acknowledged. is greatfully acknowledged.
Table of Contents Table of Contents
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................1 Abstract...................................................1
Copyright Notice...........................................1
Acknowledgement............................................2 Acknowledgement............................................2
Table of Contents..........................................2 Table of Contents..........................................2
1. Introduction............................................3 1. Introduction............................................3
2. Elliptic Curve Keys in Resource Records.................3 2. Elliptic Curve Keys in Resource Records.................3
3. The Elliptic Curve Equation.............................9 3. The Elliptic Curve Equation.............................9
4. How do I Compute Q, G, and Y?..........................10 4. How do I Compute Q, G, and Y?..........................10
5. Elliptic Curve Signatures..............................11 5. Elliptic Curve Signatures..............................11
6. Performance Considerations.............................13 6. Performance Considerations.............................13
7. Security Considerations................................13 7. Security Considerations................................13
8. IANA Considerations....................................13 8. IANA Considerations....................................13
Copyright, Disclaimer, and Additional IPR Provisions......13
Copyright and Additional IPR Provisions...................14
Informational References..................................15 Informational References..................................15
Normative Refrences.......................................15 Normative Refrences.......................................15
Author's Addresses........................................16 Author's Addresses........................................16
Expiration and File Name..................................16 Expiration and File Name..................................16
Disclaimer................................................16
INTERNET-DRAFT ECC in the DNS INTERNET-DRAFT ECC in the DNS
1. Introduction 1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and distributed database system for Internet addressing, mail proxy, and
other information. [RFC 1034, 1035] The DNS stores data in resource other information. [RFC1034] [RFC1035] The DNS stores data in
records and has been extended to include digital signatures and resource records and has been extended to include digital signatures
cryptographic keys in some of these resource records. and cryptographic keys in some of these resource records.
This document describes how to format elliptic curve cryptographic This document describes how to format elliptic curve cryptographic
(ECC) key and signature data in the DNS so they can be used for a (ECC) key and signature data in the DNS so they can be used for a
variety of purposes. The signatures use the SHA-1 eigest algorithm variety of purposes. The signatures use the SHA-1 eigest algorithm
[RFC 3174]. Familiarity with ECC cryptography is assumed [Menezes]. [RFC 3174]. Familiarity with ECC cryptography is assumed [Menezes].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119]. document are to be interpreted as described in [RFC 2119].
skipping to change at page 7, line 29 skipping to change at page 7, line 29
When FMT=2, the field polynomial is specified implicitly. No other When FMT=2, the field polynomial is specified implicitly. No other
parameters are required to define the field; the next parameters parameters are required to define the field; the next parameters
present will be the LQ,Q pair. The implicit field poynomial is the present will be the LQ,Q pair. The implicit field poynomial is the
lexicographically smallest irreducible (mod P) polynomial of the lexicographically smallest irreducible (mod P) polynomial of the
correct degree. The ordering of polynomials is by highest-degree correct degree. The ordering of polynomials is by highest-degree
coefficients first -- the leading coefficient 1 is most important, coefficients first -- the leading coefficient 1 is most important,
and the constant term is least important. Coefficients are ordered and the constant term is least important. Coefficients are ordered
by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of by sign-magnitude: 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 degree D is X^D (which is not irreducible). The next is X^D+1, which
is sometimes irreducible, followed by X^D-1, which isn't. Assuming is sometimes irreducible, followed by X^D-1, which isn$t. Assuming
odd P, this series continues to X^D - (P-1)/2, and then goes to X^D + odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
X, X^D + X + 1, X^D + X - 1, etc. 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 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 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 term K. Of all the field parameters, only the LK,K parameters are
present. The high-order bit of the LK octet stores on optional sign present. The high-order bit of the LK octet stores on optional sign
for K; if the sign bit is present, the field polynomial is X^DEG - K. 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 + When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
skipping to change at page 9, line 30 skipping to change at page 9, line 30
P). When P=2 or 3, the flag B selects an alternate curve P). When P=2 or 3, the flag B selects an alternate curve
equation. equation.
LC,C is the third parameter of the elliptic 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. 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 W-coordinate LG,G defines a point on the curve, of order Q. The W-coordinate
of the curve point is given explicitly; the Z-coordinate is of the curve point is given explicitly; the Z-coordinate is
implicit. 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 W-coordinate is given explicitly; the Z- order Q. The W-coordinate is given explicitly; the Z-
coordinate is implicit. The LY,Y parameter pair is always coordinate is implicit. The LY,Y parameter pair is always
present. present.
3. The Elliptic Curve Equation 3. The Elliptic Curve Equation
(The coordinates of an elliptic curve point are named W,Z instead of (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 the more usual X,Y to avoid confusion with the Y parameter of the
signing key.) signing key.)
skipping to change at page 10, line 20 skipping to change at page 10, line 20
A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A 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 single-1-bit value. parameter can often be 0 or 1, or be chosen as a single-1-bit value.
The flag B is used to select an alternate curve equation, Z^2 + C*Z = 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. 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? 4. How do I Compute Q, G, and Y?
The number of points on the curve is the number of solutions to the 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 curve equation, + 1 (for the "point at infinity"). The prime Q must
divide the number of points. Usually the curve is chosen first, then 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 number is factored, and if it has a large prime divisor, that number
is taken as Q. is taken as Q.
G must be a point of order Q on the curve, satisfying the equation G must be a point of order Q on the curve, satisfying the equation
Q * G = the point at infinity (on the elliptic curve) Q * G = the point at infinity (on the elliptic curve)
G may be chosen by selecting a random [RFC 1750] curve point, and G may be chosen by selecting a random [RFC4086] curve point, and
multiplying it by (number-of-points-on-curve/Q). G must not itself multiplying it by (number-of-points-on-curve/Q). G must not itself
be the "point at infinity"; in this astronomically unlikely event, a be the "point at infinity"; in this astronomically unlikely event, a
new random curve point is recalculated. new random curve point is recalculated.
G is specified by giving its W-coordinate. The Z-coordinate is G is specified by giving its W-coordinate. The Z-coordinate is
calculated from the curve equation. In general, there will be two calculated from the curve equation. In general, there will be two
possible Z values. The rule is to choose the "positive" value. possible Z values. The rule is to choose the "positive" value.
In the (mod P) case, the two possible Z values sum to P. The smaller 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 value is less than P/2; it is used in subsequent calculations. In
GF[P^D] fields, the highest-degree non-zero coefficient of the field GF[P^D] fields, the highest-degree non-zero coefficient of the field
element Z is used; it is chosen to be less than P/2. 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 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 parameter C with the alternate curve equation). The numerically
smaller Z value (the one which does not contain the highest-order 1 smaller Z value (the one which does not contain the highest-order 1
bit of W (or C)) is used in subsequent calculations. bit of W (or C)) is used in subsequent calculations.
Y is specified by giving the W-coordinate of the user's public Y is specified by giving the W-coordinate of the user$s public
signature key. The Z-coordinate value is determined from the curve signature key. The Z-coordinate value is determined from the curve
equation. As with G, there are two possible Z values; the same rule equation. As with G, there are two possible Z values; the same rule
is followed for choosing which Z to use. is followed for choosing which Z to use.
INTERNET-DRAFT ECC in the DNS INTERNET-DRAFT ECC in the DNS
During the key generation process, a random [RFC 1750] number X must During the key generation process, a random [RFC4086] number X must
be generated such that 1 <= X <= Q-1. X is the private key and is be generated such that 1 <= X <= Q-1. X is the private key and is
used in the final step of public key generation where Y is computed used in the final step of public key generation where Y is computed
as as
Y = X * G (as points on the elliptic curve) Y = X * G (as points on the elliptic curve)
If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2 If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
in the (mod P) case, or the high-order non-zero coefficient of Z > in the (mod P) case, or the high-order non-zero coefficient of Z >
P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
GF[2^N] case), then X must be replaced with Q-X. This will GF[2^N] case), then X must be replaced with Q-X. This will
correspond to the correct Z-coordinate. correspond to the correct Z-coordinate.
5. Elliptic Curve Signatures 5. Elliptic Curve Signatures
The signature portion of an RR RDATA area when using the ECC The signature portion of an RR RDATA area when using the ECC
algorithm, for example in the SIG and RRSIG [RFC 4304] RRs is shown algorithm, for example in the SIG and RRSIG [RFC4034] RRs is shown
below. below.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R, (length determined from LQ) .../ | R, (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S, (length determined from LQ) .../ | S, (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R and S are integers (mod Q). Their length is specified by the LQ R and S are integers (mod Q). Their length is specified by the LQ
field of the corresponding KEY RR and can also be calculated from the field of the corresponding KEY RR and can also be calculated from the
SIG RR's RDLENGTH. They are right justified, high-order-octet first. SIG RR$s RDLENGTH. They are right justified, high-order-octet first.
The same conditional formula for calculating the length from LQ is The same conditional formula for calculating the length from LQ is
used as for all the other length fields above. used as for all the other length fields above.
The data signed is determined as specified in [RFC 2535]. Then the The data signed is determined as specified in [RFC4034]. Then the
following steps are taken where Q, P, G, and Y are as specified in following steps are taken where Q, P, G, and Y are as specified in
the public key [Schneier]. For further information on SHA-1, see [RFC the public key [Schneier]. For further information on SHA-1, see
3174]. [RFC3174].
hash = SHA-1 ( data ) hash = SHA-1 ( data )
Generate random [RFC 4086] K such that 0 < K < Q. (Never sign Generate random [RFC 4086] K such that 0 < K < Q. (Never sign
two different messages with the same K. K should be chosen two different messages with the same K. K should be chosen
from a very large space: If an opponent learns a K value from a very large space: If an opponent learns a K value
for a single signature, the user's signing key is for a single signature, the user$s signing key is
compromised, and a forger can sign arbitrary messages. compromised, and a forger can sign arbitrary messages.
There is no harm in signing the same message multiple times There is no harm in signing the same message multiple times
with the same key or different keys.) with the same key or different keys.)
INTERNET-DRAFT ECC in the DNS INTERNET-DRAFT ECC in the DNS
R = (the W-coordinate of ( K*G on the elliptic curve )) R = (the W-coordinate of ( K*G on the elliptic curve ))
interpreted as an integer, and reduced (mod Q). (R must interpreted as an integer, and reduced (mod Q). (R must
not be 0. In this astronomically unlikely event, generate not be 0. In this astronomically unlikely event, generate
a new random K and recalculate R.) a new random K and recalculate R.)
skipping to change at page 12, line 46 skipping to change at page 12, line 46
V = (the W-coordinate of this point) interpreted as an integer V = (the W-coordinate of this point) interpreted as an integer
and reduced (mod Q). and reduced (mod Q).
The signature is valid if V = R. The signature is valid if V = R.
The reason for requiring S < Q/2 is that, otherwise, both (R,S) and The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
(R,Q-S) would be valid signatures for the same data. Note that a (R,Q-S) would be valid signatures for the same data. Note that a
signature that is valid for hash(data) is also valid for hash(data)+Q signature that is valid for hash(data) is also valid for hash(data)+Q
or hash(data)-Q, if these happen to fall in the range [0,2^160-1]. or hash(data)-Q, if these happen to fall in the range [0,2^160-1].
It's believed to be computationally infeasible to find data that It$s believed to be computationally infeasible to find data that
hashes to an assigned value, so this is only a cosmetic blemish. The hashes to an assigned value, so this is only a cosmetic blemish. The
blemish can be eliminated by using Q > 2^160, at the cost of having blemish can be eliminated by using Q > 2^160, at the cost of having
slightly longer signatures, 42 octets instead of 40. slightly longer signatures, 42 octets instead of 40.
We must specify how a field-element E ("the W-coordinate") is to be We must specify how a field-element E ("the W-coordinate") is to be
interpreted as an integer. The field-element E is regarded as a interpreted as an integer. The field-element E is regarded as a
radix-P integer, with the digits being the coefficients in the radix-P integer, with the digits being the coefficients in the
polynomial basis representation of E. The digits are in the ragne polynomial basis representation of E. The digits are in the ragne
[0,P-1]. In the two most common cases, this reduces to "the obvious [0,P-1]. In the two most common cases, this reduces to "the obvious
thing". In the (mod P) case, E is simply a residue mod P, and is thing". In the (mod P) case, E is simply a residue mod P, and is
INTERNET-DRAFT ECC in the DNS INTERNET-DRAFT ECC in the DNS
taken as an integer in the range [0,P-1]. In the GF[2^D] case, E is taken as an integer in the range [0,P-1]. In the GF[2^D] case, E is
in the D-bit polynomial basis representation, and is simply taken as in the D-bit polynomial basis representation, and is simply taken as
an integer in the range [0,(2^D)-1]. For other fields GF[P^D], it's an integer in the range [0,(2^D)-1]. For other fields GF[P^D], it$s
necessary to do some radix conversion arithmetic. necessary to do some radix conversion arithmetic.
6. Performance Considerations 6. Performance Considerations
Elliptic curve signatures use smaller moduli or field sizes than RSA Elliptic curve signatures use smaller moduli or field sizes than RSA
and DSA. Creation of a curve is slow, but not done very often. Key and DSA. Creation of a curve is slow, but not done very often. Key
generation is faster than RSA or DSA. generation is faster than RSA or DSA.
DNS implementations have been optimized for small transfers, DNS implementations have been optimized for small transfers,
typically less than 512 octets including DNS overhead. Larger typically less than 512 octets including DNS overhead. Larger
skipping to change at page 13, line 32 skipping to change at page 13, line 32
However, it is still advisable at this time to make reasonable However, it is still advisable at this time to make reasonable
efforts to minimize the size of RR sets stored within the DNS efforts to minimize the size of RR sets stored within the DNS
consistent with adequate security. consistent with adequate security.
7. Security Considerations 7. Security Considerations
Keys retrieved from the DNS should not be trusted unless (1) they Keys retrieved from the DNS should not be trusted unless (1) they
have been securely obtained from a secure resolver or independently have been securely obtained from a secure resolver or independently
verified by the user and (2) this secure resolver and secure verified by the user and (2) this secure resolver and secure
obtainment or independent verification conform to security policies obtainment or independent verification conform to security policies
acceptable to the user. As with all cryptographic algorithms, acceptable to the user. [RFC4033] [RFC4034] [RFC4035] As with all
evaluating the necessary strength of the key is essential and cryptographic algorithms, evaluating the necessary strength of the
dependent on local policy. key is essential and dependent on local policy.
Some specific key generation considerations are given in the body of Some specific key generation considerations are given in the body of
this document. this document.
8. IANA Considerations 8. IANA Considerations
Assignment of meaning to the remaining ECC data flag bits or to Assignment of meaning to the remaining ECC data flag bits or to
values of ECC fields outside the ranges for which meaning in defined values of ECC fields outside the ranges for which meaning in defined
in this document requires an IETF consensus as defined in [RFC 2434]. in this document requires an IETF consensus as defined in [RFC 2434].
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (C) The Internet Society 2006.
INTERNET-DRAFT ECC in the DNS INTERNET-DRAFT ECC in the DNS
This document is subject to the rights, licenses and restrictions Copyright and Additional IPR Provisions
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.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 15, line 5 skipping to change at page 14, line 31
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Copyright (C) The IETF Trust (2007)
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.
INTERNET-DRAFT ECC in the DNS INTERNET-DRAFT ECC in the DNS
Informational References Informational References
[RFC 1034] - P. Mockapetris, "Domain names - concepts and [RFC1034] - P. Mockapetris, "Domain names - concepts and facilities",
facilities", 11/01/1987. 11/01/1987.
[RFC 1035] - P. Mockapetris, "Domain names - implementation and [RFC 1035] - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987. specification", 11/01/1987.
[RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August
1999. 1999.
[RFC 4025] - M. Richardson, "A Method for Storing IPsec Keying [RFC 4025] - M. Richardson, "A Method for Storing IPsec Keying
Material in DNS", February 2005. Material in DNS", February 2005.
skipping to change at page 15, line 46 skipping to change at page 15, line 46
Cryptosystems", 1993 Kluwer. Cryptosystems", 1993 Kluwer.
[Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves", [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves",
1986, Springer Graduate Texts in mathematics #106. 1986, Springer Graduate Texts in mathematics #106.
Normative Refrences Normative Refrences
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an [RFC2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
IANA Considerations Section in RFCs", October 1998. Considerations Section in RFCs", October 1998.
[RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
1 (SHA1)", RFC 3174, September 2001. 1 (SHA1)", RFC 3174, September 2001.
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034, Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005. March 2005.
INTERNET-DRAFT ECC in the DNS INTERNET-DRAFT ECC in the DNS
skipping to change at page 16, line 26 skipping to change at page 16, line 26
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Motorola Laboratories Motorola Laboratories
155 Beaver Street 155 Beaver Street
Milford, MA 01757 USA Milford, MA 01757 USA
Telephone: +1 508-786-7554 (w) Telephone: +1 508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com EMail: Donald.Eastlake@motorola.com
Expiration and File Name Expiration and File Name
This draft expires in October 2006. This draft expires in September 2007.
Its file name is draft-ietf-dnsext-ecc-key-09.txt. Its file name is draft-ietf-dnsext-ecc-key-10.txt.
Disclaimer
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, THE IETF TRUST 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.
 End of changes. 29 change blocks. 
49 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/