idnits 2.17.1 draft-bsag-domain-ownership-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 204 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (20 November 2015) is 3078 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Ben Golightly 2 Expires: May 23 2016 20 November 2015 4 A Method for Verification of Domain Name Ownership 5 draft-bsag-domain-ownership-00 7 Abstract 9 This document defines a method for website administrators to verify 10 ownership of a domain name to third party service providers. 12 1. Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF). Note that other groups may also distribute 19 working documents as Internet-Drafts. The list of current 20 Internet-Drafts is at http://datatracker.ietf.org/drafts/current. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as 26 "work in progress." 28 Comments are solicited and should be addressed to the working 29 group's mailing list and/or the author(s). 31 This Internet-Draft will expire on May 23, 2016. 33 2. Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. 45 3. Introduction 47 Website administrators are often required to verify ownership of 48 a domain name to a third party service provider. This verification 49 process may form a part of access control, privacy control, or 50 security and fraud prevention more generally. 52 Examples: 54 * a webmaster may verify their ownership of a domain with a search 55 engine in order to change how the website is displayed in search, 56 diagnose issues, and access search analytics. 58 * a digital Certificate Authority issuing an SSL certificate will 59 verify domain name ownership to prevent a "man in the middle" 60 attacker from being able to act as an imposter when intercepting 61 HTTPS connections to the targeted domain name. 63 To date, there is no standard way to do this. The service provider 64 will normally specify a method such as: 66 * Adding a vendor-specific meta tag to the home page of the website 67 accessible at the given domain, or more generally add some specific 68 HTML to the website. 70 * Uploading a HTML file with a specific file name and content to 71 the root directory of the website accessible at the given domain. 73 * Modifying the DNS records for the domain. 75 * Emails sent to a specific administrator e-mail address for a 76 domain. 78 Domain names expire or change ownership. Therefore, these methods of 79 verification must be permanently maintained by the website 80 administrator and regularly checked by the service provider. 82 These vendor-specific HTML files are often cryptically named, and 83 clutter the root directory of a website. 85 The method specified in this memo allows website administrators to 86 simplify webserver and domain name maintanence by centralising 87 verification information, and allows service providers to streamline 88 the verification process by avoiding vendor-specific verification 89 methods. 91 4. Specification 93 This memo specifies a format for encoding domain name verification 94 information provided by a service provider, and a method for 95 retrieving this information. Service providers may retrieve this 96 information and treat it as current evidence of domain ownership. 98 4.1 Access method 100 The verification information must be accessible via HTTP from the 101 domain requiring verification, under a standard relative path on the 102 server: "/verify.txt". 104 For convenience this resource may be referred to as a "verify.txt 105 file", though the resource need in fact not originate from a file- 106 system. 108 This file must be served with a MIME Type of "text/plain". The 109 character encoding must be UTF-8. 111 4.2 File Format Description 113 The format consists of a list of records, separated by blank lines 114 and comment lines. 116 A comment line takes the form: 118 # 120 Each record takes the form: 122 [] 124 For example: 126 # verify.txt example 127 example.org ExampleServiceProvider1 exampleAccountId-1234 128 example.org ExampleServiceProvider1 exampleAccountId-5678 129 example.com ExampleServiceProvider2 example-ABCDEF 130 example.com ExampleServiceProvider3 131 testing.example.com Example4 v=1;u=123;d=20150102 133 4.2.1 The Domain field 135 One webserver may be accessible from several different domain names. 136 The Domain field identifies to which domain name the verification 137 record applies. 139 The content of the domain field must be any validly formatted domain 140 name or IP address. 142 4.2.2 The ServiceProvider field 144 This is a field identifying the service provider requiring the 145 verification. There is no restriction on the format of this field, 146 except that it may not contain whitespace. Service providers should 147 pick descriptive names that uniquely identify an organisation or 148 service. This could be the URL of the service. 150 The length of this field should not exceed 256 bytes. 152 4.2.3 The value field 154 This is an optional field containing a value assigned by the service 155 provider. This may be used, for example, to associate a specific 156 account with the service provider with the verified domain. There 157 is no restriction on the format of this field, except that it may 158 not contain whitespace. 160 The length of this field should not exceed 4096 bytes. 162 4.3 Interoperability 164 Service providers should be liberal in accepting files with different 165 end-of-line conventions, specifically CR and LF in addition to CRLF. 167 With the exception of line breaks, service providers should ignore 168 whitespace except as a separator between fields in a record. 170 5. Security Considerations 172 Website administrators should prevent unauthorised users from 173 creating verify.txt files at the root of any domain (including 174 subdomains). 176 Website administrators should be cautious of the verify.txt file 177 being maliciously modified, and used to verify unauthorised users 178 to service providers. Website administrators should use appropriate 179 best practice, such as audited source control, to detect and trace 180 modifications. 182 Service providers are encouraged to place limits on the resources 183 spent on processing verify.txt files. 185 Service providers should be aware that domain names expire or change 186 ownership, and take steps to reverify as appropriate. 188 Service providers should be aware that, as with any verification 189 method, it may be possible for a user to impersonate a domain 190 administrator. The required strength of verification should be 191 balanced against the desired ease of verification. 193 6. IANA Considerations 195 This document has no actions for IANA. 197 7. Author's Address 199 Ben Golightly 200 Tawesoft Ltd 201 Email: ben@tawesoft.co.uk