idnits 2.17.1 draft-pettersen-subtld-structure-08.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 21 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 (July 11, 2011) is 4673 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 Opera Software ASA 4 Updates: 6265 (if approved) July 11, 2011 5 Intended status: Experimental 6 Expires: January 12, 2012 8 The Public Suffix Structure file format and its use for Cookie domain 9 validation 10 draft-pettersen-subtld-structure-08 12 Abstract 14 This document defines the term "Public Suffix" as meaning a domain 15 under which multiple parties that are unaffiliated with the owner may 16 register subdomains. Examples of Public Suffixes include "org", 17 "co.uk" and "k12.wa.us". It also defines a fileformat that can be 18 used to distribute information about such Public Suffixes to relying 19 parties. As an example, this information is then used to limit which 20 domains an Internet service can set cookies for, strengthening the 21 rules already defined by the cookie specifications. This 22 specification updates RFC 6265 [RFC6265] by defining the term "Public 23 Suffix". 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 12, 2012. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 1. Introduction 73 The Domain Name System [RFC1034] used to name Internet hosts allows a 74 wide range of hierarchical names to be used to indicate what a given 75 host is. Some are implemented by the owners of a domain, such as by 76 creating subdomains for certain tasks or functions, while others, 77 called Public Suffixes (or registry-like domains), are created by the 78 Top Level Domain registry owner or individual domain owners to 79 indicate what kind of service the domain is, e.g., commercial, 80 educational, governmental or geographical location, e.g., city or 81 state. 83 While this system makes it relatively easy for TLD administrators to 84 organize online services, and for the user to locate and recognize 85 relevant services, this flexibility causes various security and 86 privacy-related problems when services located at different hosts are 87 allowed to share data through functionality administrated by the 88 client, e.g., HTTP state management cookies [RFC6265] and cross- 89 document information sharing in Ecmascript DOM. Most of these 90 information-sharing mechanisms make the process of sharing easy, 91 perhaps too easy, since, in many cases, there is no mechanism to 92 ensure that the servers receiving the information really want it. It 93 is also often difficult to determine the source of the information 94 being shared. To some extent, [RFC2965] addressed some of these 95 concerns for cookies, in that clients that support [RFC2965]-style 96 cookies send the target domain for the cookie along with the cookie 97 so that the recipient can verify that the cookie has the correct 98 domain. Unfortunately, [RFC2965] was never widely deployed in 99 clients or on servers. The recipient(s) can make inappropriate 100 information sharing more difficult by requiring the information to 101 contain data identifying the source, as well as by assuring the 102 integrity of the data, e.g., by using cryptographic technologies. 103 However, these techniques tend to be computationally costly. 105 There are two problem areas: 107 o Incorrect sharing of information between non-associated, services 108 e.g., example1.com and example2.com or example1.co.uk and 109 example2.co.uk -- That is, the information may be distributed to 110 all services within a given Top Level Domain. 112 o Undesirable information sharing within a single service -- This 113 is, in particular, a problem for services that sell hosting 114 services to many different customers, such as web hotels, where 115 the service itself has little or no control of the customers' 116 actions. 118 While both these problems are in some ways similar, they call for 119 different solutions. This specification will only propose a solution 120 for the first problem area. The second problem area must be handled 121 separately. This specification will first define what Public 122 Suffixes are; then it will propose a file format that can be used to 123 distribute information about the Public Suffixes within a Top Level 124 Domain, e.g., that the TLD have several Public Suffixes, such as 125 co.tld, ac.tld, org.tld. Finally it will show how this information 126 can be used to determine when information sharing through cookies is 127 not desirable. 129 2. Public Suffix 131 A Public Suffix domain is used very much like a Top Level Domain. 132 The owner or operator of the domain allow unaffiliated third parties 133 to register domain names in the Public Suffix domain and to control 134 all activity inside the registered domain. 136 While most such domains are open to registration by the general 137 public, the owner of the Public Suffix domain may have restrictions 138 on which third parties may register a domain, such as only private 139 persons, schools, government agencies, to mention a few. Such 140 limitations do not change the fact that each domain registrant is 141 nominally independent of each other and the owner of the Public 142 Suffix domain. 144 Just like a domain under a TLD may be a Public Suffix, a domain 145 registered under a Public Suffix may also be a Public Suffix. 147 There are various categories of Public Suffixes. The most common 148 category is the second level domain, used by many ccTLDs to group 149 content, such as co.tld for commercial, ac.tld for academic 150 institution, gov.tld for government. Another common category is 151 Public Suffixes dedicated to geographical locations, such as as 152 states, provinces and cities, such as the city.state.us domain 153 organization used by the US ccTLD, possibly with further Public 154 Suffix organization below these. A third category is ISP shared 155 hosting, and "vanity" domain names, e.g., country.com. In addition, 156 a number of social websites provide their users with direct access 157 names under their domains (e.g., http://example-user.example.com, 158 rather than using http://www.example.com/example-user URLs). 160 Information about Public Suffix domains can be used in several 161 security features in clients: 163 o Blocking websites' ability to set cookies to the Public Suffix 164 domain 166 o Limiting the ability of active content, such as EcmaScript, from 167 affecting content in independent domains that share the same 168 Public Suffix 170 o Highlight the actual domain in the displayed URL in the client's 171 UI, to reduce the potential of a malicious site misleading the 172 user with a URL that identifies the host as www.well-known- 173 site.com.example.pubsuffix-domain.tld, which might lead users to 174 think they are visiting www.well-known-site.com rather than a site 175 in the domain example.pubsuffix-domain.tld . 177 As there is currently no reliable method in DNS or other protocols 178 that allows clients to recognize a Public Suffix domain, the owner of 179 such a domain must self-declare its domain's status as a Public 180 Suffix and register it with each of the repositories that track such 181 information. Section 3 presents a XML-based format for how this 182 information can be published and shared via the TLD registrar. 184 3. The Public Suffix Structure file format 186 The Public Suffix Structure file format specifies how to encode 187 information about Public Suffix domains inside a TLD. It is based on 188 XML and is able to specify Public Suffixes and exceptions to any 189 level of the domain hierarchy that is desirable. 191 3.1. Domainlist format 193 The domain list file can contain a list of subdomains that are 194 considered Public Suffix domains, as well as a special list of names 195 that are not top level domains. None of the domain lists need 196 specify the TLD name, since that is implied either by the file that 197 is parsed or by the content of the tag. The domain names 198 listed MUST be encoded in punycode, as specified by to [RFC5891]. 200 3.1.1. Domainlist schema 202 The domain list is an XML file that follows the following schema: 204 default namespace = "http://xmlns.opera.com/tlds" 206 start = 207 element tld { 208 attribute levels { xsd:nonNegativeInteger | "all"}, 209 attribute name { xsd:NCName }, 210 (domain | registry)* 211 } 212 registry = 213 element registry { 214 attribute levels { xsd:nonNegativeInteger }, 215 attribute name { xsd:NCName }, 216 attribute all { string "true" | string "false" }, 217 (domain | registry)* 218 } 219 domain = 220 element domain { 221 attribute name { xsd:NCName } 222 } 224 The domainlist file usually contains a single -block (but may 225 contain multiple entries), which may contain multiple registry and 226 domain blocks, and a registry block may also contain multiple 227 registry and domain blocks. When used alone, the -block MAY 228 contain a name field identifying the TLD name; if there are multiple 229 -blocks, each block MUST specify the name field. 231 Both and tags MUST contain a name attribute 232 identifying the domain or registry. The -block MAY have a name 233 attribute, but in files with a single -block this name MUST be 234 ignored by clients, which must instead use the name of the TLD used 235 to request the file. 237 All names SHOULD be punycode encoded to make it possible for clients 238 not supporting Unicode and IDNAto use the document. 240 The - and -blocks MAY contain an attribute, levels, 241 specifying how many levels below the current domain are Public 242 Suffixes. The default is "none", meaning that the default inside the 243 current domain level is that labels are ordinary domains and not 244 Public Suffixes. If the levels attribute is 1 (one) it means that by 245 default all next-level labels within the registry/TLD are Public 246 Suffixes and not normal domains. If the levels attribute is the 247 case-insensitive token "all", then all subdomains domains below the 248 current domain are Public Suffixes. 250 A -block with attribute "all" set to "true" means that all 251 domains in that registry (at the current level) are registries, 252 unless there are overrides, and may contain additional - or 253 -blocks, which then apply to domains x.example.tld, if the 254 all block is inside the "example" block of "tld". This allows 255 specification of wildcard structures, where the structure for lower 256 domains are similar for all domains. 258 Implementations MUST ignore attributes and syntax they do not 259 recognize. 261 3.1.2. Domainlist interpretation 263 For each new - or -block within the - or 264 -block, the effective domain name to which the block 265 applies is the name of the block prepended to the ".parentdomain" of 266 the effective domain name of the containing block. 268 For the -block the effective domain name is the name of the TLD 269 the client is evaluating, and for the -block named 270 "example" the effective name becomes example.tld. 272 273 274 275 276 277 278 280 281 282 283 284 285 287 In the above example, the specification is for the TLD "tld". By 288 default any second level domain "x.tld" is a Public Suffix domain; 289 although, parliament.tld is not a Public Suffix domain, but a normal 290 domain. 292 In the example TLD, however, the co.tld registry has a sub registry 293 "state.co.tld", while all other domains in the co.tld domains are 294 ordinary domains. 296 Additionally, all school.domain.province.tld domains for all "domain" 297 labels, and any other domain under domain.province.tld are Public 298 Suffixes. 300 Also, the registry example.tld has defined all domains y.example.tld 301 as Public Suffixes, with no exceptions. 303 3.2. Public Suffix Structure as a web service 305 The Public Suffix structure file can be provided as an HTTP service, 306 managed by either the application vendor, the TLD owners, or some 307 other trusted organization, and it can be located at a URI location 308 that, when queried, returns information about a TLD's domain 309 structure. The client can then use this information to decide what 310 actions are permitted for the protocol data the client is processing. 311 The procedure for use as a service is as follows: 313 o The client retrieves the domain list for the Top Level Domain 314 "tld" from the vendor specified URI 315 https://tld-structure.example.com/tld/domainlist . Multiple 316 alternative URI for fallback procedure may be specified. 318 o The Content-Type of the returned list MUST be application/ 319 subdomain-structure. 321 o The retrieved specification SHOULD be cached by the client for at 322 least 30 days. 324 o The TLD owner SHOULD update the list at least 90 days before a new 325 sub-domain becomes active. 327 o If no specification can be retrieved the user agent MAY fall back 328 to alternative methods, depending on the profile. 330 3.3. Securing the domain information 332 Individuals with malicious intent may wish to modify the domain list 333 served by the service location to either classify a domain 334 incorrectly as a Public Suffix domain or to hide a Public Suffix 335 domain's classification. Besides obviously securing the hosting 336 locations, this also means that the content served will have to be 337 secured. 339 1. Digitally sign the specification, using one of the available 340 message signature methods, e.g., S/MIME [RFC2311]. This will 341 secure the content during storage both at the client and the 342 server, as well as during transit. The drawback is that the 343 client must implement decoding and verification of the message 344 format that it may not already support, which may be problematic 345 for clients having limited resources. 347 2. Use an encrypted connection, such as HTTP over TLS [RFC2818], 348 which is supported by many clients already. Unfortunately, this 349 method does not protect the content when stored by the client. 351 3. Use XML Signatures [RFC3275] to create a signature over the 352 specification. This method is currently not defined. 354 This specification recommends using HTTP over TLS, and the client 355 MUST use the non-anonymous cipher suites, to secure the transport of 356 the specification. The client MUST ensure that the hostname in the 357 certificate matches the hostname used in the request. 359 4. A TLD Subdomain Structure Protocol profile for HTTP Cookies 361 The HTTP State management cookies areais one where it is important, 362 both for security and privacy reasons, to ensure that unauthorized 363 services cannot set cookies for another service. Inappropriate 364 cookies can affect the functionality of a service, but they may also 365 be used to track the users across services in an undesirable fashion. 366 Neither the original Netscape cookie specification[NETSC], [RFC2965] 367 or [RFC6265] are adequate in many cases. 369 The original Netscape specification's rules require only that the 370 target domain must have one internal dot (e.g., example.com) if the 371 TLD belongs to a list of generic TLDs (gTLD), while for all other 372 TLDs the domain must contain two internal dots (e.g., example.co.uk). 373 The latter rule was never properly implemented, in particular due to 374 the many flat ccTLD domain structures that are in use. (The 375 successor [RFC6265] has since expanded this policy to exclude client- 376 specific lists of "public suffixes"). 378 [RFC2965] set the requirement that cookies can only be set for the 379 server's parent domain. 381 Unfortunately, both policies still leave open the possibility of 382 setting cookies for a Public Suffix domain by setting the cookie from 383 a host name example.pubsuf.tld to the domain pubsuf.tld, which is by 384 itself legal, but not desirable, because that means that the cookie 385 can be sent to numerous websites either revealing sensitive 386 information, or interfering with those other websites without 387 authorization. As can be seen, these rules do not work 388 satisfactorily, especially when applied to ccTLDs, which may have a 389 flat domain structure similar to the one used by the generic .com 390 TLD, a hierarchical Public Suffix domain structure like the one used 391 by the .uk ccTLD (e.g., .co.uk), or a combination of both. However, 392 there are also gTLDs, such as .name, for which cookies should not be 393 allowed for the second-level domains, as these are generally family 394 names shared between many different users, not service names. A 395 partially effective method for distinguishing service names from 396 Public Suffix domains by using DNS has been defined in [DNSCOOKIE]. 397 However, this method is not immune to TLD registries that uses Public 398 Suffix domains as directories or to services that do not define an IP 399 address for the domain name. Using the TLD Subdomain Structure 400 Protocol to retrieve a list of all Public Suffix domains in a given 401 TLD will solve both those problems. 403 4.1. Procedure for using the TLD Subdomain Structure Protocol for 404 cookies 406 When receiving a cookie, the client must first perform all the checks 407 required by the relevant specification. Upon completion of these 408 checks the client then performs the following additional verification 409 checks if the cookie is being set for the server's parent, grand- 410 parent domain (or higher): 412 1. If the Public Suffix structure of the TLD is not known already, 413 or the structure information has expired, the client should 414 retrieve or validate the structure specification from the server 415 hosting the specification, according to Section 3. If retrieval 416 is unsuccessful, and no copy of the specification is known, the 417 client MAY use alternative methods to decide the domain's status, 418 e.g., those described in [DNSCOOKIE], or other heuristics. 419 Evaluate the specification as specified in section 2. If the 420 target domain is designated as a Public Suffix domain, then the 421 cookie MUST be discarded. 423 2. If the target domain is not a Public Suffix domain, the cookie is 424 accepted (unless other policies configured for the client prevent 425 this). 427 4.2. Unverifiable transactions 429 Use of HTTP Cookies, combined with HTTP requests to resources that 430 are located in domains other than the one the user actually wants to 431 visit, have caused widespread privacy concerns. The reason is that 432 multiple websites can link to the same independent website, e.g., an 433 advertiser, who may then use cookies to build a profile of the 434 visitor, which can be used to select advertisements that might be of 435 interest to the user. 437 [RFC2965] specified that if the name of the host of an included 438 resource does not domain match the domain reach (defined as the 439 parent domain of the host) of the URL of the document the user 440 started loading, loading the resource is considered an unverifiable 441 transaction, and in such third party transactions cookies should not 442 be sent or accepted. The latter point is not widely implemented, 443 except when selected by especially interested users. This means that 444 server1.example.com and server2.example.com can share cookies and 445 either can be referenced automatically (e.g., by including an image) 446 by the other without being considered an unverifiable transaction, 447 while requests to server3.example2.com would be considered an 448 unverifiable transaction. However, as with the normal domain 449 matching rule for cookies, this rule opens up some holes. If the 450 host example.co.uk requests a resource from server4.example3.co.uk, 451 the request to example3.co.uk server would not be considered an 452 unverifiable transaction, because example.co.uk's reach is co.uk, 453 which domain matches server4.example3.co.uk, a conclusion that is 454 obviously, to a human with some knowledge of the .uk domain 455 structure, incorrect. 457 To avoid such misclassifications, clients SHOULD apply the procedure 458 specified in 3.1 for the reach domain used to decide if a request is 459 an unverifiable, and, if the reach domain is a Public Suffix, the 460 reach of the original host must be changed to become the same as the 461 name of the host itself. Requests that do not domain match the 462 original host's name must be considered unverifiable transactions. 463 That is, the reach for example.co.uk becomes example.co.uk, not 464 co.uk, and example3.co.uk will therefore not domain match the 465 resulting reach. 467 5. Examples 469 The following examples demonstrate how the TLD Subdomain Structure 470 Protocol can be used to decide cookie domain permissions. 472 5.1. Example 1 473 474 475 476 478 This specification means that all names at the top level are Public 479 Suffix domains, except "example.tld" for which cookies are allowed. 480 Cookies are also implicitly allowed for any y.x.tld domains. 482 5.2. Example 2 483 484 485 486 487 489 This specification means that example1.tld and example2.tld and any 490 domains (foo.example1.tld and bar.example2.tld) are Public Suffix 491 domains for which cookies are not allowed; for any other domains 492 cookies are allowed. 494 5.3. Example 3 495 496 497 498 499 500 501 503 This example has the same meaning as Example 2, but with the 504 exception that the domain example3.example2.tld is a regular domain 505 for which cookies are allowed. 507 6. IANA Considerations 509 This specification also requires that responses are served with a 510 specific media type. Below is the registration information for this 511 media type. 513 6.1. Registration of the application/subdomain-structure Media Type 515 Type name : application 517 Subtype name: subdomain-structure 519 Required parameters: none 521 Optional parameters: none 523 Encoding considerations: The content of this media type is always 524 transmitted in binary form. 526 Security considerations: See Section 7. 528 Interoperability considerations: none 530 Published specification: This document 532 Additional information: 534 Magic number(s): none 536 File extension(s): 538 Macintosh file type code(s): 540 Person & email address to contact for further information: Yngve N. 541 Pettersen 543 Email: yngve@opera.com 545 Intended usage: common 547 Restrictions on usage: none 549 Author/Change controller: Yngve N. Pettersen 551 Email: yngve@opera.com 553 7. Security Considerations 555 Retrieval of the specifications is vulnerable to denial of service 556 attacks or loss of network connection. Hosting the specifications at 557 a single location can increase this vulnerability, although the 558 exposure can be reduced by using mirrors with the same name but 559 hosted at different network locations. This protocol is as 560 vulnerable to DNS security problems as any other [RFC2616] HTTP-based 561 service. Requiring the specifications to be digitally signed or 562 transmitted over a authenticated TLS connection reduces this 563 vulnerability. 565 Section 3 of this document describe using the domain list defined in 566 Section 2 as a method of increasing security. The effectiveness of 567 the domain list for this purpose, and the resulting security for the 568 client, depend both on the integrity of the list, and its 569 correctness. The integrity of the list depends on how securely it is 570 stored at the server, and how securely it is transmitted. This 571 specification recommends downloading the domain list using HTTP over 572 TLS, which makes the transmission as secure as the message 573 authentication mechanism used (encryption is not required), and the 574 servers should be configured to use the strongest available key 575 lengths and authentication mechanisms. An alternative approach would 576 be to digitally sign the files. 578 The correctness of the list depends on how well the TLD registry 579 defined it. A list that does not include some Public Suffixes may 580 expose the client to potential privacy and security problems, but not 581 any worse than the situation would be without this protocol and 582 profile, while a subdomain incorrectly classified as a Public Suffix 583 can lead to denial of service for the affected services. Both of the 584 problems can be prevented by careful construction and auditing of the 585 lists, both by the TLD registry and by interested third parties. 587 8. Acknowledgments 589 Anne van Kesteren assisted with defining the XML format in 590 Section 3.1.1. 592 The Public Suffix List project was initiated by members of the 593 Mozilla Community. 595 9. References 597 9.1. Normative References 599 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 600 STD 13, RFC 1034, November 1987. 602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 603 Requirement Levels", BCP 14, RFC 2119, March 1997. 605 [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and 606 L. Repka, "S/MIME Version 2 Message Specification", 607 RFC 2311, March 1998. 609 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 610 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 611 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 613 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 615 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 616 Language) XML-Signature Syntax and Processing", RFC 3275, 617 March 2002. 619 [RFC5891] Klensin, J., "Internationalized Domain Names in 620 Applications (IDNA): Protocol", RFC 5891, August 2010. 622 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 623 April 2011. 625 9.2. Non-normative references 627 [DNSCOOKIE] 628 Pettersen, Y., "Enhanced validation of domains for HTTP 629 State Management Cookies using DNS. Work in progress.", 630 November 2008, 631 . 633 [NETSC] "Persistent Client State HTTP Cookies", . 637 [PUBSUFFIX] 638 "The Homepage of the Public Suffix List, a list of 639 registry-like domains gathered by volunteers.", 640 . 642 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 643 Mechanism", RFC 2965, October 2000. 645 Appendix A. Collection of information for the TLD structure 646 specification 648 This document does not define how the information encoded in the TLD 649 Structure Specification is gathered. 651 There are several methods available for collecting the information 652 encoded in the TLD Structure Specification, the two main ones being: 654 Data provided by the TLD registry owner through a machine readable 655 repository at well known locations 657 Data gathered by one or more application vendors based on publicly 658 available information, such as the Mozilla Project's Public Suffix 659 [PUBSUFFIX] List 661 Appendix B. Alternative solutions 663 A possible alternative to the format specified in Section 3, encoding 664 the information directly in the DNS records for the Public Suffix 665 domain, using a DNS extension. 667 Accessing this type of information requires that the client or its 668 environment is able to directly access the DNS network. In many 669 environments, e.g., firewalled systems, this may not be possible. 670 Also, not all runtime environments can provide this information, 671 which may lead to a DNS client embedded directly in the client. 673 For some applications, it may be necessary, due to system 674 limitations, to access this information through an online web service 675 in order to provide the necessary information for each hostname or 676 domain visited. A web service may, however, introduce unnecessary 677 privacy problems, as well as delays each time a new domain is tested. 679 Appendix C. Open issues 681 o Download location URI for the original domain lists 683 o Should Digital signatures be used on the files, instead of using 684 TLS? 686 Author's Address 688 Yngve N. Pettersen 689 Opera Software ASA 690 Waldemar Thranes gate 98 691 N-0175 OSLO, 692 Norway 694 Email: yngve@opera.com