draft-ietf-dnsext-ecc-key-04.txt | draft-ietf-dnsext-ecc-key-05.txt | |||
---|---|---|---|---|

©À | ||||

INTERNET-DRAFT ECC Keys in the DNS | INTERNET-DRAFT ECC Keys in the DNS | |||

Expires: February 2004 August 2003 | Expires: February 2005 August 2004 | |||

Elliptic Curve KEYs in the DNS | Elliptic Curve KEYs in the DNS | |||

-------- ----- ---- -- --- --- | -------- ----- ---- -- --- --- | |||

<draft-ietf-dnsext-ecc-key-04.txt> | <draft-ietf-dnsext-ecc-key-05.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, 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. | 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@internic.com> or to the | to the DNS mailing list <namedroppers@ops.ietf.org>. | |||

authors. | ||||

This document is an Internet Draft and is in full conformance with | Internet-Drafts are working documents of the Internet Engineering | |||

all provisions of Section 10 of RFC 2026. Internet Drafts are | Task Force (IETF), its areas, and its working groups. Note that | |||

working documents of the Internet Engineering Task Force (IETF), its | other groups may also distribute working documents as Internet- | |||

areas, and its working groups. Note that other groups may also | Drafts. | |||

distribute working documents as Internet 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 | |||

time. It is inappropriate to use Internet Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||

material or to cite them other than as "work in progress." | material or to cite them other than a "work in progress." | |||

The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||

http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/1id-abstracts.html | |||

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

A standard method for storing elliptic curve cryptographic keys in | The standard method for storing elliptic curve cryptographic keys in | |||

the Domain Name System is described. | the Domain Name System is specified. | |||

Copyright Notice | ||||

Copyright (C) The Internet Society. All Rights Reserved. | ||||

INTERNET-DRAFT ECC Keys in the DNS | INTERNET-DRAFT ECC Keys 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 Data in Resource Records.................3 | 2. Elliptic Curve Data 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. Performance Considerations.............................11 | 5. Performance Considerations.............................11 | |||

6. Security Considerations................................11 | 6. Security Considerations................................11 | |||

7. IANA Considerations....................................11 | 7. IANA Considerations....................................11 | |||

Copyright and Disclaimer..................................12 | ||||

Informational References..................................12 | Informational References..................................13 | |||

Normative Refrences.......................................12 | Normative Refrences.......................................13 | |||

Authors' Addresses........................................13 | Authors Addresses.........................................14 | |||

Expiration and File Name..................................13 | Expiration and File Name..................................14 | |||

INTERNET-DRAFT ECC Keys in the DNS | INTERNET-DRAFT ECC Keys 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. The DNS has been extended to include digital | 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 | This document describes how to store elliptic curve cryptographic | |||

(ECC) keys in the DNS so they can be used for a variety of security | (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. | purposes. A DNS elliptic curve SIG resource record is not defined. | |||

Familiarity with ECC cryptography is assumed [Menezes]. | 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]. | |||

2. Elliptic Curve Data in Resource Records | 2. Elliptic Curve Data in Resource Records | |||

Elliptic curve public keys are stored in the DNS within the RDATA | 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 | 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 | could be indicated by RR(s) with signatures that authenticates the | |||

RR(s) containing the key. | RR(s) containing the key. | |||

The research world continues to work on the issue of which is the | 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 elliptic curve system, which finite field to use, and how to | |||

best represent elements in the field. So, we have defined | best represent elements in the field. So, representations are | |||

representations for every type of finite field, and every type of | defined for every type of finite field, and every type of elliptic | |||

elliptic curve. The reader should be aware that there is a unique | curve. The reader should be aware that there is a unique finite | |||

finite field with a particular number of elements, but many possible | field with a particular number of elements, but many possible | |||

representations of that field and its elements. If two different | representations of that field and its elements. If two different | |||

representations of a field are given, they are interconvertible with | representations of a field are given, they are interconvertible with | |||

a tedious but practical precomputation, followed by a fast | a tedious but practical precomputation, followed by a fast | |||

computation for each field element to be converted. It is perfectly | computation for each field element to be converted. It is perfectly | |||

reasonable for an algorithm to work internally with one field | reasonable for an algorithm to work internally with one field | |||

representation, and convert to and from a different external | representation, and convert to and from a different external | |||

representation. | representation. | |||

INTERNET-DRAFT ECC Keys in the DNS | INTERNET-DRAFT ECC Keys in the DNS | |||

skipping to change at page 7, line 27 | skipping to change at page 7, line 27 | |||

extension. The finite field will have P^DEG elements. DEG is | extension. The finite field will have P^DEG elements. DEG is | |||

present when FMT>=2. | present when FMT>=2. | |||

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 | by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of | |||

of degree D is X^D (which is not irreducible). The next is X^D+1, | degree D is X^D (which is not irreducible). The next is X^D+1, which | |||

which is sometimes irreducible, followed by X^D-1, which isn't. | is sometimes irreducible, followed by X^D-1, which isn‚ÇÖt. Assuming | |||

Assuming odd P, this series continues to X^D - (P-1)/2, and then goes | odd P, this series continues to X^D - (P-1)/2, and then goes to X^D + | |||

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

K. When P=2, the H and K parameters are implicitly 1, and are | 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 | omitted from the representation. Only DEG and DEGH are present; the | |||

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 [RFC 1750] 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 | |||

skipping to change at page 10, line 47 | skipping to change at page 10, line 47 | |||

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 Keys in the DNS | INTERNET-DRAFT ECC Keys in the DNS | |||

During the key generation process, a random [RFC 1750] number X must | During the key generation process, a random [RFC 1750] 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 | |||

skipping to change at page 11, line 36 | skipping to change at page 11, line 36 | |||

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

transfers will perform correctly and and extensions have been | transfers will perform correctly and and extensions have been | |||

standardized to make larger transfers more efficient [RFC 2671]. | standardized to make larger transfers more efficient [RFC 2671]. | |||

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

6. Security Considerations | 6. Security Considerations | |||

Many of the general security consideration in [RFC 2535] apply. Some | Keys retrieved from the DNS should not be trusted unless (1) they | |||

specific key generation considerations are given above. Of course, | have been securely obtained from a secure resolver or independently | |||

the elliptic curve key stored in the DNS for an entity should not be | verified by the user and (2) this secure resolver and secure | |||

trusted unless it has been obtain via a trusted DNS resolver that | obtainment or independent verification conform to security policies | |||

vouches for its security or unless the application using the key has | acceptable to the user. As with all cryptographic algorithms, | |||

done a similar authentication. | 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 | 7. 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 | |||

INTERNET-DRAFT ECC Keys in the DNS | ||||

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

INTERNET-DRAFT ECC Keys in the DNS | INTERNET-DRAFT ECC Keys in the DNS | |||

Informational References | Informational References | |||

[RFC 1034] - P. Mockapetris, "Domain names - concepts and | [RFC 1034] - P. Mockapetris, "Domain names - concepts and | |||

facilities", 11/01/1987. | facilities", 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 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness | [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness | |||

Recommendations for Security", 12/29/1994. | Recommendations for Security", 12/29/1994. | |||

[RFC 2535] - D. Eastlake,"Domain Name System Security Extensions", | [RFC intro] - "DNS Security Introduction and Requirements", R. | |||

March 1999. | Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress, | |||

draft-ietf-dnsext-dnssec-intro-*.txt. | ||||

[RFC protocol] - "Protocol Modifications for the DNS Security | ||||

Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose, | ||||

work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt. | ||||

[RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August | [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August | |||

1999. | 1999. | |||

[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, | [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, | |||

Algorithms, and Source Code in C", 1996, John Wiley and Sons | Algorithms, and Source Code in C", 1996, John Wiley and Sons | |||

[Menezes] - Alfred Menezes, "Elliptic Curve Public Key | [Menezes] - Alfred Menezes, "Elliptic Curve Public Key | |||

Cryptosystems", 1993 Kluwer. | Cryptosystems", 1993 Kluwer. | |||

skipping to change at page 13, line 5 | skipping to change at page 13, line 46 | |||

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 | [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an | |||

IANA Considerations Section in RFCs", October 1998. | 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, draft-ietf-dnsext-dnssec-records- *.txt. | ||||

INTERNET-DRAFT ECC Keys in the DNS | INTERNET-DRAFT ECC Keys in the DNS | |||

Authors' Addresses | Authors Addresses | |||

Rich Schroeppel | Rich Schroeppel | |||

500 S. Maple Drive | 500 S. Maple Drive | |||

Woodland Hills, UT 84653 USA | Woodland Hills, UT 84653 USA | |||

Telephone: 1-801-423-7998(h) | Telephone: 1-801-423-7998(h) | |||

1-505-844-9079(w) | 1-505-844-9079(w) | |||

Email: rcs@cs.arizona.edu | Email: rschroe@sandia.gov | |||

rschroe@sandia.gov | ||||

Donald E. Eastlake 3rd | Donald E. Eastlake 3rd | |||

Motorola | Motorola Laboratories | |||

155 Beaver Street | 155 Beaver Street | |||

Milford, MA 01757 USA | Milford, MA 01757 USA | |||

Telephone: +1 508-634-2066 (h) | Telephone: +1 508-634-2066 (h) | |||

+1 508-851-8280 (w) | +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 February 2004. | This draft expires in February 2004. | |||

Its file name is draft-ietf-dnsext-ecc-key-04.txt. | Its file name is draft-ietf-dnsext-ecc-key-05.txt. | |||

End of changes. | ||||

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |