idnits 2.17.1 draft-ietf-dnssec-indirect-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-25) 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-indirect-key-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-indirect-key-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-indirect-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-indirect-key-00.txt,', but the file name used is 'draft-ietf-dnssec-indirect-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 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. ** 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 76: '... this technique MUST NOT be used for ...' RFC 2119 keyword, line 89: '... algorithm MAY NOT be used for zone ...' RFC 2119 keyword, line 173: '...m is 0, the hash size MUST be zero and...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Domain Name System (DNS) KEY Resource Record (RR) [RFC 2065] algorithm number 252 is defined as the indirect key algorithm. This algorithm MAY NOT be used for zone keys in support of DNS security. == 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 1998) is 9538 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 section? 'RFC 2065' on line 87 looks like a reference -- Missing reference section? 'RFC 1738' on line 112 looks like a reference -- Missing reference section? 'TDB' on line 190 looks like a reference Summary: 11 errors (**), 1 flaw (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Indirect KEY RRs 2 September 1997 3 Expires March 1998 5 Indirect Keys in the Domain Name System 6 -------- ---- -- --- ------ ---- ------ 8 Donald E. Eastlake 3rd 10 Status of This Document 12 This draft, file name draft-ietf-dnssec-indirect-key-00.txt, is 13 intended to be become a Proposed Standard RFC. Distribution of this 14 document is unlimited. Comments should be sent to the DNSSEC mailing 15 list or to the author. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months. Internet-Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet- 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 30 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 31 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 32 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 34 Abstract 36 RFC 2065 defines a means for storing cryptogrpahic public keys in the 37 Domain Name System. An additional code point is defined for the KEY 38 resource record (RR) algorithm field to indicate that the key itself 39 is not stored in the KEY RR but is pointed to by the KEY RR. 40 Encodings to indicate different types of key and pointer formats are 41 specified. 43 Table of Contents 45 Status of This Document....................................1 46 Abstract...................................................1 48 Table of Contents..........................................2 50 1. Introduction............................................3 52 2. The Indirect KEY RR Algorithm...........................4 53 2.1 The Pointer Type Field.................................4 54 2.2 The Target Type Field..................................4 55 2.3 The Algorithm Field....................................5 56 2.4 The Hash Fields........................................5 58 3. Performance Considerations..............................7 59 4. Security Considerations.................................7 61 References.................................................8 62 Author's Address...........................................8 63 Expiration and File Name...................................8 65 1. Introduction 67 The Domain Name System (DNS) security extensions [RFC 2065] provide 68 for the general storage of public keys in the domain name system via 69 the KEY resource record (RR). These KEY RRs are used in support of 70 DNS security and may be used to support other security protocols. 71 KEY RRs can be associated with users, zones, and hosts or other end 72 entities named in the DNS. 74 For reasons given below, in many cases it will be desireable to store 75 a key elsewhere and merely point to it from the KEY RR. However, 76 this technique MUST NOT be used for KEY RRs used in DNSSEC. 78 Indirect key storage makes it possible to point to a key service via 79 a URL, to have a compact pointer to a larger key structure, to point 80 to a certificate either inside DNS [see draft-ietf-dnssec-certs- 81 00.txt] or outside the DNS, and where appropriate, to store a key 82 applicable to many DNS entries in some place and point to it from 83 those entries. 85 2. The Indirect KEY RR Algorithm 87 Domain Name System (DNS) KEY Resource Record (RR) [RFC 2065] 88 algorithm number 252 is defined as the indirect key algorithm. This 89 algorithm MAY NOT be used for zone keys in support of DNS security. 91 When the algorithm byte of a KEY RR has thae value 252, the "public 92 key" portion of the RR is formated as follows: 94 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 95 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | pointer type | algorithm | target type | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | hash type | hash size | hash / 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ 101 / / 102 / pointer / 103 / | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 106 2.1 The Pointer Type Field 108 The pointer type specifies the interpretation of the pointer field. 109 Pointer types 0 and 255 are reserved. Pointer type 1 indicates that 110 the pointer field is a domain name. Name compression is prohibited. 111 Pointer type 2 indicates that the pointer field is a null terminated 112 character string to be interpreted as a URL [RFC 1738]. The 113 remaining pointer types are available for assignment by IANA. 115 2.2 The Target Type Field 117 Target type specifies the type of the key containing data being 118 pointed at. 120 Target types 0 and 65535 are reserved. 122 Target type 1 indicates that a dnssec key is being pointed at, either 123 one or more KEY RRs if the pointer type was a domain name or the 124 public key portion of a KEY RR if the pointer type was a URL. 126 Target type 2 indicates that a certificate and/or certificate 127 revocation list is being pointed at, either one or more CERT RRs if 128 the pointer type was a domain name or the certificate portion of a 129 CERT RR if the pointer was a URL. 131 Target type 3 indicates that a PKCS#1 format key is being pointed at. 132 This is only applicable to the URL pointer type. 134 The remaining target types are available for assignment by IANA. 136 2.3 The Algorithm Field 138 The algorithm field is as defined in RFC 2065. if non-zero, it 139 specifies the algorithm type of the target key pointed. If zero, it 140 does not specify what algorithm the key applies to. 142 2.4 The Hash Fields 144 If the indirecting KEY RR is retrieved from an appropriately secure 145 DNS zone with a resolver implementing DNS security, then there would 146 be a high level of confidence in the entire value of the KEY RR 147 including any direct key. This may or may not be true of any indirect 148 key pointed to. If that key is embodied in a certificate or 149 retrieved via a secure protocol such as SHTTP, it may also be secure. 150 But an indirecting KEY RR could, for example, simply have an FTP URL 151 pointing to a binary key stored elsewhere, the retrieval of which 152 would not be secure. 154 The hash option in algorithm 252 KEY RRs provides a means of 155 extending the security of the indirecting KEY RR to the actual key 156 material pointed at. By inclduing a hash in a secure indirecting RR, 157 this secure hash can be checked against the hash of the actual keying 158 material 160 Type Hash Algorithm 161 ---- -------------- 162 0 indicates no hash present 163 1 MD5 164 2 SHA-1 165 3 RIPEMD 166 4-254 available for assignment 167 255 reserved 169 The hash size field is an unsigned octet count of the hash size. For 170 some hash algorithms it may be fixed by the algorithm choice but this 171 will not always be the case. For example, hash size is used to 172 distinguish between RIPEMD-128 (16 octets) and RIPEMD-160 (20 173 octets). If the hash algorithm is 0, the hash size MUST be zero and 174 no hash octets are present. 176 The hash field itself is variable size with its length specified by 177 the hash size field. 179 3. Performance Considerations 181 With current public key technology, an indirect key will normally be 182 shorter than the keying material it points at. This may improve DNS 183 permformace in the retrieval of the initial KEY RR. However, an 184 additional retrieval step then needs to be done to get the actualy 185 keying material which must be added to the overall time to get the 186 public key. 188 4. Security Considerations 190 [TDB] 192 References 194 PKCS#1 196 RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", 197 STD 13, November 1987. 199 RFC 1035 - P. Mockapetris, "Domain Names - Implementation and 200 Specifications", STD 13, November 1987. 202 RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform 203 Resource Locators (URL)", December 1994. 205 RFC 2065 - D. Eastlake, C. Kaufman, "Domain Name System Security 206 Extensions", 01/03/1997. 208 draft-ietf-dnssec-certs-00.txt 210 Author's Address 212 Donald E. Eastlake 3rd 213 CyberCash, Inc. 214 318 Acton Street 215 Carlisle, MA 01741 USA 217 Telephone: +1 508 287 4877 218 +1 703 620-4200 (main office, Reston, VA) 219 FAX: +1 508 371 7148 220 EMail: dee@cybercash.com 222 Expiration and File Name 224 This draft expires March 1998. 226 Its file name is draft-ietf-dnssec-indirect-key-00.txt.