HTTP Working Group Daniel Jaye INTERNET DRAFT Engage Technologies May 14, 1997 Expires November 14, 1997 HTTP Trust Mechanism for State Management (Rev 1) Status of this Memo 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This is author's draft 1.03. ABSTRACT HTTP TRUST MECHANISM PROPOSAL FOR STATE MANAGEMENT March 30, 1997 1. ABSTRACT This document specifies an addition to the state management protocol specified in RFC 2109. The intent is to provide a mechanism that allows user agents to determine the trust and privacy policies of a server and to accept or reject cookies based on that policy. Allowing the user to decide whether to accept cookies based on the server's policies and trust level provides control over privacy. To provide such information about server privacy behavior, we assume the existence of an independent Trust Authority (or authorities), such as eTrust. The authority establishes levels of "trust" and can audit domains to determine their adherence to a given level. It then issues TrustLabels, in the form of signed PICS labels, to domains based on the trust level. Passing those TrustLabels along with cookies allows the user-agent to support cookie acceptance rules based on trust level. Jaye draft-ietf-jaye-trust-state-00.txt [Page 1] INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) March 19, 1997 This document describes a new header, Set-PICS-Cookie, that extends the Set-Cookie2 header in RFC2109[Kristol] to allow PICS labels that certify trust levels of domains (which we will call TrustLabels) to be sent along with cookies. 2. TERMINOLOGY The terms user agent, client, server, origin server, FQHN, FQDN, request host, request-URI and proxy are used as in RFC 2109. The terms domain- match, verifiable transaction and unverifiable transaction are defined in RFC2109, and those definitions are also used here. The term TrustLabel is used to mean a PICS label[PICS]. The term Trust Authority represents the authority who established the valid PICS label values and assigns digitally signed TrustLabels to domains. 3. OUTLINE The server sends a TrustLabel attached to a Set-PICS-Cookie header to the user agent. The user agent may use the well-known public key of the TrustLabel authority to decrypt the signature of the TrustLabel to verify the identity and trust level of the server. The user agent may then use that information to guide the acceptance or rejection of the cookie. 3.1 Syntax: General In the syntax below, a * following an item indicates it appears 0 or more times, a + indicates 1 or more times. Quotes mean the text within the quotes appears in the header as shown. The syntax of the state management header, Set-Cookie2, is specified in RFC2109[Kristol]. This specification describes a new header, Set-PICS-Cookie, that extends the Set-Cookie2 syntax to include a a TrustLabel after the list of recognized attribute-value pairs. The new Set-PICS-Cookie header syntax is specified below: set-cookie = "Set-PICS-Cookie:" cookies cookies = 1#cookie cookie = NAME "=" VALUE *(";" cookie-av) [labellist] The tokens 'NAME', 'VALUE', "port-list", and "DIGIT" are defined as in RFC 2109. "labellist" is as specified in the PICS label syntax in [PICS], except that some options are not used and we require some of the optional elements, as specified below. We indicate here the parts of the PICS label syntax we use, with the changes to indicate required options. We eliminate those parts not used here. We allow only options on the labels themselves, not the document, since these are Trust-Labels. labellist = "(" version service-info+ ")" version = "PICS-1.1" service-info = serviceID "label" label* Jaye draft-ietf-jaye-trust-state-00.txt [Page 2] INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) March 19, 1997 serviceID = quotedURL label = single-label single-label = labelattr "ratings" "(" cookierating+ ")" labelattr = "by" quotedname "gen" boolean "for" quotedURL "on" quoted-ISO-date "signature-RSA-MD5" base64-string "exp" quoted-ISO-date cookierating = "anonymous 1" | "no-share 1" | "third-party exchange 1" | rating Three well-known cookierating values are described here to provide recognized values to be implemented by recommended user agent behavior. They are correspond to the TrustMark standard proposed by Etrust (see www.etrust.com). The "anonymous 1" rating indicates that the trust authority has verified that the server will not associate the value of the cookie or derived information (e.g., clickstream information) with the user's identity (e.g., name, address, email address, or other identifying information). The "no-share 1" rating indicates that the value of the cookie or derived information may be associated with identifying information but will only be used by the organization issuing the cookie and will not be shared with third parties (e.g., mailing lists, etc.). The "third-party exchange 1" rating indicates that value of the cookie or derived information may be associated with identifying information and may be shared with third parties. This syntax allows for other ratings to be described and recognized according to the PICS specification[PICS]. "rating", "quoted name", "quotedURL", "base64-string", and "quoted-ISO-date" are as defined in the PICS spec [PICS]. The clauses in it are options in the PICS spec, but all are required here. "by" is the name of the issuing trust authority. "gen" indicates whether the label is for only the URL in the "for", or for all URL's for which the specified one is a prefix. ("True" indicates subdomains included). "on" is the date the label was issued. "exp" is the date the label expires. "signature-RSA-MD5" is the signature derived by computing the MD5 message digest of the label, and encrypting it with the trust authority's private key. It is then converted to US-ASCII. The message digest is computed on the cannonical form of the label, as specified in the PICS label spec [PICS] All other items above are as described in the PICS document [PICS]. 3.2 Server Role Any server wishing to provide TrustLabels must request such labels from a Trust Authority. The Trust Authority here must have the ability to evaluate the server domain and determine the trust level for which a label will be issued. That evaluation takes place outside the protocol described here, as does the actual granting of the labels to the origin server. The labels should expire no more than twelve months and no less than one month after they are issued. The server should store the TrustLabels and Jaye draft-ietf-jaye-trust-state-00.txt [Page 3] INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) March 19, 1997 only request a new TrustLabel from the Trust Authority when the current TrustLabel is about to expire The origin server initiates a session, if it so desires, by returning the header Set-PICS-Cookie to the client. It includes in this header the TrustLabels the server has been issued by various trust authorities. The origin server receives cookies from a user-agent in a cookie request header. This proposal does not modify the cookie request header definition. The server may choose to use or ignore cookies supplied in such request headers. Upon receipt of such a cookie, it can return the same or a different cookie in the response, or no cookie at all. The origin server may terminate a session by sending a Set-PICS-Cookie header with MAX-AGE = 0. 3.3 User Agent Role The user agent receives cookies and TrustLabels from an origin server in the Set-PICS-Cookie header. 3.3.1 Interpreting Set-PICS-Cookie User agents interpret cookies as described in RFC 2109. In addition to the cookie attributes, the user agent must now interpret the TrustLabels as well. If the user agent cannot interpret trust labels, they can be ignored. To ensure that the TrustLabel is valid, the user agent first computes the MD5digest on the label, then decrypts the TrustLabel's signature using the Trust Authority's public key. The user agent obtains that public key outside this protocol. Given that we expect a few well-known Trust Authorities, the user agent implementor should store public keys from standard trust authorities to avoid extra round trips. The user agent verifies that at least one TrustLabel in the header satisfies the following criteria: 1) that the URL specified in the "for" label attribute of the TrustLabel domain-matches the path of the cookie. If the TrustLabel is specified as generic, then the "for" URL must be a prefix of the cookie's path. If the TrustLabel is not generic, then it must match exactly. 2) that the "on" date of the label is less than the current date 3) that the "exp" date is greater than the current date If the user agent is set to accept all cookies then all TrustLabel processing can be skipped. 3.3.2 Accepting or rejecting Cookies A user or a user-designated agent should be able to determine the policy for accepting or rejecting cookies based on whether the cookie is issued by a verifiable or unverifiable transaction and the TrustLabel. The default should be that "anonymous 1" or "no-share 1" cookies are accepted from verifiable transactions and that "anonymous 1" cookies are accepted from unverifiable transactions." Jaye draft-ietf-jaye-trust-state-00.txt [Page 4] INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) March 19, 1997 3.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 TrustLabels occurs outside the scope of this protocol, but the protocol depends on user trust in that authority. The Trust Authority must understand the scope in which a TrustLabel applies and the related domain-matching rules, to ensure that for all situations in which the TrustLabel would be deemed to be applicable, the server(s) are in fact operating at the specified trust level rating. 3.4.1 Issuing TrustLabels On receiving a TrustLabel request, the authority should verify the trust rating of the site requesting the TrustLabel and issue the appropriate TrustLabel. To issue the TrustLabel, the authority hashes the labellist provided by the requester, encrypts that hash value with its private key and includes the resulting value as the "signature-RSA-MD5" attribute in the TrustLabel it issues. 3.4.2 Revocation of TrustLabels TrustLabels must have expiration dates. When a TrustLabel is issued, the Trust Authority must receive agreement from the requesting organization that the policies for which the TrustLabel was assigned will be maintained until the TrustLabel expires or the domain becomes inactive. 3.4.3 Discovery of Trust levels Trust levels are well known values established by each Trust Authority. Rules regarding handling of Trust Authority levels are established by the user agent. 4. EXAMPLES 4.1 Example 1 1. User Agent policies: In this example, the user agent has a policy of automatically accepting cookies from domains that are have valid ratings of "anonymous 1" or "no_share 1" by trust authority www.aaa.org. 2. User Agent -> Server POST /acme/login HTTP/1.1 Host: acme.com [form data] User identifies self via a form. 3. Server -> User Agent HTTP/1.1 200 OK Set-PICS-Cookie: Customer="WILE_E_COYOTE"; Max-Age = 94608000; Jaye draft-ietf-jaye-trust-state-00.txt [Page 5] INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) March 19, 1997 Version="1"; Path="/acme" (PICS-1.1 "http://www.aaa.org" label by "aaa trust authority" gen true for "http://www.acme.com/" on "1995.10.15T13:29-0000" signature-RSA-MD5 E53G19D35A7B2158E53G19D35A7B2158E53G19D35A7B2158 exp "1995.12.31T23:59-0000" ratings (no_share 1)) Cookie reflects users identity and transmits signed label back to user agent. Cookie is accepted by user agent because rating "no_share" is recognized by the user agent cookie policy. 4.2 Example 2 1. User Agent policies: In this example, the user agent has a policy of automatically accepting cookies from domains that are "anonymous 1" or "no_share 1" by trusted authority www.aaa.org or from unverifiable transactions from domains that are verifiable as "anonymous 1" by www.aaa.org. 2. User Agent -> Server POST /acme/login HTTP/1.1 Host: 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-PICS-Cookie: Customer="0000000123"; Max-Age = 94608000; Version="1"; Path="/birds" (PICS-1.1 "http://www.aaa.org" label by "aaa trust authority" gen true for "http://www.acme.com/birds" on "1995.10.15T13:29-0000" signature-RSA-MD5 3G19D35A7B2158E53G19D35A7B2158E53G19D35A7B2158E5 exp "1995.12.31T23:59-0000" ratings (no_share 1)) Cookie reflects users identity and transmits signed label back to user agent. Cookie is accepted by user agent because rating "no_share" is recognized by the user agent cookie policy. 4. User Agent -> Server GET cgi-bin/maps?TERR=deserts&FEAT=cliffs HTTP/1.1 Host: roadrunnermaps.com User requests image via CGI script 5. Server -> User Agent (unverifiable transaction) HTTP/1.1 200 OK Set-PICS-Cookie: Customer="0000000123"; Max-Age = 94608000; Jaye draft-ietf-jaye-trust-state-00.txt [Page 6] INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) March 19, 1997 Version="1" (PICS-1.1 "http://www.aaa.org" label by "aaa trust authority" gen true for "http://www.roadrunnermaps.com/" on "1995.10.15T13:30-0000" signature-RSA-MD5 9D35A7B2158E53G19D35A7B2158E53G19D35A7B2158E53G1 exp "1995.12.31T23:59-0000" ratings (anonymous 1)) Cookie reflects user's system generated id number and transmits signed label back to user agent. Cookie is accepted by user agent because rating "anonymous" is recognized by the user agent cookie policy for unverifiable transactions. 5. SECURITY CONSIDERATIONS 5.1 Revocation of TrustLabels A site could receive a TrustLabel for a particular trust level rating and later change its policies before the TrustLabel has expired. To address this need, Trust Authorities should execute agreements with TrustLabel recipients to provide legal remedies to discourage this behavior. 6. SUMMARY This document presents an extension to the state management protocol defined in RFC2109. It describes only changes to that protocol. Any parts of the state management not explicitly described here are assumed to remain as defined in RFC 2109. The protocol described here allows a user agent to verify that the origin server is using cookies in a manner consistent with the privacy expectations of the user, by providing a certificate. or TrustLabel, issued by a trusted authority. 7. ACKNOWLEDGEMENTS This document represents extensive work by Toby Bloom, as well as input from Dave Kristol, Yaron Goland, Jonathan Stark, and Dan Connolly. 8. REFERENCES [PICS] Jim Miller et al, PICS Label Distribution label Syntax and Communication Protocol, Version 1.1, REC-PICS-labels-961031 http://www.w3.org/pub/WWW/PICS/labels.html [Kristol] Kristol, David M., HTTP State Management Mechanism (rev 1). Internet Draft ftp://ietf.org/internet-drafts/draft-ietf-http-state-man-mec-01.txt Jaye draft-ietf-jaye-trust-state-00.txt [Page 7] INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) March 19, 1997 9. AUTHOR'S ADDRESS Daniel Jaye Engage Technologies 100 Brickstone Square 1st Floor Andover, MA 01810 Phone: (508) 684-3641 FAX: (508) 684-3636 Email: djaye@engagetech.com Jaye draft-ietf-jaye-trust-state-00.txt [Page 8]