idnits 2.17.1 draft-ietf-dnssec-indirect-key-01.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-20) 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-01.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-indirect-key-01.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-indirect-key-01.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-01.txt,', but the file name used is 'draft-ietf-dnssec-indirect-key-01' == 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 82: '...mplementation, this technique MUST NOT...' RFC 2119 keyword, line 89: '... algorithm MAY NOT be used for zone ...' RFC 2119 keyword, line 194: '...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. All KEYs used in DNSSEC validation must be stored directly in the DNS. == 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 (May 1998) is 9472 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 116 looks like a reference -- Missing reference section? 'RFC 1738' on line 145 looks like a reference -- Missing reference section? 'RFC 1321' on line 184 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 November 1997 3 Expires May 1998 5 Indirect KEY RRs 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-01.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 Target Type Field..................................4 54 2.2 The Target Algorithm Field.............................5 55 2.3 The Hash Fields........................................5 57 3. Performance Considerations..............................7 58 4. Security Considerations.................................7 60 References.................................................8 61 Author's Address...........................................8 62 Expiration and File Name...................................8 64 1. Introduction 66 The Domain Name System (DNS) security extensions [RFC 2065] provide 67 for the general storage of public keys in the domain name system via 68 the KEY resource record (RR). These KEY RRs are used in support of 69 DNS security and may be used to support other security protocols. 70 KEY RRs can be associated with users, zones, and hosts or other end 71 entities named in the DNS. 73 For reasons given below, in many cases it will be desireable to store 74 a key or keys elsewhere and merely point to it from the KEY RR. 75 Indirect key storage makes it possible to point to a key service via 76 a URL, to have a compact pointer to a larger key or set of keys, to 77 point to a certificate either inside DNS [see draft-ietf-dnssec- 78 certs-*.txt] or outside the DNS, and where appropriate, to store a 79 key or key set applicable to many DNS entries in some place and point 80 to it from those entries. 82 However, to simplify DNSSEC implementation, this technique MUST NOT 83 be used for KEY RRs used in for verification in DNSSEC. 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. 90 All KEYs used in DNSSEC validation must be stored directly in the 91 DNS. 93 When the algorithm byte of a KEY RR has thae value 252, the "public 94 key" portion of the RR is formated as follows: 96 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 97 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 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | target type | target alg. | hash type | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | hash size | hash (variable size) / 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ 103 | / 104 / pointer (varible size) / 105 / / 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 108 2.1 The Target Type Field 110 Target type specifies the type of the key containing data being 111 pointed at. 113 Target types 0 and 65535 are reserved. 115 Target type 1 indicates that the pointer is a domain name from which 116 KEY RRs [RFC 2065] should be retrieved. Name compression in the 117 pointer field is prohibited. 119 Target type 2 indicates that the pointer is a null terminated 120 character string which is a URL [RFC 1738]. For exisiting data 121 transfer URL schemes, such as ftp, http, shttp, etc., the data is the 122 same as the public key portion of a KEY RR. (New URL schmes may be 123 defined which return multiple keys.) 125 Target type 2 indicates that the pointer is a domain name from which 126 CERT RRs [draft-ietf-dnssec-certs-*.txt] should be retrieved. Name 127 compression in the pointer field is prohibiited. 129 Target type 3 indicates that the pointer is a null terminated 130 character string which is a URL [RFC 1738]. For exisiting data 131 transfer URL schemes, such as ftp, http, shttp, etc., the data is the 132 same as the entire RDATA portion of a CERT RR [draft-ietf-dnssec- 133 certs-*.txt]. (New URL schmes may be defined which return multiple 134 such data blocks.) 136 Target type 4 indicates that the pointer is a null terminated 137 character string which is a URL [RFC 1738]. For exisiting data 138 transfer URL schemes, such as ftp, http, shttp, etc., the data is a 139 PKCS#1 format key. (New URL schmes may be defined which return 140 multiple keys.) 142 The target types 5 through 255 are available for assignment by IANA. 144 Target type 256 through 511 (i.e., 256 + n) indicate that the pointer 145 is a null terminated character string which is a URL [RFC 1738]. For 146 exisiting data transfer URL schemes, such as ftp, http, shttp, etc., 147 the data is a certificate of the type indicated by a CERT RR [draft- 148 ietf-dnssec-certs-*.txt] certificate type of n. That is, target 149 types 257, 258, and 259 are PKIX, SPKI, and PGP certificates and 150 target types 509 and 510 are URL and OID private certificate types. 151 (New URL schmes may be defined which return multiple such 152 certificates.) 154 Target types 512 through 65534 are available for assignment by IANA. 156 2.2 The Target Algorithm Field 158 The algorithm field is as defined in RFC 2065. if non-zero, it 159 specifies the algorithm type of the target key or keys pointed. If 160 zero, it does not specify what algorithm the target key or keys apply 161 to. 163 2.3 The Hash Fields 165 If the indirecting KEY RR is retrieved from an appropriately secure 166 DNS zone with a resolver implementing DNS security, then there would 167 be a high level of confidence in the entire value of the KEY RR 168 including any direct keys. This may or may not be true of any 169 indirect key pointed to. If that key is embodied in a certificate or 170 retrieved via a secure protocol such as SHTTP, it may also be secure. 171 But an indirecting KEY RR could, for example, simply have an FTP URL 172 pointing to a binary key stored elsewhere, the retrieval of which 173 would not be secure. 175 The hash option in algorithm 252 KEY RRs provides a means of 176 extending the security of the indirecting KEY RR to the actual key 177 material pointed at. By inclduing a hash in a secure indirecting RR, 178 this secure hash can be checked against the hash of the actual keying 179 material 181 Type Hash Algorithm 182 ---- -------------- 183 0 indicates no hash present 184 1 MD5 [RFC 1321] 185 2 SHA-1 186 3 RIPEMD 187 4-254 available for assignment 188 255 reserved 190 The hash size field is an unsigned octet count of the hash size. For 191 some hash algorithms it may be fixed by the algorithm choice but this 192 will not always be the case. For example, hash size is used to 193 distinguish between RIPEMD-128 (16 octets) and RIPEMD-160 (20 194 octets). If the hash algorithm is 0, the hash size MUST be zero and 195 no hash octets are present. 197 The hash field itself is variable size with its length specified by 198 the hash size field. 200 3. Performance Considerations 202 With current public key technology, an indirect key will sometimes be 203 shorter than the keying material it points at. This may improve DNS 204 permformace in the retrieval of the initial KEY RR. However, an 205 additional retrieval step then needs to be done to get the actualy 206 keying material which must be added to the overall time to get the 207 public key. 209 4. Security Considerations 211 The indirecting step of using an indirect KEY RR adds complexity and 212 additional steps where security could go wrong. If the indirect key 213 RR was retrieved from a zone that was insecure for the resolver, you 214 have no security. If the indirect key RR, although secure itself, 215 point to a key which can not be securely retrieved and is not 216 validatated by a secure hash in the indirect key RR, you have no 217 security. 219 References 221 PKCS#1 223 RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", 224 STD 13, November 1987. 226 RFC 1035 - P. Mockapetris, "Domain Names - Implementation and 227 Specifications", STD 13, November 1987. 229 RFC 1321 - R. Rivest, "The MD5 Message-Digest Algorithm", April 1992. 231 RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform 232 Resource Locators (URL)", December 1994. 234 RFC 2065 - D. Eastlake, C. Kaufman, "Domain Name System Security 235 Extensions", 01/03/1997. 237 draft-ietf-dnssec-certs-*.txt 239 Author's Address 241 Donald E. Eastlake 3rd 242 CyberCash, Inc. 243 318 Acton Street 244 Carlisle, MA 01741 USA 246 Telephone: +1 978 287 4877 247 +1 703 620-4200 (main office, Reston, VA) 248 FAX: +1 978 371 7148 249 EMail: dee@cybercash.com 251 Expiration and File Name 253 This draft expires May 1998. 255 Its file name is draft-ietf-dnssec-indirect-key-01.txt.