idnits 2.17.1 draft-pettersen-subtld-structure-10.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6265]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 16 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 13, 2014) is 3723 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2965 (Obsoleted by RFC 6265) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Pettersen 3 Internet-Draft Vivaldi Technologies AS 4 Updates: 6265 (if approved) February 13, 2014 5 Intended status: Experimental 6 Expires: August 17, 2014 8 The Public Suffix Structure file format and its use for Cookie domain 9 validation 10 draft-pettersen-subtld-structure-10 12 Abstract 14 This document defines the term "Public Suffix domain" as meaning a 15 domain under which multiple parties that are unaffiliated with the 16 owner of the Public Suffix domain may register subdomains. Examples 17 of Public Suffix domains include "org", "co.uk", "k12.wa.us" and 18 "uk.com". It also defines a file format that can be used to 19 distribute information about such Public Suffix domains to relying 20 parties. As an example, this information is then used to limit which 21 domains an Internet service can set HTTP cookies for, strengthening 22 the rules already defined by the cookie specification. This 23 specification updates RFC 6265 [RFC6265] by defining the term "Public 24 Suffix domain". 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 17, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 1. Introduction 75 The Domain Name System (DNS) [RFC1034] used to name Internet hosts 76 allows a wide range of hierarchical names to be used to indicate what 77 a kind of business a given host is engaged in. Some are implemented 78 by the owners of a domain, such as by creating subdomains for certain 79 tasks or functions, while others, called Public Suffixes (or 80 registry-like domains), are created by the Top Level Domain (TLD) 81 registry owner or individual domain owners to indicate what kind of 82 service the hosts under the domain provides, e.g., commercial, 83 educational, governmental or geographical location, such as city or 84 state. 86 While this system makes it relatively easy for TLD administrators to 87 organize online services, and for the user to locate and recognize 88 relevant services, this flexibility causes various security and 89 privacy-related problems when services located at different hosts are 90 allowed to share data through functionality administrated by the 91 client, e.g., HTTP state management cookies [RFC6265] and cross- 92 document information sharing in ECMAScript DOM. Most of these 93 information-sharing mechanisms make the process of sharing easy, 94 perhaps too easy, since, in many cases, there is no mechanism to 95 ensure that the servers receiving the information really want it. It 96 is also often difficult to determine the original source of the 97 information being shared. To some extent, [RFC2965] tried to address 98 some of these concerns for cookies, in that clients that send 99 [RFC2965]-style cookies also send the target domain for the cookie 100 along with the cookie so that the recipient can verify that the 101 cookie has the correct domain. Unfortunately, [RFC2965] was never 102 widely deployed in clients or on servers. The recipient server(s) 103 can make inappropriate information sharing more detectable by 104 requiring the information to contain data identifying the source, as 105 well as by assuring the integrity of the data, e.g., by using 106 cryptographic technologies. However, these techniques tend to be 107 computationally costly. 109 There are two problem areas: 111 o Incorrect sharing of information between non-associated services 112 e.g., example1.com and example2.com or example1.co.uk and 113 example2.co.uk -- That is, the information may be distributed to 114 all services within a given Top Level Domain or Public Suffix 115 domain. Sharing within a TLD is usually prevented by a simple 116 rule that does not permit it, but that is more difficult for 117 general Public Suffix domains, since they do not have a well 118 defined pattern. 120 o Undesirable information sharing within a single service -- This 121 is, in particular, a problem for services that sell hosting 122 services to many different customers, such as web hotels, where 123 the service itself has little or no control of the customers' 124 actions. 126 While both these problems are in some ways similar, they call for 127 different solutions. This specification will only propose a solution 128 for the first problem area. The second problem area must be handled 129 separately. This specification will first define what Public 130 Suffixes are; then it will propose a file format that can be used to 131 distribute information about the Public Suffixes within a Top Level 132 Domain, e.g., that the TLD have several Public Suffix domains, such 133 as co.tld, ac.tld, org.tld. Finally it will show how this 134 information can be used to determine when information sharing through 135 cookies is not desirable. 137 2. Public Suffix domains 139 A Public Suffix domain is used very much like a Top Level Domain. 140 The owner or operator of the domain allow unaffiliated third parties 141 to register domain names in the Public Suffix domain and to control 142 all activity inside the registered domain. 144 While most such domains are open to registration by the general 145 public, the owner of the Public Suffix domain may have defined 146 restrictions on which third parties may register a domain, such as 147 only private persons, schools, or government agencies, to mention a 148 few. Such limitations do not change the fact that each domain 149 registrant is nominally independent of all other domain registrants 150 in the Public Suffix domain, as well as of the owner of the Public 151 Suffix domain. 153 Just like a domain under a TLD may be a Public Suffix domain, a 154 domain registered under a Public Suffix domain may also be a Public 155 Suffix domain. Examples of this are the state.us and city.state.us 156 Public Suffix domains in the dot-US ccTLD. 158 There are various categories of Public Suffix domains. The most 159 common category is the second-level domain, used by many ccTLDs to 160 group content, such as co.tld for commercial, ac.tld for academic 161 institution, and gov.tld for government. Another common category is 162 Public Suffixes dedicated to geographical locations, such as as 163 states, provinces, and cities, such as the city.state.us domain 164 organization used by the US ccTLD, possibly with more Public Suffix 165 domains within these domains. A third category is ISP shared 166 hosting, and "vanity" domain names, e.g., country.com. In addition, 167 a number of social websites provide their users with direct access 168 names under their domains (e.g., http://example-user.example.com, 169 rather than using http://www.example.com/example-user URLs). 171 Information about Public Suffix domains can be used in several 172 security features in clients: 174 o Blocking websites' ability to set cookies to the Public Suffix 175 domain 177 o Limiting the ability of active content, such as EcmaScript, from 178 affecting content in independent domains that happen to share the 179 same Public Suffix domain as the source domain 181 o Highlighting the actual domain in the displayed URL in the 182 client's UI, to reduce the potential of a malicious site 183 misleading the user with a URL that identifies the host as www 184 .well-known-site.com.example.pubsuffix-domain.tld, which might 185 lead users to think they are visiting www.well-known-site.com 186 rather than a site in the domain example.pubsuffix-domain.tld 188 As there is currently no reliable method in DNS or other protocols 189 that allows clients to automatically recognize a Public Suffix 190 domain, the owner of such a domain must self-declare the domain's 191 status as a Public Suffix domain and register it with each of the 192 repositories that track such information. Such self-registration may 193 lead to inconsistencies between the various repositories, which could 194 cause security problems to develop. A more reliable method might be 195 that the TLD registrar collect such information from their registered 196 domains, and make it available to relying parties. Section 3 197 presents a XML-based format for how this information can be published 198 and shared by the TLD registrar. 200 3. The Public Suffix Structure file format 202 The Public Suffix Structure file format specifies how to encode 203 information about Public Suffix domains inside a TLD. It is based on 204 XML and is able to specify Public Suffixes and exceptions to any 205 level of the domain hierarchy that is desirable. 207 3.1. Domain list format 209 The domain list file can contain a list of subdomains that are 210 considered Public Suffix domains, as well as a special list of names 211 that are not top level domains. None of the domain lists need 212 specify the TLD name, since that is implied either by the file that 213 is parsed or by the content of the tag. The domain names 214 listed MUST be encoded in punycode, as specified by [RFC5891]. 216 3.1.1. Domain list schema 218 The domain list is an XML file that follows the following schema: 220 default namespace = "http://xmlns.opera.com/tlds" 222 start = 223 element tld { 224 attribute levels { xsd:nonNegativeInteger | "all"}, 225 attribute name { xsd:NCName }, 226 (domain | registry)* 227 } 228 registry = 229 element registry { 230 attribute levels { xsd:nonNegativeInteger }, 231 attribute name { xsd:NCName }, 232 attribute all { string "true" | string "false" }, 233 (domain | registry)* 234 } 235 domain = 236 element domain { 237 attribute name { xsd:NCName } 238 } 240 The domain list file usually contains a single -block (but may 241 contain multiple entries), which may contain multiple registry and 242 domain blocks, and a registry block, which define a Public Suffix 243 domain, may also contain multiple registry and domain blocks. When 244 used alone, the -block MAY contain a name field identifying the 245 TLD name; if there are multiple -blocks, each block MUST specify 246 the name field. 248 Both and tags MUST contain a name attribute 249 identifying the domain or registry. The -block MAY have a name 250 attribute, but in files with a single -block this name MUST be 251 ignored by clients, which must instead use the name of the TLD used 252 to request the file. 254 All names SHOULD be punycode encoded [RFC5891] to make it possible 255 for clients unaware of either Unicode or IDNA to use the document. 257 The - and -blocks MAY contain an attribute, "levels", 258 specifying how many levels below the current domain are Public 259 Suffixes. The default is "none", meaning that the default inside the 260 current domain level is that labels are ordinary domains and not 261 Public Suffix domains. If the value of the "levels" attribute is 1 262 (one) by default all next-level labels within the registry/TLD are 263 Public Suffix domains, not normal domains. If the value of the 264 "levels" attribute is the case-insensitive token "all", then all 265 subdomains domains below the current domain are Public Suffix 266 domains, by default. 268 A -block with the attribute "all" set to "true" inside the 269 declaration for the registry domain example.tld indicates that all 270 domains x.example.tld are also Public Suffix domains, by default, 271 unless a domain is specified differently by a different declaration. 272 The registry-all block may contain additional - or 273 -blocks, which then apply to domains foo.x.example.tld, for 274 all domains x, except those that have separate entries. This allows 275 specification of wildcard structures, where the structure for lower 276 domains are similar for all domains. 278 Implementations MUST ignore attributes and syntax they do not 279 recognize. 281 3.1.2. Domainlist interpretation 283 For each new - or -block within the - or 284 -block, the effective domain name to which the block 285 applies is the name of the block prepended to the ".parentdomain" of 286 the effective domain name of the containing block. 288 For the -block the effective domain name is the name of the TLD 289 the client is evaluating, and for the -block named 290 "example" the effective name becomes example.tld. 292 293 294 295 296 297 298 300 301 302 303 304 305 307 In the above example, the specification is for the TLD "tld". By 308 default any second level domain "x.tld" is a Public Suffix domain; 309 although, parliament.tld is not a Public Suffix domain, but a normal 310 domain. 312 In the example TLD, however, the co.tld registry has a sub registry 313 "state.co.tld", while all other domains in the co.tld domains are 314 ordinary domains. 316 Additionally, all domains x.province.tld are Public Suffixes, and all 317 school.x.province.tld are normal domains for all domains x in 318 province.tld. 320 Also, the registry example.tld has defined all domains y.example.tld 321 as Public Suffixes, with no exceptions. 323 3.2. Public Suffix Structure as a web service 325 The Public Suffix structure file can be provided as an HTTP service, 326 managed by either the application vendor, the TLD owners, or some 327 other trusted organization, and it can be located at a URI location 328 that, when queried, returns information about a TLD's domain 329 structure. The client can then use this information to decide what 330 actions are permitted for the protocol data the client is processing. 331 The procedure for use as a service is as follows: 333 o The client retrieves the domain list for the Top Level Domain 334 "tld" from the vendor specified URI https://tld- 335 structure.example.com/tld/domainlist . Multiple alternative URIs 336 for a fallback procedure may be specified. 338 o The Content-Type of the returned list MUST be application/ 339 subdomain-structure. 341 o The retrieved specification SHOULD be cached by the client for at 342 least 30 days. 344 o The TLD owner SHOULD update the list at least 90 days before a new 345 sub-domain becomes active. 347 o If no specification can be retrieved the user agent MAY fall back 348 to alternative, undefined methods, depending on the profile. 350 3.3. Securing the domain information 352 Individuals with malicious intent may wish to modify the domain list 353 served by the service location to either classify a domain 354 incorrectly as a Public Suffix domain or to hide a Public Suffix 355 domain's classification. Besides obviously securing the hosting 356 locations, this also means that the content served will have to be 357 secured. 359 1. Digitally sign the specification, using one of the available 360 message signature methods, e.g., S/MIME [RFC2311]. This will 361 secure the content during storage both at the client and the 362 server, as well as during transit. The drawback is that the 363 client must implement decoding and verification of the message 364 format that it may not already support, which may be problematic 365 for clients having limited resources. 367 2. Use an encrypted connection, such as HTTP over TLS [RFC2818], 368 which is supported by many clients already. Unfortunately, this 369 method does not protect the content when stored by the client. 371 3. Use XML Signatures [RFC3275] to create a signature over the 372 specification. This method is currently not defined. 374 This specification recommends using HTTP over TLS, and the client 375 MUST use the non-anonymous cipher suites, to secure the transport of 376 the specification. The client MUST ensure that the hostname in the 377 certificate matches the hostname used in the request. 379 4. A Public Suffix Structure file format profile for HTTP Cookies 381 The HTTP State management cookies area is one where it is important, 382 both for security and privacy reasons, to ensure that unauthorized 383 services cannot set cookies for another service. Inappropriate 384 cookies can affect the functionality of a service, but they may also 385 be used to track the users across services in an undesirable fashion. 386 Neither the original Netscape cookie specification[NETSC], [RFC2965] 387 or [RFC6265] are adequate in many cases. 389 The original Netscape specification's rules required only that the 390 target domain must have one internal dot (e.g., example.com) if the 391 TLD belongs to a list of generic TLDs (gTLD), while for all other 392 TLDs the domain must contain two internal dots (e.g., example.co.uk). 393 The latter rule was never properly implemented, in particular due to 394 the many flat ccTLD domain structures that are in use. (The 395 successor [RFC6265] has since expanded this policy to exclude domains 396 listed in client-specific lists of "public suffixes").[RFC2965] set 397 the requirement that cookies can only be set for the server's parent 398 domain. 400 Unfortunately, both the [NETSC] and [RFC2965] policies still left 401 open the possibility of setting cookies for a Public Suffix domain by 402 setting the cookie from a host name example.pubsuf.tld to the domain 403 pubsuf.tld, which is by itself legal, but not desirable, because that 404 means that the cookie can be sent to numerous websites either 405 revealing sensitive information, or interfering with those other 406 websites without authorization. As can be seen, these rules do not 407 work satisfactorily, especially when applied to ccTLDs, which may 408 have a flat domain structure similar to the one used by the generic 409 .com TLD, a hierarchical Public Suffix domain structure like the one 410 used by the .uk ccTLD (e.g., .co.uk), or a combination of both. 411 However, there are also gTLDs, such as .name, for which cookies 412 should not be allowed for the second-level domains, as these are 413 generally family names shared between many different users, not 414 service names. A partially effective method for distinguishing 415 service names from Public Suffix domains by using DNS was developed 416 by Opera Software ASA. However, this method was not immune to TLD 417 registries that use Public Suffix domains as directories or to 418 services that do not define an IP address for the domain name. Using 419 the Public Suffix Structure file format to retrieve a list of all 420 Public Suffix domains in a given TLD will solve both those problems. 422 4.1. Procedure for using the Public Suffix Structure file format for 423 cookies 425 When receiving a cookie, the client must first perform all the checks 426 required by the relevant specification. Upon completion of these 427 checks the client then performs the following additional verification 428 checks if the cookie is being set for the server's parent, grand- 429 parent domain (or higher): 431 1. If the Public Suffix domain structure of the TLD is not known 432 already, or the structure information has expired, according to 433 the client's policies, the client should retrieve or revalidate 434 the structure specification from the server hosting the 435 specification, according to Section 3. If retrieval is 436 unsuccessful, and no copy of the specification is known, the 437 client MAY use alternative information or heuristics to decide 438 the domain's status. Upon successful retrieval the specification 439 is evaluated as specified in Section 3. If the target domain is 440 designated as a Public Suffix domain, then the cookie MUST be 441 discarded or, alternatively, processed as if it had not specified 442 a domain attribute. 444 2. If the target domain is not a Public Suffix domain, the cookie is 445 accepted (unless other policies configured for the client prevent 446 this). 448 4.2. Third party cookies 450 Use of HTTP Cookies, combined with HTTP requests to resources that 451 are located in domains other than the one the user actually wants to 452 visit, have caused widespread privacy concerns. The reason is that 453 multiple websites can link to the same independent website, e.g., an 454 advertiser, who may then use cookies to build a profile of the 455 visitor, which can be used to select advertisements that might be of 456 interest to the user. 458 Some clients have therefore implemented restrictions on what cookie 459 related activities are accepted in relation to a third-party domain. 460 Frequently, such restrictions are based on determining whether the 461 two hosts share the same immediate parent domain as a domain suffix, 462 or if the first domain of the two is a parent domain (suffix) of the 463 other. 465 This determination method might incorrectly classify a third-party 466 server as a first party if the immediate parent domain of the first 467 party server is a Public Suffix domain, and possibly break the user's 468 privacy expectations. 470 To avoid such misclassifications, when the two servers have the first 471 party server's immediate parent domain as a shared suffix, clients 472 SHOULD apply the procedure specified in Section 4.1 for this domain, 473 and, if this domain is determined to be a Public Suffix domain, the 474 second host must be considered a third party. That is, if the first 475 party server example.co.uk causes a request for a resource at 476 example3.co.uk the parent domain co.uk is determined to be a Public 477 Suffix domain, and example3.co.uk is therefore a third-party server, 478 even if they share the same immediate parent domain. 480 5. Examples 482 The following examples demonstrate how the Public Suffix Structure 483 file format can be used to decide cookie domain permissions. 485 5.1. Example 1 487 488 489 490 492 This specification means that all names at the top level are Public 493 Suffix domains, except "example.tld" for which cookies are allowed. 494 Cookies are also implicitly allowed for any y.x.tld domains. 496 5.2. Example 2 498 499 500 501 502 504 This specification means that example1.tld and example2.tld and any 505 domains (foo.example1.tld and bar.example2.tld) are Public Suffix 506 domains for which cookies are not allowed; for any other domains 507 cookies are allowed. 509 5.3. Example 3 510 511 512 513 514 515 516 518 This example has the same meaning as Example 2, but with the 519 exception that the domain example3.example2.tld is a regular domain 520 for which cookies are allowed. 522 6. IANA Considerations 524 This specification also requires that responses are served with a 525 specific media type. Below is the registration information for this 526 media type. 528 6.1. Registration of the application/subdomain-structure Media Type 530 Type name : application 532 Subtype name: subdomain-structure 534 Required parameters: none 536 Optional parameters: none 538 Encoding considerations: The content of this media type is always 539 transmitted in binary form. 541 Security considerations: See Section 7. 543 Interoperability considerations: none 545 Published specification: This document 547 Additional information: 549 Magic number(s): none 551 File extension(s): 553 Macintosh file type code(s): 555 Person & email address to contact for further information: Yngve N. 556 Pettersen 557 Email: yngve@vivaldi.com 559 Intended usage: common 561 Restrictions on usage: none 563 Author/Change controller: Yngve N. Pettersen 565 Email: yngve@vivaldi.com 567 7. Security Considerations 569 Retrieval of the Public Suffix Structure specifications is vulnerable 570 to denial of service attacks or loss of network connection. Hosting 571 the specifications at a single location can increase this 572 vulnerability, although the exposure can be reduced by using mirrors 573 with the same name but hosted at different network locations. This 574 protocol is as vulnerable to DNS security problems as any other 575 [RFC2616] HTTP-based service. Requiring the specifications to be 576 digitally signed or transmitted over a authenticated TLS connection 577 reduces this vulnerability. 579 Section 4 of this document describes using the domain list defined in 580 Section 3 as a method of increasing security and privacy. The 581 effectiveness of the domain list for this purpose, and the resulting 582 security and privacy improvements for the user, depend both on the 583 integrity of the list, and its correctness. The integrity of the 584 list depends on how securely it is stored in the repository and how 585 securely it is transmitted. This specification recommends 586 downloading the domain list using HTTP over TLS [RFC2818], which 587 makes the transmission as secure as the message authentication 588 mechanism used (encryption is not required), and the servers should 589 be configured to use the strongest available key lengths and 590 authentication mechanisms. An alternative or complimentary approach 591 would be to digitally sign the files. 593 The correctness of the list depends on how well the TLD registry 594 defined it, or how well the list maintainer have been able to collect 595 correct information. A list that does not include some Public Suffix 596 domains may expose the client to potential privacy and security 597 problems, but the situation would not be any worse than it would be 598 without this protocol and profile, while a subdomain incorrectly 599 classified as a Public Suffix domain can lead to denial of service 600 for the affected services. Both of the problems can be prevented by 601 careful construction and auditing of the lists, both by the TLD regis 602 try and by interested third parties. 604 8. Acknowledgments 606 Anne van Kesteren assisted with defining the XML format in 607 Section 3.1.1. 609 The Public Suffix List project [PUBSUFFIX] was initiated by members 610 of the Mozilla Community, and members of the project, in particular 611 Gervase Markham, have provided input to this document. 613 9. References 615 9.1. Normative References 617 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 618 STD 13, RFC 1034, November 1987. 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, March 1997. 623 [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and 624 L. Repka, "S/MIME Version 2 Message Specification", RFC 625 2311, March 1998. 627 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 628 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 629 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 631 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 633 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 634 Language) XML-Signature Syntax and Processing", RFC 3275, 635 March 2002. 637 [RFC5891] Klensin, J., "Internationalized Domain Names in 638 Applications (IDNA): Protocol", RFC 5891, August 2010. 640 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 641 April 2011. 643 9.2. Non-normative references 645 [NETSC] "Persistent Client State HTTP Cookies", 646 . 649 [PUBSUFFIX] 650 "The Homepage of the Public Suffix List, a list of 651 registry-like domains gathered by volunteers.", 652 . 654 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 655 Mechanism", RFC 2965, October 2000. 657 Appendix A. Collection of information for the TLD structure 658 specification 660 This document does not define how the information encoded in the TLD 661 Structure Specification is gathered. 663 There are several methods available for collecting the information 664 encoded in the TLD Structure Specification, the two main ones being: 666 Data provided by the TLD registry owner through a machine readable 667 repository at well known locations 669 Data gathered by one or more application vendors based on publicly 670 available information, such as the Mozilla Project's Public Suffix 671 List[PUBSUFFIX], 673 Appendix B. Alternative solutions 675 A possible alternative to the format specified in Section 3, encoding 676 the information directly in the DNS records for the Public Suffix 677 domain, using a DNS extension. 679 Accessing this type of information requires that the client or its 680 environment is able to directly access the DNS network. In many 681 environments, e.g., firewalled systems, this may not be possible. 682 Also, not all runtime environments can provide this information, 683 which may lead to a DNS client embedded directly in the client. 685 For some applications, it may be necessary, due to system 686 limitations, to access this information through an online web service 687 in order to provide the necessary information for each hostname or 688 domain visited. A web service may, however, introduce unnecessary 689 privacy problems, as well as delays each time a new domain is tested. 691 Appendix C. Open issues 693 o Download location URI for the original domain lists 695 o Should Digital signatures be used on the files, instead of using 696 TLS? 698 Author's Address 700 Yngve N. Pettersen 701 Vivaldi Technologies AS 702 Norway 704 Email: yngve@vivaldi.com