[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

INTERNET-DRAFT                                    Donald E. Eastlake 3rd
                                                         CyberCash, Inc.
Expires: September 1997                                       March 1997



                       The DNS Inverse Key Domain
                       --- --- ------- --- ------





Status of This Document

   This draft, file name draft-ietf-dnssec-in-key-00.txt, is intended to
   be become a Proposed Standard RFC. Distribution of this document is
   unlimited. Comments should be sent to the DNS security mailing list
   <dns-security@tis.com> or the author.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (East USA), ftp.isi.edu (West USA),
   nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
   munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).



















Donald E. Eastlake 3rd                                          [Page 1]


INTERNET-DRAFT           The in-key.int Domain                March 1997


Abstract

   Proposed Standard protocol extensions now exist to the Domain Name
   System (DNS) to authenticate the data in DNS and provide key
   distribution services (RFC 2065).  This draft proposes a special in-
   key.int domain which would allow entities to be found from their keys
   if they have voluntarily registered them in that domain.



Table of Contents

      Status of This Document....................................1

      Abstract...................................................2
      Table of Contents..........................................2

      1. The Inverse Key Domain Domain...........................3

      2. Inverse Key Domain Name Structure.......................4

      3. Inverse Key Domain Administration.......................5

      4. Inverse Key Domain Authentication.......................6

      5. Security Considerations.................................7
      References.................................................7
      Author's Address...........................................7
      Expiration and File Name...................................7























Donald E. Eastlake 3rd                                          [Page 2]


INTERNET-DRAFT           The in-key.int Domain                March 1997


1. The Inverse Key Domain Domain

   A special domain is defined, the in-key.int. domain, to permit
   inverse lookup by key.  DNS servers for zones that include any
   updatable part of this domain have a special update policy and all
   servers and resolvers have a special authentication policy for this
   domain.

   Normally the only RRs stored in this domain will be a KEY RR and an
   authenticating SIG with the SIG signer field pointing to the normal
   owner of the KEY. It is expected that an administrative restriction
   may be placed on the number of RRs stored under any particular owner
   name or that charges imposed (see draft-eastlake-internet-payment-
   *.txt) for additions to this domain by the as yet to be determined
   operator of the domain or of a zone within the domain.

   Registration in the in-key.int. domain is voluntary.  All servers
   that include key storage leaves of the in-key.int. domain MUST
   operate in mode A for those zones (see draft-ietf-dnssec-update-
   04.txt [approved as a Proposed Standard but not yet issued as an
   RFC]).

   (Note:  The structure of the IETF recommended top level domain names
   is currently being examined.  If infrastructure domains such as
   ipv6.int are moved elsewhere, such as to the current infrastructure
   ".arpa" domain, then the in-key domain should move also, for example
   to in-key.arpa.)

























Donald E. Eastlake 3rd                                          [Page 3]


INTERNET-DRAFT           The in-key.int Domain                March 1997


2. Inverse Key Domain Name Structure

   The owner name associated with a KEY RR in the in-key.int domain is

        <key-hash>.<key-footprint>.algorithm.in-key.int.

   key-hash is the hex representation of the SHA1 [SHA1] hash of the
        "public key" portion of the corresponding KEY RR (the portion of
        the RDATA after the algorithm octet) with label separating dots
        added every fourth hex digit.

   key-footprint is the hex representation of the key footprint field of
        the KEY RR.

   algorithm is the decimal number designating the public key algorithm
        from the "algorithm" octet portion of the corresponding key.
        Thus, at this time, algorithm will be either 1 or 254.  Entries
        for algorithm 253 are prohibited.

   For example, the RRs in this domain for a purported key with actual
   owner name example.tld could be as follows:

    $ORIGIN xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.1.in-key.int.

     IN KEY <flags> 0 1 (
    45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoUMxFcby9k/yvedMfQgKzhH5er0Mu/vILz
    80jEeC8aTrO+KKmCaY1tVfSCSqQYn6//11U6Nld= ;key
                     )
     IN SIG KEY 1 3 ( ;type-cov=PTR, alg=1, labels=3
                     19991202030405 ;signature expiration
                     19951211100908 ;time signed
                     2143658709     ;key footprint
                     example.tld.       ;signer
     MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU
     1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature
                     )
















Donald E. Eastlake 3rd                                          [Page 4]


INTERNET-DRAFT           The in-key.int Domain                March 1997


3. Inverse Key Domain Administration

   The strucutre of the in-key domain names scatters keys within an
   algorithm by hash codes.  Thus, while the domain has structure that
   can be used to split it inot zones and avoid any zone within it from
   getting too large, this structure does not correspond in to
   communities that might wish to use or maintain the zone.

   If only a small number of key holders wish to register there key
   here, this will probably not be a problem as a volunteer operator can
   likely be found and the entire inverse key domain can be run as one
   zone.  If many registrants within this domain appear, some form of
   charging may be necessary and it may be necessary to split the domain
   into zones by algorithm and then key footprint.  If huge numbers
   register, it may even be necessry to split it further based on the
   highest SHA1 key hash derived label.

   DNS dynamic update (draft-ietf-dnsind-dynUPD-*.txt) gas been adopted
   as a Proposed Standard.  Assuming the adoption of DNS charging
   (draft-eastlake-internet-payment-*.txt), the best way to populate the
   domain may be via dynamic updates for which a fee is charged by the
   maintainer(s) of the domain.






























Donald E. Eastlake 3rd                                          [Page 5]


INTERNET-DRAFT           The in-key.int Domain                March 1997


4. Inverse Key Domain Authentication

   Retrievals and updates to this domain use special authentication
   policies as indicated below.

   Retrievals from leaves of this domain are authenticated by validating
   the SIG against the KEY with the same owner name and checking that
   this owner name correctly reflects the hash and key footprint of the
   key.  Thus, for this type of validation only, the signer name is
   ignored and the SIG is NOT traced back to a known trusted key.  In
   addition, entries in this domain are "eternal" in that the SIG time
   signed and signature expiration are ignored.  Note that entries in
   this special domain, even when authenticated, give only a hint that
   the KEY stored there is or was valid for the signer name.  A separate
   retrieval from the signer name must be done for confirmation that
   they key is currently valid.

   Servers authenticate updates for this domain based on the requester's
   knowledge of the private key corresponding to a public key whose hash
   is encoded into the RR owner name as indicated by the update request
   SIG.  No dynamic update key previously stored in the zone need be
   used.






























Donald E. Eastlake 3rd                                          [Page 6]


INTERNET-DRAFT           The in-key.int Domain                March 1997


5. Security Considerations

   Storage of many keys in the in-key.int domain may lead to the
   discovery of duplicate keys due to bad random number generation or
   other causes.  Someone seeking to enter a key and finding the same
   key their with a different signer could possibly exploit this to
   impersonate the other holder of the same key.



References

   [RFC 2065] - Domain Name System Security Extensions, D. Eastlake, C.
   Kaufman, January 1997.

   draft-ietf-dnssec-update-04.txt [approved as a Proposed Standard but
   not yet issued as an RFC].

   draft-eastlake-internet-payment-*.txt



Author's Address

   Donald E. Eastlake, 3rd
   CyberCash, Inc.
   318 Acton Street
   Carlisle, MA 01741 USA

   Telephone:   +1 508-287-4877
                +1 508-371-7148 (fax)
                +1 703-620-4200 (main office, Reston, Virginia, USA)
   email:       dee@cybercash.com



Expiration and File Name

   This draft expires September 1997.

   Its file name is draft-ietf-dnssec-in-key-00.txt.











Donald E. Eastlake 3rd                                          [Page 7]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/