idnits 2.17.1 draft-schlyter-appkey-02.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (February 6, 2002) is 8114 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) ** Obsolete normative reference: RFC 2246 (ref. '2') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2535 (ref. '3') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2538 (ref. '4') (Obsoleted by RFC 4398) ** Obsolete normative reference: RFC 2845 (ref. '6') (Obsoleted by RFC 8945) == Outdated reference: A later version (-04) exists of draft-josefsson-base-encoding-03 ** Downref: Normative reference to an Informational draft: draft-josefsson-base-encoding (ref. '8') -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-04) exists of draft-ietf-dnsext-restrict-key-for-dnssec-01 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Schlyter 2 Internet-Draft Carlstedt Research & 3 Expires: August 7, 2002 Technology 4 February 6, 2002 6 Storing application public keys in the DNS 7 draft-schlyter-appkey-02.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 7, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This document specifies a new DNS RR type for applications to store 39 public keys in. Experience with DNSSEC has indicated that mixing DNS 40 keys and application keys is a bad idea in many regards. The new RR 41 expands certain fields based on experience from early DNSSEC 42 deployment. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Comments on the KEY RR . . . . . . . . . . . . . . . . . . . . 3 48 2.1 The flag field . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2.2 The protocol field . . . . . . . . . . . . . . . . . . . . . . 3 50 3. The APPKEY resource record . . . . . . . . . . . . . . . . . . 3 51 3.1 The APPKEY RDATA format . . . . . . . . . . . . . . . . . . . 4 52 3.2 Algorithm number specification . . . . . . . . . . . . . . . . 4 53 3.3 Text representation of APPKEY RRs . . . . . . . . . . . . . . 4 54 3.4 Owner names for APPKEY RRs . . . . . . . . . . . . . . . . . . 4 55 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 56 5. Security considerations . . . . . . . . . . . . . . . . . . . 5 57 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5 58 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 60 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 61 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 The Domain Name System Security Extensions (DNSSEC) as described in 66 RFC 2535 [3] specifies the KEY resource record (RR). The KEY RR is 67 specified for use both for storing keys used by the DNSSEC 68 infrastructure itself and for storing keys used by non-DNSSEC 69 infrastructure applications (e.g. TLS [2], email and IPsec). The 70 issues with combining these two uses in one RR are further discussed 71 in a draft called "Limiting the Scope of the KEY Resource Record" 72 [10]. 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119 [1]. 78 2. Comments on the KEY RR 80 2.1 The flag field 82 The KEY RR includes a flag field that specifies key usage, what kind 83 of entity the key is associated with and various other flags. As 84 this kind of information often is application dependent and a common 85 specification that covers all kinds of different flags that an 86 application might need is hard to do, the usability of this field is 87 questionable. 89 2.2 The protocol field 91 The protocol field in the KEY RR is only 8-bit and thus limited to 92 256 different protocols. As there is no way of separating different 93 version of a specific protocol, incompatible versions of a single 94 protocol requires multiple protocol values. A larger protocol field 95 together with the possibility to specify a version of the protocol 96 could solve this issue. 98 A problem with multiple applications storing their public keys at a 99 single owner name and thus creating a very large RR set has been 100 identified. A possible solution for this could be to use a generic 101 protocol value [9] indicating that the actual protocol used is 102 indicated in the owner name using a SRV-like encoding. Although this 103 would indeed solve the problem with large RR sets when querying for 104 an application key, it could also make the protocol field lose its 105 value in practice as new applications would not require a new 106 protocol value. 108 3. The APPKEY resource record 110 The APPKEY resource record (RR) is used to store a application public 111 key that is associated with a Domain Name System (DNS) name. 113 The RR type code for the APPKEY RR is TBA. 115 An APPKEY RR is, like any other RR, authenticated by a SIG RR. 117 3.1 The APPKEY RDATA format 119 The RDATA for an APPKEY RR consists of an algorithm number octet and 120 the public key itself. The format is as follows: 122 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | algorithm | / 126 +---------------+ public key / 127 / / 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 130 The meaning of the APPKEY RR owner name and algorithm number octet 131 are described in the sections below. The format of the public key is 132 algorithm dependent. 134 APPKEY RRs do not specify their validity period but their 135 authenticating SIG RR(s) do as described in RFC 2535 [3]. 137 3.2 Algorithm number specification 139 The algorithm number used is the same as defined for the KEY RR 140 described in RFC 2535 [3]. 142 3.3 Text representation of APPKEY RRs 144 The RDATA portion of an APPKEY RR has the algorithm number octet 145 represented as unsigned integers. 147 The public key fields is represented in base 64 [8] and may be 148 divided up into any number of white space separated substrings, down 149 to single base 64 digits, which are concatenated to obtain the full 150 public key. These substrings can span lines using the standard 151 parenthesis notation. Note that although the public key field may 152 have internal sub-fields, these do not appear in the master file 153 representation. 155 3.4 Owner names for APPKEY RRs 157 The owner name of the APPKEY RR is defined per application and SHOULD 158 be defined in such a way that it is possible to query for a single 159 application APPKEY. This can be, but is not limited to, the domain 160 name of the host the application is running at (e.g. 161 host.example.com) combined with a protocol identifier. A name 162 matching the SRV RR [5] for the service (e.g. 163 _service._protocol.host.example.com) could be a good starting point 164 for this naming. 166 4. Applicability Statement 168 The APPKEY resource record (RR) are only intended for storage of 169 public keys - private keys MUST NOT be stored in an APPKEY RR. 171 The APPKEY RR is not intended for storage of certificates and a 172 separate certificate RR, defined in RFC 2538 [4], has been developed 173 for that purpose. 175 5. Security considerations 177 Public keys from an APPKEY RR, SHOULD NOT be trusted unless the 178 APPKEY was authenticated by a trusted SIG RR. Applications that do 179 not validate the signatures by themselves are advised to use TSIG [6] 180 or SIG(0) [7] to protect the transport between themselves and the 181 name server doing the signature validation. 183 6. IANA considerations 185 IANA needs to allocate a RR type code for APPKEY from the standard RR 186 type space. No other IANA services are required by this document. 188 References 190 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 191 Levels", BCP 14, RFC 2119, March 1997. 193 [2] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 194 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 195 1999. 197 [3] Eastlake, D., "Domain Name System Security Extensions", RFC 198 2535, March 1999. 200 [4] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the 201 Domain Name System (DNS)", RFC 2538, March 1999. 203 [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 204 specifying the location of services (DNS SRV)", RFC 2782, 205 February 2000. 207 [6] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 208 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 209 2845, May 2000. 211 [7] Eastlake, D., "DNS Request and Transaction Signatures ( 212 SIG(0)s)", RFC 2931, September 2000. 214 [8] Josefsson, S., "Base Encodings", work in progress draft- 215 josefsson-base-encoding-03, November 2001. 217 [9] Lewis, E., "DNS KEY Resource Record Generic Protocol Value", 218 work in progress draft-lewis-dnsext-key-genprot-00, July 2001. 220 [10] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 221 Record", work in progress draft-ietf-dnsext-restrict-key-for- 222 dnssec-01, January 2002. 224 Author's Address 226 Jakob Schlyter 227 Carlstedt Research & Technology 228 Stora Badhusgatan 18-20 229 Goteborg SE-411 21 230 Sweden 232 EMail: jakob@crt.se 233 URI: http://www.crt.se/~jakob/ 235 Appendix A. Acknowledgements 237 The author gratefully acknowledges, in no particular order, the 238 contributions of the following persons: 240 Olafur Gudmundsson 242 Olaf Kolkman 244 Edward Lewis 246 Dan Massey 248 Full Copyright Statement 250 Copyright (C) The Internet Society (2002). All Rights Reserved. 252 This document and translations of it may be copied and furnished to 253 others, and derivative works that comment on or otherwise explain it 254 or assist in its implementation may be prepared, copied, published 255 and distributed, in whole or in part, without restriction of any 256 kind, provided that the above copyright notice and this paragraph are 257 included on all such copies and derivative works. However, this 258 document itself may not be modified in any way, such as by removing 259 the copyright notice or references to the Internet Society or other 260 Internet organizations, except as needed for the purpose of 261 developing Internet standards in which case the procedures for 262 copyrights defined in the Internet Standards process must be 263 followed, or as required to translate it into languages other than 264 English. 266 The limited permissions granted above are perpetual and will not be 267 revoked by the Internet Society or its successors or assigns. 269 This document and the information contained herein is provided on an 270 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 271 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 272 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 273 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 274 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 276 Acknowledgement 278 Funding for the RFC Editor function is currently provided by the 279 Internet Society.