idnits 2.17.1 draft-ietf-dnssec-in-key-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-dnssec-in-key-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-in-key-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-in-key-00.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-dnssec-in-key-00.txt,', but the file name used is 'draft-ietf-dnssec-in-key-00' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 77: '... leaves of the in-key.int. domain MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 1997) is 9902 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SHA1' is mentioned on line 94, but not defined == Unused Reference: 'RFC 2065' is defined on line 181, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) Summary: 14 errors (**), 1 flaw (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 CyberCash, Inc. 3 Expires: September 1997 March 1997 5 The DNS Inverse Key Domain 6 --- --- ------- --- ------ 8 Status of This Document 10 This draft, file name draft-ietf-dnssec-in-key-00.txt, is intended to 11 be become a Proposed Standard RFC. Distribution of this document is 12 unlimited. Comments should be sent to the DNS security mailing list 13 or the author. 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months. Internet-Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet- 23 Drafts as reference material or to cite them other than as a 24 ``working draft'' or ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 28 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 29 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 30 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 32 Abstract 34 Proposed Standard protocol extensions now exist to the Domain Name 35 System (DNS) to authenticate the data in DNS and provide key 36 distribution services (RFC 2065). This draft proposes a special in- 37 key.int domain which would allow entities to be found from their keys 38 if they have voluntarily registered them in that domain. 40 Table of Contents 42 Status of This Document....................................1 44 Abstract...................................................2 45 Table of Contents..........................................2 47 1. The Inverse Key Domain Domain...........................3 49 2. Inverse Key Domain Name Structure.......................4 51 3. Inverse Key Domain Administration.......................5 53 4. Inverse Key Domain Authentication.......................6 55 5. Security Considerations.................................7 56 References.................................................7 57 Author's Address...........................................7 58 Expiration and File Name...................................7 60 1. The Inverse Key Domain Domain 62 A special domain is defined, the in-key.int. domain, to permit 63 inverse lookup by key. DNS servers for zones that include any 64 updatable part of this domain have a special update policy and all 65 servers and resolvers have a special authentication policy for this 66 domain. 68 Normally the only RRs stored in this domain will be a KEY RR and an 69 authenticating SIG with the SIG signer field pointing to the normal 70 owner of the KEY. It is expected that an administrative restriction 71 may be placed on the number of RRs stored under any particular owner 72 name or that charges imposed (see draft-eastlake-internet-payment- 73 *.txt) for additions to this domain by the as yet to be determined 74 operator of the domain or of a zone within the domain. 76 Registration in the in-key.int. domain is voluntary. All servers 77 that include key storage leaves of the in-key.int. domain MUST 78 operate in mode A for those zones (see draft-ietf-dnssec-update- 79 04.txt [approved as a Proposed Standard but not yet issued as an 80 RFC]). 82 (Note: The structure of the IETF recommended top level domain names 83 is currently being examined. If infrastructure domains such as 84 ipv6.int are moved elsewhere, such as to the current infrastructure 85 ".arpa" domain, then the in-key domain should move also, for example 86 to in-key.arpa.) 88 2. Inverse Key Domain Name Structure 90 The owner name associated with a KEY RR in the in-key.int domain is 92 ..algorithm.in-key.int. 94 key-hash is the hex representation of the SHA1 [SHA1] hash of the 95 "public key" portion of the corresponding KEY RR (the portion of 96 the RDATA after the algorithm octet) with label separating dots 97 added every fourth hex digit. 99 key-footprint is the hex representation of the key footprint field of 100 the KEY RR. 102 algorithm is the decimal number designating the public key algorithm 103 from the "algorithm" octet portion of the corresponding key. 104 Thus, at this time, algorithm will be either 1 or 254. Entries 105 for algorithm 253 are prohibited. 107 For example, the RRs in this domain for a purported key with actual 108 owner name example.tld could be as follows: 110 $ORIGIN xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.1.in-key.int. 112 IN KEY 0 1 ( 113 45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoUMxFcby9k/yvedMfQgKzhH5er0Mu/vILz 114 80jEeC8aTrO+KKmCaY1tVfSCSqQYn6//11U6Nld= ;key 115 ) 116 IN SIG KEY 1 3 ( ;type-cov=PTR, alg=1, labels=3 117 19991202030405 ;signature expiration 118 19951211100908 ;time signed 119 2143658709 ;key footprint 120 example.tld. ;signer 121 MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU 122 1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature 123 ) 125 3. Inverse Key Domain Administration 127 The strucutre of the in-key domain names scatters keys within an 128 algorithm by hash codes. Thus, while the domain has structure that 129 can be used to split it inot zones and avoid any zone within it from 130 getting too large, this structure does not correspond in to 131 communities that might wish to use or maintain the zone. 133 If only a small number of key holders wish to register there key 134 here, this will probably not be a problem as a volunteer operator can 135 likely be found and the entire inverse key domain can be run as one 136 zone. If many registrants within this domain appear, some form of 137 charging may be necessary and it may be necessary to split the domain 138 into zones by algorithm and then key footprint. If huge numbers 139 register, it may even be necessry to split it further based on the 140 highest SHA1 key hash derived label. 142 DNS dynamic update (draft-ietf-dnsind-dynUPD-*.txt) gas been adopted 143 as a Proposed Standard. Assuming the adoption of DNS charging 144 (draft-eastlake-internet-payment-*.txt), the best way to populate the 145 domain may be via dynamic updates for which a fee is charged by the 146 maintainer(s) of the domain. 148 4. Inverse Key Domain Authentication 150 Retrievals and updates to this domain use special authentication 151 policies as indicated below. 153 Retrievals from leaves of this domain are authenticated by validating 154 the SIG against the KEY with the same owner name and checking that 155 this owner name correctly reflects the hash and key footprint of the 156 key. Thus, for this type of validation only, the signer name is 157 ignored and the SIG is NOT traced back to a known trusted key. In 158 addition, entries in this domain are "eternal" in that the SIG time 159 signed and signature expiration are ignored. Note that entries in 160 this special domain, even when authenticated, give only a hint that 161 the KEY stored there is or was valid for the signer name. A separate 162 retrieval from the signer name must be done for confirmation that 163 they key is currently valid. 165 Servers authenticate updates for this domain based on the requester's 166 knowledge of the private key corresponding to a public key whose hash 167 is encoded into the RR owner name as indicated by the update request 168 SIG. No dynamic update key previously stored in the zone need be 169 used. 171 5. Security Considerations 173 Storage of many keys in the in-key.int domain may lead to the 174 discovery of duplicate keys due to bad random number generation or 175 other causes. Someone seeking to enter a key and finding the same 176 key their with a different signer could possibly exploit this to 177 impersonate the other holder of the same key. 179 References 181 [RFC 2065] - Domain Name System Security Extensions, D. Eastlake, C. 182 Kaufman, January 1997. 184 draft-ietf-dnssec-update-04.txt [approved as a Proposed Standard but 185 not yet issued as an RFC]. 187 draft-eastlake-internet-payment-*.txt 189 Author's Address 191 Donald E. Eastlake, 3rd 192 CyberCash, Inc. 193 318 Acton Street 194 Carlisle, MA 01741 USA 196 Telephone: +1 508-287-4877 197 +1 508-371-7148 (fax) 198 +1 703-620-4200 (main office, Reston, Virginia, USA) 199 email: dee@cybercash.com 201 Expiration and File Name 203 This draft expires September 1997. 205 Its file name is draft-ietf-dnssec-in-key-00.txt.