idnits 2.17.00 (12 Aug 2021) /tmp/idnits47721/draft-ietf-dnsind-indirect-key-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2535]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 92: '...mplementation, this technique MUST NOT...' RFC 2119 keyword, line 94: '...d of an indirect KEY RR MUST NOT be 3....' RFC 2119 keyword, line 104: '... algorithm MAY NOT be used for zone ...' RFC 2119 keyword, line 105: '...NSSEC validation MUST be stored direct...' RFC 2119 keyword, line 222: '...0, the hash size MUST be zero and no h...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 186 has weird spacing: '...Y RRset inclu...' -- 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 2535] 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1999) is 8247 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 2535' on line 176 looks like a reference -- Missing reference section? 'RFC 2538' on line 165 looks like a reference -- Missing reference section? 'RFC 2119' on line 99 looks like a reference -- Missing reference section? 'RFC 1738' on line 162 looks like a reference -- Missing reference section? 'RFC 2181' on line 183 looks like a reference -- Missing reference section? '2535' on line 183 looks like a reference -- Missing reference section? 'RFC 1321' on line 202 looks like a reference -- Missing reference section? 'RFC 2434' on line 241 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSIND Working Group D. Eastlake 2 INTERNET-DRAFT IBM 3 Expires October 1999 4 April 1999 5 draft-ietf-dnsind-indirect-key-00.txt 7 Indirect KEY RRs in the Domain Name System (DNS) 8 -------- --- --- -- --- ------ ---- ------ ----- 10 Donald E. Eastlake 3rd 12 Status of This Document 14 This draft, file name draft-ietf-dnsind-indirect-key-00.txt, is 15 intended to be become a Proposed Standard RFC. Distribution of this 16 document is unlimited. Comments should be sent to the DNSSEC mailing 17 list or to the author. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months. Internet-Drafts may be updated, replaced, or obsoleted by 27 other documents at any time. It is not appropriate to use Internet- 28 Drafts as reference material or to cite them other than as a 29 ``working draft'' or ``work in progress.'' 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 To view the entire list of current Internet-Drafts, please check the 38 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 39 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 40 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 41 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 43 Abstract 45 [RFC 2535] defines a means for storing cryptographic public keys in 46 the Domain Name System. An additional code point is defined for the 47 algorithm field of the KEY resource record (RR) to indicate that the 48 key is not stored in the KEY RR but is pointed to by the KEY RR. 49 Encodings to indicate different types of key and pointer formats are 50 specified. 52 [This draft is moved from the DNSSEC WG as part of that WG's merger 53 into me DNSIND WG. It would have been draft-ietf-dnssec-indirect- 54 key-02.txt in the DNSSEC WG.] 56 Table of Contents 58 Status of This Document....................................1 59 Abstract...................................................1 61 Table of Contents..........................................2 63 1. Introduction............................................3 64 2. The Indirect KEY RR Algorithm...........................3 65 2.1 The Target Type Field..................................4 66 2.2 The Target Algorithm Field.............................5 67 2.3 The Hash Fields........................................5 68 3. Performance Considerations..............................6 69 4. IANA Considerations.....................................6 70 5. Security Considerations.................................6 71 References.................................................7 72 Author's Address...........................................7 73 Expiration and File Name...................................8 75 1. Introduction 77 The Domain Name System (DNS) security extensions [RFC 2535] provide 78 for the general storage of public keys in the domain name system via 79 the KEY resource record (RR). These KEY RRs are used in support of 80 DNS security and may be used to support other security protocols. 81 KEY RRs can be associated with users, zones, and hosts or other end 82 entities named in the DNS. 84 For reasons given below, it will sometimes be desireable to store a 85 key or keys elsewhere and merely point to it from the KEY RR. 86 Indirect key storage makes it possible to point to a key service via 87 a URL, to have a compact pointer to a larger key or set of keys, to 88 point to a certificate either inside DNS [RFC 2538] or outside the 89 DNS, and where appropriate, to store a key or key set applicable to 90 many DNS entries in some place and point to it from those entries. 92 However, to simplify DNSSEC implementation, this technique MUST NOT 93 be used for KEY RRs used in for verification in DNSSEC, i.e., the 94 value of the "protocol" field of an indirect KEY RR MUST NOT be 3. 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", 97 "RECOMMENDED", and "MAY" in this document are to be interpreted as 98 described in [RFC 2119]. 100 2. The Indirect KEY RR Algorithm 102 Domain Name System (DNS) KEY Resource Record (RR) [RFC 2535] 103 algorithm number 252 is defined as the indirect key algorithm. This 104 algorithm MAY NOT be used for zone keys in support of DNS security. 105 All KEYs used in DNSSEC validation MUST be stored directly in the 106 DNS. 108 When the algorithm byte of a KEY RR has the value 252, the "public 109 key" portion of the RR is formated as follows: 111 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 112 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 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | target type | target alg. | hash type | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | hash size | hash (variable size) / 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ 118 | / 119 / pointer (variable size) / 120 / / 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 123 2.1 The Target Type Field 125 Target type specifies the type of the key containing data being 126 pointed at. 128 Target type 129 ----------- 131 0 - reserved, see section 4 133 1 - indicates that the pointer is a domain name from which KEY RRs 134 [RFC 2535] should be retrieved. Name compression in the pointer 135 field is prohibited. 137 2 - indicates that the pointer is a null terminated character string 138 which is a URL [RFC 1738]. For exisiting data transfer URL 139 schemes, such as ftp, http, shttp, etc., the data is the same as 140 the public key portion of a KEY RR. (New URL schemes may be 141 defined which return multiple keys.) 143 3 - indicates that the pointer is a domain name from which CERT RRs 144 [RFC 2538] should be retrieved. Name compression in the pointer 145 field is prohibited. 147 4 - indicates that the pointer is a null terminated character string 148 which is a URL [RFC 1738]. For exisiting data transfer URL 149 schemes, such as ftp, http, shttp, etc., the data is the same as 150 the entire RDATA portion of a CERT RR [RFC 2538]. (New URL 151 schemes may be defined which return multiple such data blocks.) 153 5 - indicates that the pointer is a null terminated character string 154 which is a URL [RFC 1738]. For exisiting data transfer URL 155 schemes, such as ftp, http, shttp, etc., the data is a PKCS#1 [RFC 156 2437] format key. (New URL schemes may be defined which return 157 multiple keys.) 159 6 through 255 - available for assignment, see section 4. 161 256 through 511 (i.e., 256 + n) - indicate that the pointer is a null 162 terminated character string which is a URL [RFC 1738]. For 163 exisiting data transfer URL schemes, such as ftp, http, shttp, 164 etc., the data is a certificate of the type indicated by a CERT RR 165 [RFC 2538] certificate type of n. That is, target types 257, 258, 166 and 259 are PKIX, SPKI, and PGP certificates and target types 509 167 and 510 are URL and OID private certificate types. (New URL 168 schemes may be defined which return multiple such certificates.) 170 512 through 65534 - available for assignment, see section 4. 172 65535 reserved, see section 4. 174 2.2 The Target Algorithm Field 176 The algorithm field is as defined in [RFC 2535]. If non-zero, it 177 specifies the algorithm type of the target key or keys pointed. If 178 zero, it does not specify what algorithm the target key or keys apply 179 to. 181 2.3 The Hash Fields 183 If the indirecting KEY RRset [RFC 2181, 2535] is retrieved from an 184 appropriately secure DNS zone with a resolver implementing DNS 185 security, then there would be a high level of confidence in the 186 entire value of the KEY RRset including any direct keys. This may or 187 may not be true of any indirect key pointed to. If an indirect key 188 is embodied in a certificate or retrieved via a secure protocol such 189 as SHTTP, it may also be secure. But an indirecting KEY RR could, 190 for example, simply have an FTP URL pointing to a binary key stored 191 elsewhere, the retrieval of which would not be secure. 193 The hash option in algorithm 252 KEY RRs provides a means of 194 extending the security of the indirecting KEY RR to the actual key 195 material pointed at. By including a hash in a secure indirecting RR, 196 this secure hash can be checked against the hash of the actual keying 197 material 199 Type Hash Algorithm 200 ---- -------------- 201 0 indicates no hash present 202 1 MD5 [RFC 1321] 203 2 SHA-1 204 3 RIPEMD 205 4-252 available, see section 4 206 253 private, domain name (see below) 207 254 private, OID (see below) 208 255 reserved 210 Codes 253 and 254 indicate that a private, proprietary, local, or 211 experimental hash algorithm is used. For code 253, the hash field 212 begins with a wire encoded domain name (with compression prohibited) 213 that indicates the algorithm to use. For code 254, the hash field 214 begins with a one byte unsigned OID length followed by a BER encoded 215 OID which indicates the algorithm to use. 217 The hash size field is an unsigned octet count of the hash field size 218 less the length of any code 253 or 254 prefix. For some hash 219 algorithms it may be fixed by the algorithm choice but this will not 220 always be the case. For example, hash size is used to distinguish 221 between RIPEMD-128 (16 octets) and RIPEMD-160 (20 octets). If the 222 hash algorithm field is 0, the hash size MUST be zero and no hash 223 octets are present. 225 The hash field itself is variable size with its length specified by 226 the hash size field and any code 253 or 254 prefix. 228 3. Performance Considerations 230 With current public key technology, an indirect key will sometimes be 231 shorter than the keying material it points at. In addition, there 232 can be cases where a single indirect KEY RR points to multiple keys 233 elsewhere. This may improve DNS performance in the retrieval of the 234 initial KEY RR. However, an additional retrieval step then needs to 235 be done to get the actually keying material which must be added to 236 the overall time to get the public key. 238 4. IANA Considerations 240 IETF consensus, standards action, and similar terms in this section 241 are as define in [RFC 2434]. 243 KEY RR algorithm number 252 was already reserved for indirect keys in 244 RFC 2535. 246 An IETF standards action is required to allocate target type codes 247 hex x0000, x0006 through x00FF, x0200 through x0FFF, and xFFFF. 248 Codes in the range x1000 through x7FFF can be allocated by an IETF 249 consensus. Codes x8000 through xFEFF are available on a first come 250 first serve basis. Codes xFF00 through xFFFE are available for 251 experimentation or private local use without allocation. Use of 252 codes in this block may result in conflicts outside such experiment 253 or locality. 255 An IETF consensus is required to allocate an indirect KEY RR hash 256 algorithm code in the range 4-252 and a standards action is required 257 to allocate hash algorithm code 255. Codes 253 and 254 should cover 258 requirements for local, private, or proprietary algorithms. 260 5. Security Considerations 262 The indirecting step of using an indirect KEY RR adds complexity and 263 additional steps where security could go wrong. If the indirect key 264 RR was retrieved from a zone that was insecure for the resolver, you 265 have no security. If the indirect key RR, although secure itself, 266 point to a key which can not be securely retrieved and is not 267 validateted by a secure hash in the indirect key RR, you have no 268 security. 270 References 272 RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", 273 STD 13, November 1987. 275 RFC 1035 - P. Mockapetris, "Domain Names - Implementation and 276 Specifications", STD 13, November 1987. 278 RFC 1321 - R. Rivest, "The MD5 Message-Digest Algorithm", April 1992. 280 RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform 281 Resource Locators (URL)", December 1994. 283 RFC 2119 - "Key words for use in RFCs to Indicate Requirement 284 Levels", S. Bradner. March 1997. 286 RFC 2181 - R. Elz, R. Bush, "Clarifications to the DNS 287 Specification", July 1997. 289 RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 290 Considerations Section in RFCs", October 1998. 292 RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography 293 Specifications Version 2.0", October 1998. 295 RFC 2535 - D. Eastlake, "Domain Name System Security Extensions", 296 March 1999. 298 RFC 2538 - D. Eastlake, O. Gudmundsson, "Storing Certificates in the 299 Domain Name System (DNS)", March 1999. 301 Author's Address 303 Donald E. Eastlake 3rd 304 IBM 305 65 shindegan Hill Road, RR #1 306 Carmel, NY 10512 USA 308 Telephone: +1-914-784-7913 (w) 309 +1-914-276-2668 (h) 310 FAX: +1-914-784-3833 (w) 311 EMail: dee3@us.ibm.com 313 Expiration and File Name 315 This draft expires October 1999. 317 Its file name is draft-ietf-dnsind-indirect-key-00.txt.