idnits 2.17.1 draft-schlyter-mailcert-dns-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: ---------------------------------------------------------------------------- == 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 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 abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The abstract seems to indicate that this document updates RFC2538, but the header doesn't have an 'Updates:' line to match this. 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 (November 10, 2001) is 8195 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) == Unused Reference: '1' is defined on line 183, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 192, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (ref. '1') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2440 (ref. '3') (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 2535 (ref. '4') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2538 (ref. '5') (Obsoleted by RFC 4398) ** Obsolete normative reference: RFC 2822 (ref. '6') (Obsoleted by RFC 5322) == Outdated reference: A later version (-09) exists of draft-ietf-dnsext-dnssec-opt-in-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-dnsext-dnssec-opt-in (ref. '7') -- Possible downref: Normative reference to a draft: ref. '8' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 4 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: May 11, 2002 Technology 4 S. Josefsson 5 RSA Security 6 R. Arends 7 Nominum 8 November 10, 2001 10 Storing certificates in DNS for email applications 11 draft-schlyter-mailcert-dns-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 11, 2002. 36 Copyright Notice 38 Copyright (C) The Internet Society (2001). All Rights Reserved. 40 Abstract 42 The Domain Name System (DNS) can be used to store certificates used 43 to identify mail addresses. This document describes on how to name 44 these certificates when stored in DNS. This document updates RFC 45 2538. 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [2]. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Problems with the current representation . . . . . . . . . . . 3 55 2.1 Name collisions . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2 No automatic locating of PKI material of entities . . . . . . 3 57 2.3 Administrative boundaries . . . . . . . . . . . . . . . . . . 4 58 3. Proposed representation . . . . . . . . . . . . . . . . . . . 4 59 3.1 Algorithm to convert RFC 2822 address to domain name . . . . . 4 60 3.2 Case handling . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 65 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 66 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 RFC 2538 [5] section 3.1 describes how to translate X.509 subject and 71 issuer names and into a domain name. The translation used is a 72 fairly complicated set of recommendations to use in priority order 73 depending on what is available in the X.509 certificate. 75 RFC 2538 section 3.2 describes how to translate a general character 76 string PGP User ID, as defined in RFC 2440 [3], that includes a RFC 77 2822 [6] email address into a domain name. The translation used is 78 the standard translation of an email address into a domain name. 80 Using the translations described in RFC 2538 has several 81 disadvantages. We explore these disadvantages in section 2 and 82 propose a new representation in section 3. 84 2. Problems with the current representation 86 2.1 Name collisions 88 When the standard translation, as specified in RFC 2538 [5] 3.2 is 89 used, translated mailbox names, as specified in RFC 2822 [6], may 90 collide with hostnames and/or other mailboxes. 92 For example translated to label 93 "leslie.example.example.com" collides with the translated mailbox 94 as this would translate to the equal 95 label. Another example is that would 96 collide with the host called "hostmaster.example.com". 98 2.2 No automatic locating of PKI material of entities 100 The RFC 2538 [5] X.509 owner name guidelines is not adequate because 101 they focus on the content of a certificate to determine how it should 102 be stored. This imposes a dilemma for a third party that wishes to 103 locate a certificate for an remote entity (e.g. identified with an 104 mail address) - they need to know parts of the certificate they want 105 to retrieve. In email applications the parties can in general only 106 be assumed to know a limited set of information about the other 107 entity. Such as the mail address. They do not know apriori the 108 X.509 DN of the remote entity. 110 When the RFC 2538 owner names for X.509 certificates are used, 111 clients that only knows e.g. the email address of a certificate 112 owner cannot infer the DNS name where the certificate is used. 114 For example, when the certificate for is 115 stored in DNS the owner name depends on what the certificate 116 contains. For instance if the users's URI is present in the 117 certificate the owner name for the certificate should, according to 118 the RFC 2538 rules, be the domain name in the URI. A mail client 119 that only knows the email address but not the URI cannot infer the 120 domain name used. 122 2.3 Administrative boundaries 124 3. Proposed representation 126 As we have seen, the DNS "owner name" guidelines described in RFC 127 2538 has several flaws. They also do not make the owner name 128 guidelines mandatory, which would be a advantage for interoperable 129 secure email. Below we specify a scheme for applications that use 130 RFC 2822 addresses to identify identities, such as Internet Mail and 131 the UseNet News. 133 N.B., the RFC 2538 guideliness MAY still be used in addition to the 134 owner names specified here. One of the owner names MAY be CNAMEs to 135 the other. 137 3.1 Algorithm to convert RFC 2822 address to domain name 139 To encode a RFC 2822 "addr-spec" into the string used to a DNS domain 140 name as represented in zone files, the "local-part" is appended with 141 "._mail." and concatenated with the "domain" part. 143 ;; INPUT (from RFC 2882 EBNF): 144 addr-spec = local-part "@" domain 146 ;; OUTPUT (domain name for DNS zone file): 147 local-part._mail.domain. 149 3.2 Case handling 151 Even though the local-part of a mail address may be case sensitive in 152 theory, the address SHOULD be converted to lower case before use. 154 3.3 Examples 156 A certificate for is stored at 157 leslie._mail.example.com. 159 A certificate for is stored at 160 firstname.lastname._mail.example.com. 162 4. Security Considerations 164 Since certificates are digitally signed, no additional integrity 165 service is necessary. Certificates do not need to be kept secret, 166 and anonymous access to certificates is generally acceptable, thus no 167 privacy service is necessary. However, clients that retrieve CRLs 168 without some way of verifying the server run the risk of being sent a 169 still current but superceded CRL. 171 Operators of DNS servers should authenticate end entities, CAs and 172 RAs who publish certificates. However, authentication is not 173 necessary to retrieve certificates. 175 When a zone is signed and published using the DNS security 176 extensions, it is feasible to traverse a zone by NXT-chaining to 177 collect mailboxes. This may not be desired. One solution might be 178 to store the certificates as unsigned RRsets [7] or use a hashed 179 alternative to the NXT chain [8]. 181 References 183 [1] Crocker, D., "Standard for the format of ARPA Internet text 184 messages", STD 11, RFC 822, August 1982. 186 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 187 Levels", BCP 14, RFC 2119, March 1997. 189 [3] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP 190 Message Format", RFC 2440, November 1998. 192 [4] Eastlake, D., "Domain Name System Security Extensions", RFC 193 2535, March 1999. 195 [5] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the 196 Domain Name System (DNS)", RFC 2538, March 1999. 198 [6] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 200 [7] Arends, R., Kosters, M. and D. Blacka, "DNSSEC Opt-In", work in 201 progress draft-ietf-dnsext-dnssec-opt-in-01, November 2001. 203 [8] Josefsson, S., "Authenticating denial of existence in DNS with 204 minimum disclosure", work in progress draft-ietf-dnsext-not- 205 existing-rr-01, November 2000. 207 Authors' Addresses 209 Jakob Schlyter 210 Carlstedt Research & Technology 211 Stora Badhusgatan 18-20 212 Goteborg SE-411 21 213 Sweden 215 EMail: jakob@crt.se 216 URI: http://www.crt.se/~jakob/ 218 Simon Josefsson 219 RSA Security 220 Arenavagen 29 221 Stockholm SE-121 29 222 Sweden 224 Phone: +46 8 725 09 14 225 EMail: sjosefsson@rsasecurity.com 227 Roy Arends 228 Nominum 229 1e Atjehstraat 174-2 230 Amsterdam 1094 KX 231 The Netherlands 233 EMail: roy.arends@nominum.com 234 URI: http://www.nominum.com/ 236 Appendix A. Acknowledgements 238 The authors gratefully acknowledges, in no particular order, the 239 contributions of the following persons: 241 Mats Dufberg 243 Olafur Gudmundsson 245 Dan Massey 247 Full Copyright Statement 249 Copyright (C) The Internet Society (2001). All Rights Reserved. 251 This document and translations of it may be copied and furnished to 252 others, and derivative works that comment on or otherwise explain it 253 or assist in its implementation may be prepared, copied, published 254 and distributed, in whole or in part, without restriction of any 255 kind, provided that the above copyright notice and this paragraph are 256 included on all such copies and derivative works. However, this 257 document itself may not be modified in any way, such as by removing 258 the copyright notice or references to the Internet Society or other 259 Internet organizations, except as needed for the purpose of 260 developing Internet standards in which case the procedures for 261 copyrights defined in the Internet Standards process must be 262 followed, or as required to translate it into languages other than 263 English. 265 The limited permissions granted above are perpetual and will not be 266 revoked by the Internet Society or its successors or assigns. 268 This document and the information contained herein is provided on an 269 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 270 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 271 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 272 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 273 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 275 Acknowledgement 277 Funding for the RFC Editor function is currently provided by the 278 Internet Society.