draft-ietf-dnsext-ecc-key-07.txt

bind 源码 最新实现 linux/unix/windows平台

   following steps are taken where Q, P, G, and Y are as specified in
   the public key [Schneier]:

     hash = SHA-1 ( data )

     Generate random [RFC 4086] K such that 0 < K < Q.  (Never sign two
          different messages with the same K.  K should be chosen from a
          very large space: If an opponent learns a K value for a single
          signature, the user's signing key is compromised, and a forger
          can sign arbitrary messages. There is no harm in signing the
          same message multiple times with the same key or different
          keys.)

     R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted


R. Schroeppel, et al                                           [Page 11]


INTERNET-DRAFT                                       ECC Keys in the DNS


          as an integer, and reduced (mod Q).  (R must not be 0.  In
          this astronomically unlikely event, generate a new random K
          and recalculate R.)

     S = ( K^(-1) * (hash + X*R) ) mod Q.

     S must not be 0.  In this astronomically unlikely event, generate a
          new random K and recalculate R and S.

     If S > Q/2, set S = Q - S.

     The pair (R,S) is the signature.

     Another party verifies the signature as follows:

          Check that 0 < R < Q and 0 < S < Q/2.  If not, it can not be a
               valid EC sigature.

          hash = SHA-1 ( data )

          Sinv = S^(-1) mod Q.

          U1 = (hash * Sinv) mod Q.

          U2 = (R * Sinv) mod Q.

          (U1 * G + U2 * Y) is computed on the elliptic curve.

          V = (the W-coordinate of this point) interpreted as an integer
               and reduced (mod Q).

          The signature is valid if V = R.

     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
     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].  It's believed to be computationally infeasible to
     find data that 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 slightly longer signatures, 42 octets
     instead of 40.

     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
     radix-P integer, with the digits being the coefficients in the
     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 thing".  In the (mod P) case, E is simply a residue mod P,
     and is taken as an integer in the range [0,P-1].  In the GF[2^D]


R. Schroeppel, et al                                           [Page 12]


INTERNET-DRAFT                                       ECC Keys in the DNS


     case, E is 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 necessary to do some radix conversion
     arithmetic.



  6. Performance Considerations

     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 generation is faster than RSA or DSA.

     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.



  7. Security Considerations

     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.



  8. IANA Considerations

     The key and signature data structures defined herein correspond to
     the value 4 in the Algorithm number field of the IANA registry

     Assignment of meaning to the remaining ECC data flag bits or to
     values of ECC fields outside the ranges for which meaning in
     defined in this document requires an IETF consensus as defined in
     [RFC 2434].





R. Schroeppel, et al                                           [Page 13]


INTERNET-DRAFT                                       ECC Keys in the DNS


  Copyright and Disclaimer

     Copyright (C) The Internet Society 2005.  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.





































R. Schroeppel, et al                                           [Page 14]


INTERNET-DRAFT                                       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 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)",
     August 1999.

     [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and
     S. Rose, "DNS Security Introduction and Requirements", RFC 4033,
     March 2005.

     [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and
     S. Rose, "Protocol Modifications for the DNS Security Extensions",
     RFC 4035, March 2005.

     [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
     "Randomness Requirements for Security", BCP 106, RFC 4086, June
     2005.

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

     [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic
     Curves", 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 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and
     S. Rose, "Resource Records for the DNS Security Extensions", RFC
     4034, March 2005.







R. Schroeppel, et al                                           [Page 15]


INTERNET-DRAFT                                       ECC Keys in the DNS


  Author's Addresses

     Rich Schroeppel
     500 S. Maple Drive
     Woodland Hills, UT 84653 USA

     Telephone:   [phone](w)
     Email:       [e-mail]


     Donald E. Eastlake 3rd
     Motorola Laboratories
     155 Beaver Street
     Milford, MA 01757 USA

     Telephone:   [phone] (w)
     EMail:       [e-mail]



  Expiration and File Name

     This draft expires in January 2006.

     Its file name is draft-ietf-dnsext-ecc-key-07.txt.



























R. Schroeppel, et al                                           [Page 16]