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/ |