HTTP Working Group Eric Brunner INTERNET DRAFT Daniel Jaye Engage July 14, 2000 Expires January 14, 2000 HTTP Trust Mechanism for State Management Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Brunner, Jaye expires January 2001 July 2000 [Page 1] Internet-Draft HTTP Trust State Management July 2000 Abstract This document describes an extension to the HTTP/1.1 state management mechanism described in [Kristol]. This mechanism, "trust-labels", associates digitally signed labels with Set-Cookie or Set-Cookie2 headers. The labels allow additional semantics to attach to cookies and cookie processing, and the digital signatures allow trust models to be associated with processing rules for labeled cookies. The intent is to provide a mechanism that allows user agent implementors to implement evaluation of the authenticity and content of cookie-associated labels, and to implement additional processing rules for cookie handling. The intended use is browser determination of server privacy practices and acceptance, rejection, modification or redirection of cookies based on those practices. The more general use of trust model scoped, label semantic scoped processing of HTTP state artifacts is not precluded by this intended use. Allowing browser users to establish preferences for how to handle cookies based on the server's practices provides a practical mechanism to provide users control over the privacy implications of cookies. To provide verification of server privacy practices, we assume the existence of one or more independent Trust Authorities. The authority establishes P3P ratings representing server privacy practices. It then issues trust-labels, in the form of digitally signed P3P labels, to organizations for specific domains and paths based on the server privacy practices. The Trust Authority must be able to audit domains to verify their adherence to a given level. Passing these trust-labels along with cookies allows the user agent to support cookie handling preferences based on trusted privacy practices. This document describes how signed label headers are used in conjunction with Set-Cookie or Set-Cookie2 headers in [Kristol] to provide trust-labels to communicate the privacy practices of servers regarding cookies. Brunner, Jaye expires January 2001 July 2000 [Page 2] Internet-Draft HTTP Trust State Management July 2000 Table of Contents Status of this Memo ............................................ 1 Copyright Notice ............................................... 1 Abstract ....................................................... 2 Table of Contents .............................................. 3 1. Motivation .................................................. 4 2. Introduction ................................................ 5 3. Terminology ................................................. 6 4. Requirements ................................................ 7 5. Specification ............................................... 8 6. Examples .................................................... 14 7. IANA Considerations ......................................... 17 8. Internationalization Considerations ......................... 17 9. Security Considerations ..................................... 17 Acknowledgments ................................................ 18 References ..................................................... 18 Authors' Addresses ............................................. 20 Appendix A ..................................................... 21 Full Copyright Statement ....................................... 22 Brunner, Jaye expires January 2001 July 2000 [Page 3] Internet-Draft HTTP Trust State Management July 2000 1. Motivation Section 15.1 of the HTTP/1.1 Specification [RFC 2616] restates the issue of HTTP client access to personal information previously stated variously and in part in the HTTP/1.0 Specification [RFC 1945]. 15.1 Personal Information HTTP clients are often privy to large amounts of personal information (e.g. the user's name, location, mail address, passwords, encryption keys, etc.), and SHOULD be very careful to prevent unintentional leakage of this information via the HTTP protocol to other sources. The uses to which the HTTP protocol has been put have evolved considerably over the years. In the four years since HTTP/1.0 was published, commercial use has become the dominant modality of use of the web. This has brought increasing sophistication to the practice of user profiling, the advent of state techniques [Levine] and cookies [Netscape] and an increased sophistication with and concern regarding privacy and data protection. In the year since HTTP/1.1 was published the practice of depositing persistent third-party cookies arising out of unverifiable transactions in client store has become common. A transaction is verifiable if the user, or a user-designated agent, has the option to review the request-URI prior to its use in the transaction. A transaction is unverifiable if the user does not have that option. Unverifiable transactions typically arise when a user agent automatically requests inlined or embedded entities or when it resolves redirection (3xx) responses from an origin server. Typically the origin transaction, the transaction that the user initiates, is verifiable, and that transaction may directly or indirectly induce the user agent to make unverifiable transactions. [Kristol] defines third-party transactions using the DNS (see "domain-match"). Alternate characterizations of third-parties are possible, e.g., those which use end-point or aggregation identifiers other than domain names, or those which use mechanisms other than domain name string match rules. For the purposes of this draft, third-parties are ad networks. Section 15.1 of the HTTP/1.1 Spec continues with guidance to client implementors: Brunner, Jaye expires January 2001 July 2000 [Page 4] Internet-Draft HTTP Trust State Management July 2000 We very strongly recommend that a convenient interface be provided for the user to control dissemination of such information, and that designers and implementors be particularly careful in this area. A mechanism which allows http client management of data disclosure to http servers and proxies, and which allows the http client manager granularity of access to the HTTP state management mechanism, and which is extensible is the motivation for this draft. The general form of this mechanism is the separation of labelled data in conjunction with information flow data protection policies [Bell- LaPadula]. The approach taken here differs from that taken in [P3P] (see Requirements, particularly round-trip analysis and authentication), though the Harmonized Vocabulary of P3P is adopted. 2. Introduction << Comments are in angle brackets like this. Note that since this is effectively a substantive revision of this protocol, many changes are to be expected, possibly including significant re-design based on PKIX WG review. The transition from W3C PICS and reconcilliation with W3C P3P (and possibly W3C PICS/RDF) is incomplete. >> The Hypertext Transfer Protocol (HTTP) is a stateless protocol for which the abstractions of "session" and "stateful session" are underspecified. There have been several approaches to the problem of constructing meaningful state, hence stateful sessions, the prevalent one is that an origin server sends state information to the user agent, and the user agent stores and returns the state information to the origin server. These constructs are HTTP cookies. The purpose of HTTP State Management is to allow an HTTP-based service to create stateful sessions which persist across multiple HTTP transactions, multiple server hosts, and possibly multiple client-side hosts. 2.1 This Document This document is an informational Internet draft that specifies the trust-label extension to the HTTP State Management Mechanism. It also provides advice to trust-label implementors about some of the issues discussed at length during trust-label development, in hopes Brunner, Jaye expires January 2001 July 2000 [Page 5] Internet-Draft HTTP Trust State Management July 2000 of making it easier to build implementations that will actually interoperate. The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC 2119]. 2.2 Changes Since Last Version Substantial rewrite, updated references to current drafts, added co- author. Updated references to W3C P3P vocabulary, deleted dependency on W3C PICS. 2.3 To Do Add in section(s) to talk about Mozilla/Amaya implementation issues. Rewrite trust models section (reconcile with PKIX Roadmap). Round-trip analysis, trust-labels vs P3P. Please send comments on this document to: cookie-cutters@world.std.com 3. Terminology The terms domain-match, verifiable transaction, and unverifiable transaction are defined in [Kristol], and those definitions are also used here. The terms user agent, client, server, proxy, and origin server have the same meaning as in the HTTP/1.1 specification [RFC 2616]. (Generally, any term defined in the HTTP/1.1 specification has the same meaning here unless explicitly noted otherwise.) The terms certificate, certificate authority (CA), certificate policy (CP), certificate, and other public key infrastructure terms have the same meaning as in [PKIX-ROADMAP]. Generally, any term defined in the PKIX Roadmap has the same meaning here unless explicitly noted otherwise. The Set-Cookie and Set-Cookie2 headers are defined in [Kristol] (which extends those definitions from those of [RFC 2109]), and those definitions are also used here. Brunner, Jaye expires January 2001 July 2000 [Page 6] Internet-Draft HTTP Trust State Management July 2000 The term label is used here is a special case of information labels defined in [RFC 2104], and allows information flow control models, e.g., the Bell-LaPadula model, applied to HTTP cookies. Note: The label vocabulary is the harmonized vocabulary defined in [P3P1.0] ("privacy"), rather than [DoD85, DoD87] ("security"), both describing social attributes of protected data and data protection practices. The specific application of the trust-label mechanism is the provision of state flow confidentiality. A digitally signed label associated with Set-Cookie or Set-Cookie2 headers [Kristol] is a ``trust-label''. 4. Requirements The following requirements have been identified as important in the meeting of the needs of extending HTTP State Management mechanism to provide privacy and data protection: + ease of deployment to HTTP State Management participants, Comment: this is an issue with URI namespace-based policy models. Only third party service providers with legitimate need for persistent cookies and user agent implementors must comply. + ease of integration with existing CA infrastructure, + extensible label vocabularies, + extensible digital signature mechanisms, + good scaling properties as transaction complexity increases (minimal round-trip overhead), Comment: this is an issue with URI namespace-based policy models. A URI may reference additional embedded objects, not all of which attempt to participate in HTTP State Management. + simple, extensible label syntax. + sufficient to support one or more convenient user interfaces to control dissemination of personally identifying information, + sufficient to allow HTTP participant designers and implementors to be particularly careful in the area of personally identifying information disclosure (cryptographic authentication). Brunner, Jaye expires January 2001 July 2000 [Page 7] Internet-Draft HTTP Trust State Management July 2000 5. Specification An HTTP origin server sends a Set-Cookie and/or a Set-Cookie2 header to a user agent along with a P3P-Label header containing the trust- label. The user agent may then use that information to guide the acceptance or rejection of the cookie. If the trust-label has a digital signature, the user agent may use the well-known public key of the Trust Authority to decrypt the signature of the trust-label to verify the identity and practices of the server and scope of the trust-label. 5.1 P3P-Label Syntax This specification describes how the Purpose and Recipient Element vocabularies, described in [P3P], are used to convey the privacy practices of the server to the user-agent. An alternative vocabularies (AV) may be used to construct an alternative vocabulary label (AV-Label) headers. The new P3P-Label header syntax is specified below: trust-label = "P3P-Label:" labellist The header is recognized as a trust-label by the existence of the cookieinfo extension. << The PICS-epoch cookieinfo-1.0.html draft needs to be revised and moved from the (obsoleted) w3.org/PICS URL to the (current) w3.org/P3P URL. All cookieinfo references dangle until then. The PICS/RDF (modern) draft is an alternative, modulo the complications of harmonizing with RDF (schema and namespace). >> This trust-label applies to cookies in the response that are compatible (as described in section x.x.x) with the domain and path of the "for" labelattr of the P3P-Label header. The specific cookies are listed in the cookieinfo extension to the P3P label or to all compatible cookies if no cookies listed in the cookieinfo extension. "labellist" is specified Appendix A, taken from the original PICS-1.1 label syntax in [PICS], modified as follows: + an extension to include a list of the specific cookies to to which the trust-label applies; + an optional extension according to the digital signatures working draft [DSIG]; + the optional label attributes "by" "gen" "for" "on" and "exp" are required. Brunner, Jaye expires January 2001 July 2000 [Page 8] Internet-Draft HTTP Trust State Management July 2000 The P3P label syntax (modified from the syntax in Appendix A) is listed here. labellist = "(" "P3P-1.0" service-info ")" service-info = serviceID "label" 1*label serviceID = "http://www.w3.org/P3P/tbd" | quotedURL label = labelattr "ratings" "(" privacypractice ")" cookieinfo [sigblock] labelattr = ["by" quotedname] "gen" boolean "for" quotedURL "on" quoted-ISO8601-date "exp" quoted-ISO8601-date privacypractice = "purpose" 1*purposerating "recipient" recptrating "identifiable" piirating cookieinfo = "extension" "(" "mandatory" <"> "http://www.w3.org/P3P/tbd" <"> *cookiename ")" cookiename = NAME purposerating = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" recptrating = "0" | "1" | "2" | "3" | "4" | "5" piirating = "0" | "1" <<"quotedname", "quotedURL", and "rating" were defined in [PICS] and a revised definition must be made.>> "quoted-ISO8601-date" is defined in [ISO 8601]. ServiceID references a quoted URL that defines the rating service and rating system. The well-known rating service proposed here is the privacy rating system [harmonized vocabulary] developed by the Platform for Privacy Project (P3P) at the World-Wide Web Consortium (W3C). "for" is the URL or root URL for which this label applies. "by" is the email address of the issuing trust authority. The "gen" boolean indicates whether the label is generic to the web site or for a specific page. A value of "True" indicates that the label is generic for all cookies with a Path attribute for which the path component of the URL in the "for" attribute is a prefix. "on" is the date the label was issued. "exp" is the date the label expires. "mandatory" in cookieinfo causes legacy browsers to ignore the label. cookiename is the "NAME" of each cookie to which this label applies. sigblock is the digital signature extension as described in the digital signature working draft [DSIG]. The sigblock must contain the SigCrypto token within the SigData block. The SigCrypto token Brunner, Jaye expires January 2001 July 2000 [Page 9] Internet-Draft HTTP Trust State Management July 2000 must contain the encrypted trust-label-data described below. trust-label-data = labelattr-data privacy-practice [cookielist] labelattr-data = gen-boolean for-URL exp-date gen-boolean = boolean for-URL = quotedURL exp-date = quoted-ISO-date "gen-boolean", "for-URL", and "exp-date" refer to the values of the "gen", "for", and "exp" attributes in the "labelattr" section. "cookielist" refers to the list of cookie names in the cookieblock extension. Three well-known privacy-practice categories are described here to provide recognized behavior that should be handled by user agents. Two of these categories are taken from the rating service developed by the Platform for Privacy Project (P3P) at the World-Wide Web Consortium (W3C). The third is an extension to P3P version 1.0, which appeared in a prior draft of the P3P Specification. 5.1.1 Purpose The purpose rating specifies the purpose for data processing (data practices) relevant to the Web. See http://www.w3.org/TR/2000/WD-P3P-20000510/#PURPOSE "Completion and Support of Current Activity" value = 0 "Web Site and System Administration" value = 1 "Research & Development" value = 2 "Affirmative Customization" value = 3 "One-time Tailoring" value = 4 "Pseudononymous Profiling" value = 5 "Individual Profiling" value = 6 "Contacting Visitors for Marketing of Services or Products" value = 7 "Other Uses" value = 8 5.1.2 Recipient The recipient rating specifies the legal entity, or domain, beyond the service provider and its agents where data may be distributed. (Note: formerly "domainofuse"). See http://www.w3.org/TR/2000/WD-P3P-20000510/#RECPNT "Only by ourselves and agents" value = 0 "Delivery services possibly following different practices" Brunner, Jaye expires January 2001 July 2000 [Page 10] Internet-Draft HTTP Trust State Management July 2000 value = 1 "Legal entities following our practices" value = 2 "Legal entities following different practices" value = 3 "Unrelated third parties" value = 4 "Public" value = 5 5.1.3 Personally Identifiable Information The Identifiable rating specifies whether the information gathered is in identifiable form, is associated with identifiable information, or used to derive personal identity. "non-identifiable" value = 0 "identifiable" value = 1 5.2 Server Role A server communicates its privacy practices by sending an unsigned or signed trust-label in the same response as the cookie header(s). Any server wishing to provide a digitally signed trust-label must request the label from a Trust Authority. The Trust Authority must have the ability to evaluate the server and determine the trust rating for which a label will be issued. That evaluation takes place outside the protocol described here, as does the actual granting of the label to the origin server. The labels should expire no more than thirteen months and no less than one month after they are issued. The server should store the trust labels and only request a new trust-label from the Trust Authority when the current trust-label is about to expire. 5.3 User Agent Role The user agent receives a cookie headers and trust-labels from an origin server. 5.3.1 Interpreting the Trust-Label User agents interpret cookies as consistent with RFC 2109 and [Kristol]. In addition to the cookie attributes, the user agent must now interpret the trust-labels as well. If the user agent receives a P3P label with a serviceID from a recognized label service for trust- labels, it is assumed to be a trust-label for all "compatible" cookies, as defined below. A trust-label and a cookie are defined as "compatible" if the following conditions are met: Brunner, Jaye expires January 2001 July 2000 [Page 11] Internet-Draft HTTP Trust State Management July 2000 + The domain portion of the URL specified in the "for" attribute of labelattr domain-matches the Domain attribute of the cookie response header, according to the matching rules in [Kristol]. + The path portion of the URL specified in the "for" attribute of labelattr is either a), a prefix of the Path attribute of the cookie if the trust-label is generic or, b), an exact match with the Path attribute of the cookie if the trust-label is not generic. If the cookieinfo extension does not contain any cookie names, then the trust-label applies to all cookies in the response that are compatible. A trust-label is ignored if the "exp-date" attribute of labelattr is less than or equal to the current date. To help verify the trustworthiness of the server, the user agent may look for a digital signature and use the Trust Authority's well known public key to decrypt the trust-label-data from the SigCrypto term. The user agent obtains that public key outside this protocol. Given that we expect only a few well-known Trust Authorities, the user agent implementor should cache public keys from standard trust authorities to avoid extra network traffic. The labelattr-data, privacy-practice, and cookielist in the decrypted trust-label-data from the sigblock must match the plaintext labelattr, privacy-practice, and cookielist for the signature to be valid. If the digital signature is invalid, then the trust-label should be ignored and the cookie should not be set. If the user agent is set to accept all cookies then all trust-label processing can be skipped. 5.3.2 Accepting or Rejecting Cookies In addition to the rules for rejecting cookies specified in [Kristol], a user or a user-designated agent should be able to designate preferences for accepting or rejecting cookies based on the privacy-practice of the server, whether the transaction is verifiable or unverifiable, and whether the privacy-practice is signed by a recognized Trust Authority. For example, a user may have a preference to accept all cookies from verifiable transactions or with a piirating 0 and signed by a Brunner, Jaye expires January 2001 July 2000 [Page 12] Internet-Draft HTTP Trust State Management July 2000 recognized Trust Authority. Defaults: User agents may accept without prompting cookies from verifiable transactions without trust-labels to provide backwards compatibility for the large number of existing applications with requirements for persistent first party cookies. User agents should accept without prompting the user cookies from verifiable transactions with purposerating 0 through 6 and recptrating 0. User agents should accept without prompting the user cookies from unverifiable transactions with digitally signed trust-labels issued by a recognized Trust Authority with purposerating 0 through 5, recptrating 0, and piirating 0. User agents should prompt the user for cookies from all other unverifiable transactions including cookies without digitally signed trust-labels from recognized Trust Authorities. 5.3.3 User Intervention The user agent may prompt the user to verify that it wishes to reject a cookie in conditions where the cookie is being rejected based on a default preference or no preference applies. User agents that solicit user input for cookie handling may wish to display the URL of the rating service to better inform the user of the meaning of the privacy ratings for the server. Placeholder: Caution generally and specific to defaults. 5.3.4 Cookie Request Header Syntax The syntax for the Cookie request header has not been modified. 5.4 Trust Authority Role The Trust Authority referred to in this document must be a neutral third party that can be trusted to accurately characterize the privacy behavior of web sites. The issuing of trust-labels occurs outside the scope of this protocol. However, the protocol depends on user trust in the Trust Authority. The Trust Authority must understand the scope to which a trust-label applies to ensure that for all situations in which the trust-label would be deemed to be applicable, the server(s) are in fact operating in accordance with Brunner, Jaye expires January 2001 July 2000 [Page 13] Internet-Draft HTTP Trust State Management July 2000 the specified privacy rating. 5.4.1 Issuing Trust-Labels On receiving a request for a signed trust-label, the authority should verify the privacy practices of the site requesting the trust-label and issue the appropriate trust-label. To issue the trust-label, the Trust Authority assembles the trust-label-data, it canonicalizes whitespace for the trust-label-data, and it encrypts the trust-label- data for the site request using its private key and the algorithm specified in the attribution of the digital signature. The encryption method must be a public-private key pair with a well-known public key to eliminate round-trips to the Trust Authority. 5.4.2 Revocation of Trust-Labels Trust-labels must have expiration dates. When a trust-label is issued, the Trust Authority must receive agreement from the requesting organization that the privacy practices for which the trust-label was assigned will be maintained until the trust-label expires, the domain becomes inactive, or those cookies are no longer set or examined by the organization's servers. 5.4.3 Discovery of Privacy-Practice Ratings Privacy-practice ratings are defined in the P3P label rating system referenced by the Trust Authority's label rating service. The well- known rating service, http://www.w3.org/TR/2000/WD-P3P-20000510 is referenced in this document. 6. Examples Two examples are presented. The first shows the case where the labeled cookie asserts that the recipient of any disclosed data is the origin server of the cookie. The second shows the case where the labeled cookie asserts that the recipient of no personally identifiable data is disclosed, or disclosure via an unverified transaction to a specific class of recipient is permitted if it is signed by a well-known example service provider (the American Automobile Association). 6.1 Example 1 1. User Agent Preferences: In this example, the user agent has a preference for automatically accepting cookies from domains that are recptrating 0. Brunner, Jaye expires January 2001 July 2000 [Page 14] Internet-Draft HTTP Trust State Management July 2000 2. User Agent -> Server POST /acme/login HTTP/1.1 Host: www.acme.com [form data] User identifies self via a form. 3. Server -> User Agent HTTP/1.1 200 OK Set-Cookie2: Customer="WILE_E_COYOTE"; Max-Age = 94608000; Version="1"; Path="/acme" P3P-Label: (P3P-1.0 "http://www.w3.org/P3P/tbd/" label for "http://www.acme.com/" exp "2000.12.31T23:59-0000" extension (mandatory "http://www.w3.org/P3P/tbd") ratings (purpose 0:8 piirating 1 recptrating 0)) 6.2 Example 2 1. User Agent Preferences: In this example, the user agent has a preference for automatically accepting cookies that are rated recptrating 0 or cookies in unverifiable transactions that are piirating 0 and recptrating 0 or recptrating 2 by www.aaa.org. 2. User Agent -> Server POST /acme/login HTTP/1.1 Host: www.acme.com [form data] User requests page with embedded IMG SRC reference to "http://www.roadrunnermaps.com/cgi-bin/maps?TER=deserts&FE=cliffs" 3. Server -> User Agent HTTP/1.1 200 OK Set-Cookie2: Customer="0000000123"; Max-Age = 94608000; Version="1"; Path="/birds" P3P-Label: (P3P-1.0 "http://www.w3.org/P3P/tbd" Brunner, Jaye expires January 2001 July 2000 [Page 15] Internet-Draft HTTP Trust State Management July 2000 label by "auditor@aaa.org" gen true for "http://www.acme.com/" exp "2000.12.31T23:59-0000" extension (mandatory "http://www.w3.org/P3P/tbd") ratings (purpose 0:8 piirating 0 recptrating 0)) A Cookie reflecting the users identity is transmitted with an unsigned trust-label back to the user agent. The Cookie is accepted by the user agent because recptrating 0 is compatible with the user agent's privacy preference. 4. User Agent -> Server GET cgi-bin/maps?TER=deserts&FE=cliffs HTTP/1.1 Host: www.roadrunnermaps.com User requests an image via CGI script from a third party map provider. This is an unverifiable transaction. 5. Server -> User Agent HTTP/1.1 200 OK Set-Cookie2: Customer="0000000123"; Max-Age = 94608000; Version="1" P3P-Label: (P3P-1.0 "http://www.w3.org/P3P/tbd" label by "auditor@aaa.org" gen true for "http://www.roadrunnermaps.com/" exp "2000.12.31T23:59-0000" extension (optional "http://www.w3.org/P3P/tbd" Customer) extension (mandatory "http://www.w3.org/P3P/sig_tbd" ("AttribInfo" ("http://www.w3.org/P3P/sig_tbd/X509.html" "base64-x.509-cert")) ("Signature" "http://www.aaa.org/trust.html" ("byName" "aaapublickey") ("SigCrypto" "8E53B19D35A3F198930E5D815B235A38930E53FDA815B2158"))) ratings (purpose 0:3 piirating 0 recptrating 1)) Brunner, Jaye expires January 2001 July 2000 [Page 16] Internet-Draft HTTP Trust State Management July 2000 A cookie containing the user's system generated id number is transmitted with a signed label back to user agent. The cookie is accepted by user agent because a cookie with a piirating 0 and recptrating 1 in an unverifiable transaction signed by www.aaa.org" is acceptable to the user agent. 7. IANA Considerations This section is left intentionally blank. 8. Internationalization Considerations Placeholder, reference "IETF Policy on Character Sets and Languages" [RFC 2277] Placeholder, reference "UTF-8, a transformation format of Unicode and ISO 10646" [RFC 2044] Placeholder, reference client localization of the [keyword] attributes-value pairs and cookieinfo extension to the language of the user. Placeholder, reference "Country and Region Codes", [ISO 3166] 9. Security Considerations Since the elements of information which are key to trust-label service (certificates and CRLs) are both digitally signed pieces of information, no additional integrity service is REQUIRED. This mechanism only provides protection against covert HTTP state eavesdropping attacks. It does not provide session privacy, server authentication, protection from active attacks or security issues for network protocols other than HTTP/1.1. 9.1 Revocation A site could receive a trust-label for a particular trust-level rating from a Trust Authority and subsequently change its policies before the trust-label expired. To address this Trust Authorities should execute agreements with trust label recipients to provide legal remedies to discourage this behavior. Placeholder, reference to CRLs. Brunner, Jaye expires January 2001 July 2000 [Page 17] Internet-Draft HTTP Trust State Management July 2000 9.2 False representation A site could state a privacy practice that it either intentionally or unintentionally does not follow. If the trust-label is not signed by a recognized trust authority, there is no independent verification of the site's adherence to its stated privacy practice. However, if the site digitally signs the label, then that represents a legally binding contract on the site to follow the professed privacy practice. In addition, the site may be in violation of consumer fraud statutes in some jurisdictions if they misrepresent their privacy practices. Placeholder, reference to CRLs. << Additional remarks on security consideration will be added to the next revision of this document. The above is from -02 and both are awkward and legalistic.>> Acknowledgements This paper has benefited from the contributions from several sources: the HTTP community, the security community, privacy advocates and data commissioners, and of course, the scrutiny of the IESG. This document reflects prior input from Dave Kristol, Yaron Goland, Joseph Reagle, and Jonathan Stark, and contemporary input from Martin Presler-Marshall and Lorrie Cranor. References [RFC 1945] T. Berners-Lee, R. Fielding, and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May, 1996. RFC 2044] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. [RFC 2109] Kristol, D.M., Montulli, L., "HTTP State Management Mechanism", RFC 2109, February, 1997. [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Brunner, Jaye expires January 2001 July 2000 [Page 18] Internet-Draft HTTP Trust State Management July 2000 Levels", RFC 2119, March 1997. [RFC 2077] H. Alvestrand, "IETF Policy on Character Sets and Languages" RFC 2277, January 1998. [RFC 2616] Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk Nielsen, Larry Masinter, Paul Leach,and Tim Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [ISO 3166] ISO 3166/MA "Country and Region Codes", ISO 3166 January 1996. [P3P1.0] Lorrie Cranor, Mark Langheinrich, Massimo Marchiori, Martin Presler-Marshall, Joseph Reagle, "The Platform for Privacy Preferences 1.0 Specification", work in progress. , 10 May 2000. (To be replaced by the final reference when published.) [Kristol] David Kristol, Lou Montulli, "HTTP State Management Mechanism" Internet-Draft , work in progress. (To be replaced by the RFC name when this memo is published.) [PKIX-ROADMAP] Alfred Arsenault, Sean Turner, "PKIX Roadmap", Internet-Draft , work in progress. (To be replaced by the RFC name when this memo is published.) [DoD85] US National Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD., December 1985. [DoD87] US National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD., 31 July 1987. [Netscape] Netscape Corp., "Persistent Client State -- HTTP Cookies", available at http://www.netscape.com/newsref/std/cookie_spec.html, undated. Brunner, Jaye expires January 2001 July 2000 [Page 19] Internet-Draft HTTP Trust State Management July 2000 [Levine] US Patent and Trademark Office, "Stateless shopping cart for the web", PN/5745681 available at http://www.uspto.gov, 1998 [Bell-LaPadula] Bell, D.E. and LaPadula, L.J. "Secure Computer Systems: Unified Exposition and Multics Interoperation", MTR-2997 Rev. 1, MITRE Corp., Bedford Mass., March 1976. [PICS] Jim Miller et al, "PICS Label Distribution Label Syntax and Communication Protocols, Version 1.1", REC-PICS-labels-961031 available at http://www.w3.org/PICS/labels.html. [DSIG] Philip DesAutels et al, "DSIG 1.0 Signature Labels, Version 1.0", WD-DSIG-label-970605 available at http:/www.w3.org/TR/WD-DSIG- label.html. Authors' Addresses Eric Brunner Engage Technologies 100 Brickstone Square, 2nd Floor Andover, MA 01810 brunner@engage.com 978 684-7796 voice 978 684-3636 fax Daniel Jaye Engage Technologies 100 Brickstone Square, 2nd Floor Andover, MA 01810 djaye@engage.com 978 684-3641 voice 978 684-3636 fax Brunner, Jaye expires January 2001 July 2000 [Page 20] Internet-Draft HTTP Trust State Management July 2000 Appendix A Appendix A: PICS-1.1 Label Syntax The following grammar, in modified BNF, describes the syntax of labels. The methods by which labels are embedded in specific protocols are detailed below. labellist :: '(' version service-info+ ')' version :: 'PICS-1.1' service-info :: 'error' '(no-ratings' explanation* ')' | serviceID service-error | serviceID option* labelword label* serviceID :: quotedURL labelword :: 'labels' | 'l' label :: label-error | single-label | '(' single-label* ')' single-label :: option* ratingword '(' rating+ ')' ratingword :: 'ratings' | 'r' quotedURL :: '"' URL '"' as described and extended in Rating Services and Rating Systems. option :: labeloption | documentoption | otheroption labeloption :: 'by' quotedname | 'generic' boolean | 'gen' boolean | 'for' quotedURL | 'on' quoted-ISO-date | 'signature-RSA-MD5' "base64-string" | 'until' quoted-ISO-date | 'exp' quoted-ISO-date documentoption :: 'at' quoted-ISO-date | 'MIC-md5' "base64-string" | 'md5' "base64-string" otheroption :: 'comment' quotedname | 'complete-label' quotedURL | 'full' quotedURL | 'extension' '(' mand/opt quotedURL data* ')' mand/opt :: 'optional' | 'mandatory' data :: quoted-ISO-date | quotedURL | number | quotedname | '(' data* ')' quoted-ISO-date :: '"'YYYY'.'MM'.'DD'T'hh':'mmStz'"' based on the ISO 8601:1988 date and time standard, restricted to the specific form described here: YYYY :: four-digit year MM :: two-digit month (01=January, etc.) DD :: two-digit day of month (01 through 31) hh :: two digits of hour (00 through 23) (am/pm NOT allowed) mm :: two digits of minute (00 through 60) S :: sign of time zone offset from UTC ('+' or '-') tz :: four digit amount of offset from UTC (e.g., 1512 means 15 hours and 12 minutes) Brunner, Jaye expires January 2001 July 2000 [Page 21] Internet-Draft HTTP Trust State Management July 2000 For example, "1994.11.05T08:15-0500" is a valid quoted-ISO-date denoting November 5, 1994, 8:15 am, US Eastern Standard Time Note: The ISO standard allows considerably greater flexibility than that described here. PICS requires precisely the syntax described here -- neither the time nor the time zone may be omitted, none of the alternate formats are permitted, and the punctuation must be as specified here. rating :: transmit-name number | transmit-name '(' multi-value* ')' multi-value :: number | number ':' number transmit-name :: transmit-name-char+ ['/' transmit-name] number :: [sign]unsignedint['.' [unsignedint]] sign :: '+' | '-' unsignedint :: [0-9]+ quotedname :: '"' urlchar-or-space+ '"' alphanumpm :: 'A' | ... | 'Z' | 'a' | ... | 'z' | '0' | ... | '9' | sign transmit-name-char :: alphanumpm | '.' | '$' | ',' | ';' | ':' | '&' | '=' | '?' | '!' | '*' | '~' | '@' | '#' | '_' | '%' hex hex Note: Use the "%" escape technique (% followed by the two hex digits that represent the character in the ASCII character set) to insert single or double quotation marks or parentheses. urlchar :: transmit-name-char | '(' | ')' hex :: '0' | ... | '9' | 'A' | ... | 'F' | 'a' | ... | 'f' urlchar-or-space :: urlchar | ' ' base64-string :: as defined in RFC-1521. service-error :: 'error' '(' 'request-denied' explanation* ')' | 'error' 'service-unavailable' label-error :: 'error' '(' 'request-denied' [quotedURL explanation*] ')' | 'error' '(' 'not-labeled' quotedURL* ')' explanation :: quotedname Full Copyright Statement Copyright (C) The Internet Society 1999. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process shall be followed, or as required to translate it into languages other than English. Brunner, Jaye expires January 2001 July 2000 [Page 22] Internet-Draft HTTP Trust State Management July 2000 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Brunner, Jaye expires January 2001 July 2000 [Page 23]