draft-ietf-dnsext-dnssec-records-03.txt

bind-3.2.

Arends, et al.           Expires August 26, 2003               [Page 25]

Internet-Draft           DNSSEC Resource Records           February 2003


Normative References

   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
         13, RFC 1034, November 1987.

   [2]   Mockapetris, P., "Domain names - implementation and
         specification", STD 13, RFC 1035, November 1987.

   [3]   Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
         Extensions) Part One: Mechanisms for Specifying and Describing
         the Format of Internet Message Bodies", RFC 1521, September
         1993.

   [4]   Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
         August 1996.

   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

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

   [7]   Eastlake, D., "DNS Request and Transaction Signatures (
         SIG(0)s)", RFC 2931, September 2000.

   [8]   Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
         System (DNS)", RFC 3110, May 2001.

   [9]   Gudmundsson, O., "Delegation Signer Resource Record", draft-
         ietf-dnsext-delegation-signer-12 (work in progress), December
         2002.

   [10]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
         "DNS Security Introduction and Requirements", draft-ietf-
         dnsext-dnssec-intro-05 (work in progress), February 2003.

   [11]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
         "Protocol Modifications for the DNS Security Extensions",
         draft-ietf-dnsext-dnssec-protocol-00 (work in progress),
         Februari 2003.

   [12]  Gustafsson, A., "Handling of Unknown DNS RR Types", draft-ietf-
         dnsext-unknown-rrs-04 (work in progress), September 2002.

   [13]  Kosters, M., Blacka, D. and R. Arends, "DNSSEC Opt-in", draft-
         ietf-dnsext-dnssec-opt-in-04 (work in progress), February 2003.





Arends, et al.           Expires August 26, 2003               [Page 26]

Internet-Draft           DNSSEC Resource Records           February 2003


Informative References

   [14]  Eastlake, D., "Domain Name System Security Extensions", RFC
         2535, March 1999.

   [15]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
         2930, September 2000.

   [16]  Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
         Record (RR)", RFC 3445, December 2002.


Authors' Addresses

   Roy Arends
   Telematica Instituut
   Drienerlolaan 5
   7522 NB  Enschede
   NL

   EMail: [e-mail]


   Rob Austein
   Internet Software Consortium
   40 Gavin Circle
   Reading, MA  01867
   USA

   EMail: [e-mail]


   Matt Larson
   VeriSign, Inc.
   21345 Ridgetop Circle
   Dulles, VA  20166-6503
   USA

   EMail: [e-mail]


   Dan Massey
   USC Information Sciences Institute
   3811 N. Fairfax Drive
   Arlington, VA  22203
   USA

   EMail: [e-mail]



Arends, et al.           Expires August 26, 2003               [Page 27]

Internet-Draft           DNSSEC Resource Records           February 2003


   Scott Rose
   National Institute for Standards and Technology
   100 Bureau Drive
   Gaithersburg, MD  20899-8920
   USA

   EMail: [e-mail]












































Arends, et al.           Expires August 26, 2003               [Page 28]

Internet-Draft           DNSSEC Resource Records           February 2003


Appendix A. DNSSEC Algorithm and Digest Types

   The DNS security extensions are designed to be independent of the
   underlying cryptographic algorithms.  The KEY, SIG, and DS resource
   records all use a DNSSEC Algorithm Number to identify the
   cryptographic algorithm in use by the resource record.   The DS
   resource record also specifies a Digest Algorithm Number to identify
   the digest algorithm used to construct the DS record.  The currently
   defined Algorithm and Digest Types are listed below.  Additional
   Algorithm or Digest Types could be added as advances in cryptography
   warrant.

   A DNSSEC aware resolver or name server MUST implement all MANDATORY
   algorithms.

A.1 DNSSEC Algorithm Types

   An "Algorithm Number" field in the KEY, SIG, and DS resource record
   types identifies the cryptographic algorithm used by the resource
   record.   Algorithm specific formats are described in separate
   documents.  The following table lists the currently defined algorithm
   types and provides references to their supporting documents:

   VALUE   Algorithm                  RFC          STATUS
   0      Reserved                    -            -
   1      RSA/MD5                     RFC 2537     NOT RECOMMENDED
   2      Diffie-Hellman              RFC 2539     OPTIONAL
   3      DSA                         RFC 2536     OPTIONAL
   4      elliptic curve              TBA          OPTIONAL
   5      RSA/SHA1                    RFC 3110     MANDATORY
   6-251  available for assignment    -
   252    reserved                    -
   253    private                     see below    OPTIONAL
   254    private                     see below    OPTIONAL
   255    reserved                    -            -


A.1.1 Private Algorithm Types

   Algorithm number 253 is reserved for private use and will never be
   assigned to a specific algorithm.  The public key area in the KEY RR
   and the signature area in the SIG RR begin with a wire encoded domain
   name.  Only local domain name compression is permitted.  The domain
   name indicates the private algorithm to use and the remainder of the
   public key area is determined by that algorithm.  Entities should
   only use domain names they control to designate their private
   algorithms.




Arends, et al.           Expires August 26, 2003               [Page 29]

Internet-Draft           DNSSEC Resource Records           February 2003


   Algorithm number 254 is reserved for private use and will never be
   assigned to a specific algorithm.  The public key area in the KEY RR
   and the signature area in the SIG RR begin with an unsigned length
   byte followed by a BER encoded Object Identifier (ISO OID) of that
   length.  The OID indicates the private algorithm in use and the
   remainder of the area is whatever is required by that algorithm.
   Entities should only use OIDs they control to designate their private
   algorithms.

A.2 DNSSEC Digest Types

   A "Digest Type" field in the DS resource record types identifies the
   cryptographic digest algorithm used by the resource record.   The
   following table lists the currently defined digest algorithm types.

              VALUE   Algorithm                 STATUS
                0      Reserved                   -
                1      SHA-1                   MANDATORY
              2-255    Unassigned                 -
































Arends, et al.           Expires August 26, 2003               [Page 30]

Internet-Draft           DNSSEC Resource Records           February 2003


Appendix B. Key Tag Calculation

   The Key Tag field in the SIG and DS resource record types provides a
   mechanism for selecting a public key efficiently.  In most cases, a
   combination of owner name, algorithm, and key tag can efficiently
   identify a KEY record.  Both the SIG and DS resource records have
   corresponding KEY records.  The Key Tag field in the SIG and DS
   records can be used to help select the corresponding KEY RR
   efficiently when more than one candidate KEY RR is available.

   However, it is essential to note that the key tag is not a unique
   identifier.  It is theoretically possible for two distinct KEY RRs to
   have the same owner name, the same algorithm, and the same key tag.
   The key tag is used to limit the possible candidate keys, but it does
   not uniquely identify a KEY record.  Implementations MUST NOT assume
   that the key tag uniquely identifies a KEY RR.

   The key tag is the same for all KEY algorithm types except algorithm
   1 (please see Appendix B.1 for the definition of the key tag for
   algorithm 1).  For all algorithms other than algorithm 1, the key tag
   is defined to be the output which would be generated by running the
   ANSI C function shown below with the RDATA portion of the KEY RR as
   input.  It is not necessary to use the following reference code
   verbatim, but the numerical value of the Key Tag MUST be identical to
   what the reference implementation would generate for the same input.

   Please note that the algorithm for calculating the Key Tag is almost
   but not completely identical to the familiar ones complement checksum
   used in many other Internet protocols.  Key Tags MUST be calculated
   using the algorithm described below rather than the ones complement
   checksum.

   The following ANSI C reference implementation calculates the value of
   a Key Tag.  This reference implementation applies to all algorithm
   types except algorithm 1 (see Appendix B.1).  The input is the wire
   format of the RDATA portion of the KEY RR.  The code is written for
   clarity, not efficiency.














Arends, et al.           Expires August 26, 2003               [Page 31]

Internet-Draft           DNSSEC Resource Records           February 2003


   /*
    * Assumes that int is at least 16 bits.
    * First octet of the key tag is the most significant 8 bits of the
    * return value;
    * Second octet of the key tag is the least significant 8 bits of the
    * return value.
    */

   unsigned int
   keytag (
           unsigned char key[],  /* the RDATA part of the KEY RR */
           unsigned int keysize  /* the RDLENGTH */
          )
   {
           unsigned long ac;     /* assumed to be 32 bits or larger */
           int i;                /* loop index */

           for ( ac = 0, i = 0; i < keysize; ++i )
                   ac += (i & 1) ? key[i] : key[i] << 8;
           ac += (ac >> 16) & 0xFFFF;
           return ac & 0xFFFF;
   }


B.1 Key Tag for Algorithm 1 (RSA/MD5)

   The key tag for algorithm 1 (RSA/MD5) is defined differently than the
   key tag for all other algorithms, for historical reasons.  For a KEY
   RR with algorithm 1, the key tag is defined to be the most
   significant 16 bits of the least significant 24 bits in the public
   key modulus (in other words, the 4th to last and 3rd to last octets
   of the public key modulus).

   Please note that Algorithm 1 is NOT RECOMMENDED.

















Arends, et al.           Expires August 26, 2003               [Page 32]

Internet-Draft           DNSSEC Resource Records           February 2003


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Arends, et al.           Expires August 26, 2003               [Page 33]