2004/id/draft-ietf-http-jaye-trust-state-00.txt



HTTP Working Group                      Daniel Jaye
INTERNET DRAFT                    Engage Technologies


<draft-ietf-http-jaye-trust-state-00.txt>
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 <draft-ietf-http-state-man-mec-01.txt>
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]


1	wakaba	1.1
2
3
4
5			HTTP Working Group Daniel Jaye
6			INTERNET DRAFT Engage Technologies
7
8
9			<draft-ietf-http-jaye-trust-state-00.txt>
10			May 14, 1997 Expires November 14, 1997
11
12
13			HTTP Trust Mechanism for State Management (Rev 1)
14
15
16
17
18			Status of this Memo
19
20			This document is an Internet-Draft. Internet-Drafts are
21			working documents of the Internet Engineering Task Force
22			(IETF), its areas, and its working groups. Note that other
23			groups may also distribute working documents as Internet-
24			Drafts.
25
26			Internet-Drafts are draft documents valid for a maximum of six
27			months and may be updated, replaced, or obsoleted by other
28			documents at any time. It is inappropriate to use Internet-
29			Drafts as reference material or to cite them other than as
30			``work in progress.''
31
32			To learn the current status of any Internet-Draft, please
33			check the ``1id-abstracts.txt'' listing contained in the
34			Internet- Drafts Shadow Directories on ftp.is.co.za (Africa),
35			nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
36			ds.internic.net (US East Coast), or ftp.isi.edu (US West
37			Coast).
38
39			This is author's draft 1.03.
40
41
42			ABSTRACT
43
44			HTTP TRUST MECHANISM PROPOSAL FOR STATE MANAGEMENT
45			March 30, 1997
46
47			1. ABSTRACT
48
49			This document specifies an addition to the state management protocol
50			specified in RFC 2109. The intent is to provide a mechanism that allows
51			user agents to determine the trust and privacy policies of a server and
52			to accept or reject cookies based on that policy. Allowing the user to
53			decide whether to accept cookies based on the server's policies and
54			trust level provides control over privacy.
55
56			To provide such information about server privacy behavior, we assume the
57			existence of an independent Trust Authority (or authorities), such as
58			eTrust. The authority establishes levels of "trust" and can audit
59			domains to determine their adherence to a given level. It then issues
60			TrustLabels, in the form of signed PICS labels, to domains based on the
61			trust level. Passing those TrustLabels along with cookies allows the
62			user-agent to support cookie acceptance rules based on trust level.
63
64
65
66			Jaye draft-ietf-jaye-trust-state-00.txt [Page 1]
67
68
69
70
71
72			INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) March 19, 1997
73
74
75
76			This document describes a new header, Set-PICS-Cookie, that extends the
77			Set-Cookie2 header in RFC2109[Kristol] to allow PICS labels that certify
78			trust levels of domains (which we will call TrustLabels) to be sent along
79			with cookies.
80
81
82			2. TERMINOLOGY
83
84			The terms user agent, client, server, origin server, FQHN, FQDN, request
85			host, request-URI and proxy are used as in RFC 2109. The terms domain-
86			match, verifiable transaction and unverifiable transaction are defined
87			in RFC2109, and those definitions are also used here.
88
89			The term TrustLabel is used to mean a PICS label[PICS]. The term Trust
90			Authority represents the authority who established the valid PICS label
91			values and assigns digitally signed TrustLabels to domains.
92
93
94			3. OUTLINE
95
96			The server sends a TrustLabel attached to a Set-PICS-Cookie header to the
97			user agent. The user agent may use the well-known public key of the
98			TrustLabel authority to decrypt the signature of the TrustLabel to
99			verify the identity and trust level of the server. The user agent may
100			then use that information to guide the acceptance or rejection of the
101			cookie.
102
103			3.1 Syntax: General
104
105			In the syntax below, a * following an item indicates it appears 0 or
106			more times, a + indicates 1 or more times. Quotes mean the text within
107			the quotes appears in the header as shown.
108
109			The syntax of the state management header, Set-Cookie2, is specified in
110			RFC2109[Kristol]. This specification describes a new header,
111			Set-PICS-Cookie, that extends the Set-Cookie2 syntax to include a
112			a TrustLabel after the list of recognized attribute-value pairs.
113			The new Set-PICS-Cookie header syntax is specified below:
114
115			set-cookie = "Set-PICS-Cookie:" cookies
116			cookies = 1#cookie
117			cookie = NAME "=" VALUE *(";" cookie-av) [labellist]
118
119			The tokens 'NAME', 'VALUE', "port-list", and "DIGIT" are defined as in
120			RFC 2109. "labellist" is as specified in the PICS label syntax in
121			[PICS], except that some options are not used and we require some of
122			the optional elements, as specified below.
123
124			We indicate here the parts of the PICS label syntax we use, with the
125			changes to indicate required options. We eliminate those parts not
126			used here. We allow only options on the labels themselves, not the
127			document, since these are Trust-Labels.
128
129			labellist = "(" version service-info+ ")"
130			version = "PICS-1.1"
131			service-info = serviceID "label" label*
132
133
134
135			Jaye draft-ietf-jaye-trust-state-00.txt [Page 2]
136
137
138
139
140
141			INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) March 19, 1997
142
143
144
145			serviceID = quotedURL
146			label = single-label
147			single-label = labelattr "ratings" "(" cookierating+ ")"
148			labelattr = "by" quotedname
149			"gen" boolean
150			"for" quotedURL
151			"on" quoted-ISO-date
152			"signature-RSA-MD5" base64-string
153			"exp" quoted-ISO-date
154			cookierating = "anonymous 1"
155			\| "no-share 1"
156			\| "third-party exchange 1"
157			\| rating
158
159			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).
160			The "anonymous 1" rating indicates that the trust authority has verified
161			that the server will not associate the value of the cookie or derived
162			information (e.g., clickstream information) with the user's identity
163			(e.g., name, address, email address, or other identifying information).
164			The "no-share 1" rating indicates that the value of the cookie or derived
165			information may be associated with identifying information but will
166			only be used by the organization issuing the cookie and will not be
167			shared with third parties (e.g., mailing lists, etc.). The "third-party
168			exchange 1" rating indicates that value of the cookie or derived
169			information may be associated with identifying information and may be
170			shared with third parties. This syntax allows for other ratings to be
171			described and recognized according to the PICS specification[PICS].
172
173			"rating", "quoted name", "quotedURL", "base64-string", and
174			"quoted-ISO-date" are as defined in the PICS spec [PICS]. The clauses
175			in it are options in the PICS spec, but all are required here. "by" is
176			the name of the issuing trust authority. "gen" indicates whether the
177			label is for only the URL in the "for", or for all URL's for which the
178			specified one is a prefix. ("True" indicates subdomains included). "on"
179			is the date the label was issued. "exp" is the date the label expires.
180			"signature-RSA-MD5" is the signature derived by computing the MD5
181			message digest of the label, and encrypting it with the trust
182			authority's private key. It is then converted to US-ASCII. The message
183			digest is computed on the cannonical form of the label, as specified in
184			the PICS label spec [PICS]
185
186			All other items above are as described in the PICS document [PICS].
187
188			3.2 Server Role
189
190			Any server wishing to provide TrustLabels must request such labels from
191			a Trust Authority. The Trust Authority here must have the ability to
192			evaluate the server domain and determine the trust level for which a
193			label will be issued. That evaluation takes place outside the protocol
194			described here, as does the actual granting of the labels to the origin
195			server.
196
197			The labels should expire no more than twelve months and no less than one
198			month after they are issued. The server should store the TrustLabels and
199
200
201
202			Jaye draft-ietf-jaye-trust-state-00.txt [Page 3]
203
204
205
206
207
208			INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) March 19, 1997
209
210
211
212			only request a new TrustLabel from the Trust Authority when the current
213			TrustLabel is about to expire
214
215			The origin server initiates a session, if it so desires, by returning
216			the header Set-PICS-Cookie to the client. It includes in this header the
217			TrustLabels the server has been issued by various trust authorities.
218
219			The origin server receives cookies from a user-agent in a cookie request
220			header. This proposal does not modify the cookie request header
221			definition. The server may choose to use or ignore cookies supplied in
222			such request headers. Upon receipt of such a cookie, it can return the
223			same or a different cookie in the response, or no cookie at all. The
224			origin server may terminate a session by sending a Set-PICS-Cookie header
225			with MAX-AGE = 0.
226
227			3.3 User Agent Role
228
229			The user agent receives cookies and TrustLabels from an origin server
230			in the Set-PICS-Cookie header.
231
232			3.3.1 Interpreting Set-PICS-Cookie
233			User agents interpret cookies as described in RFC 2109. In addition
234			to the cookie attributes, the user agent must now interpret the
235			TrustLabels as well. If the user agent cannot interpret trust labels,
236			they can be ignored. To ensure that the TrustLabel is valid, the user
237			agent first computes the MD5digest on the label, then decrypts the
238			TrustLabel's signature using the Trust Authority's public key.
239
240			The user agent obtains that public key outside this protocol. Given
241			that we expect a few well-known Trust Authorities, the user agent
242			implementor should store public keys from standard trust authorities
243			to avoid extra round trips.
244
245			The user agent verifies that at least one TrustLabel in the header
246			satisfies the following criteria:
247
248			1) that the URL specified in the "for" label attribute of the
249			TrustLabel domain-matches the path of the cookie. If the TrustLabel is
250			specified as generic, then the "for" URL must be a prefix of the
251			cookie's path. If the TrustLabel is not generic, then it must match
252			exactly.
253
254			2) that the "on" date of the label is less than the current date
255
256			3) that the "exp" date is greater than the current date
257
258			If the user agent is set to accept all cookies then all TrustLabel
259			processing can be skipped.
260
261			3.3.2 Accepting or rejecting Cookies
262			A user or a user-designated agent should be able to determine the policy
263			for accepting or rejecting cookies based on whether the cookie is issued
264			by a verifiable or unverifiable transaction and the TrustLabel. The
265			default should be that "anonymous 1" or "no-share 1" cookies are accepted
266			from verifiable transactions and that "anonymous 1" cookies are accepted
267			from unverifiable transactions."
268
269
270
271			Jaye draft-ietf-jaye-trust-state-00.txt [Page 4]
272
273
274
275
276
277			INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) March 19, 1997
278
279
280
281			3.4 Trust Authority Role
282
283			The Trust Authority referred to in this document must be a neutral third
284			party that can be trusted to accurately characterize the privacy
285			behavior of web sites. The issuing of TrustLabels occurs outside the
286			scope of this protocol, but the protocol depends on user trust in that
287			authority. The Trust Authority must understand the scope in which a
288			TrustLabel applies and the related domain-matching rules, to ensure
289			that for all situations in which the TrustLabel would be deemed to be
290			applicable, the server(s) are in fact operating at the specified trust
291			level rating.
292
293			3.4.1 Issuing TrustLabels
294			On receiving a TrustLabel request, the authority should verify the trust
295			rating of the site requesting the TrustLabel and issue the appropriate
296			TrustLabel. To issue the TrustLabel, the authority hashes
297			the labellist provided by the requester, encrypts that hash value with
298			its private key and includes the resulting value as the
299			"signature-RSA-MD5" attribute in the TrustLabel it issues.
300
301			3.4.2 Revocation of TrustLabels
302			TrustLabels must have expiration dates. When a TrustLabel is issued,
303			the Trust Authority must receive agreement from the requesting
304
305			organization that the policies for which the TrustLabel was assigned
306			will be maintained until the TrustLabel expires or the domain becomes
307			inactive.
308
309			3.4.3 Discovery of Trust levels
310			Trust levels are well known values established by each Trust Authority.
311			Rules regarding handling of Trust Authority levels are established by
312			the user agent.
313
314
315			4. EXAMPLES
316
317			4.1 Example 1
318
319			1. User Agent policies:
320
321			In this example, the user agent has a policy of automatically
322			accepting cookies from domains that are have valid ratings of
323			"anonymous 1" or "no_share 1" by trust authority www.aaa.org.
324
325
326			2. User Agent -> Server
327
328			POST /acme/login HTTP/1.1
329			Host: acme.com
330			[form data]
331
332			User identifies self via a form.
333
334			3. Server -> User Agent
335			HTTP/1.1 200 OK
336			Set-PICS-Cookie: Customer="WILE_E_COYOTE"; Max-Age = 94608000;
337
338
339
340			Jaye draft-ietf-jaye-trust-state-00.txt [Page 5]
341
342
343
344
345
346			INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) March 19, 1997
347
348
349
350			Version="1"; Path="/acme"
351			(PICS-1.1 "http://www.aaa.org" label
352			by "aaa trust authority" gen true
353			for "http://www.acme.com/"
354			on "1995.10.15T13:29-0000" signature-RSA-MD5
355			E53G19D35A7B2158E53G19D35A7B2158E53G19D35A7B2158
356			exp "1995.12.31T23:59-0000" ratings (no_share 1))
357
358			Cookie reflects users identity and transmits signed label back to
359			user agent. Cookie is accepted by user agent because rating
360			"no_share" is recognized by the user agent cookie policy.
361
362			4.2 Example 2
363
364			1. User Agent policies:
365
366			In this example, the user agent has a policy of automatically
367			accepting cookies from domains that are "anonymous 1" or
368			"no_share 1" by trusted authority www.aaa.org or from unverifiable
369			transactions from domains that are verifiable as "anonymous 1" by
370			www.aaa.org.
371
372			2. User Agent -> Server
373
374			POST /acme/login HTTP/1.1
375			Host: acme.com
376			[form data]
377
378			User requests page with embedded IMG SRC reference to "http://www.roadrunnermaps.com/cgi-bin/maps?TER=deserts&FE=cliffs"
379
380			3. Server -> User Agent
381			HTTP/1.1 200 OK
382			Set-PICS-Cookie: Customer="0000000123"; Max-Age = 94608000;
383			Version="1"; Path="/birds"
384			(PICS-1.1 "http://www.aaa.org" label
385			by "aaa trust authority" gen true
386			for "http://www.acme.com/birds"
387			on "1995.10.15T13:29-0000" signature-RSA-MD5
388			3G19D35A7B2158E53G19D35A7B2158E53G19D35A7B2158E5
389			exp "1995.12.31T23:59-0000" ratings (no_share 1))
390
391			Cookie reflects users identity and transmits signed label back to
392			user agent. Cookie is accepted by user agent because rating
393			"no_share" is recognized by the user agent cookie policy.
394
395			4. User Agent -> Server
396
397			GET cgi-bin/maps?TERR=deserts&FEAT=cliffs HTTP/1.1
398			Host: roadrunnermaps.com
399
400			User requests image via CGI script
401
402			5. Server -> User Agent (unverifiable transaction)
403			HTTP/1.1 200 OK
404			Set-PICS-Cookie: Customer="0000000123"; Max-Age = 94608000;
405
406
407
408			Jaye draft-ietf-jaye-trust-state-00.txt [Page 6]
409
410
411
412
413
414			INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) March 19, 1997
415
416
417
418			Version="1"
419			(PICS-1.1 "http://www.aaa.org" label
420			by "aaa trust authority" gen true
421			for "http://www.roadrunnermaps.com/"
422			on "1995.10.15T13:30-0000" signature-RSA-MD5
423			9D35A7B2158E53G19D35A7B2158E53G19D35A7B2158E53G1
424			exp "1995.12.31T23:59-0000" ratings (anonymous 1))
425
426			Cookie reflects user's system generated id number and transmits
427			signed label back to user agent. Cookie is accepted by user
428			agent because rating "anonymous" is recognized by the user agent
429			cookie policy for unverifiable transactions.
430
431
432			5. SECURITY CONSIDERATIONS
433
434			5.1 Revocation of TrustLabels
435
436			A site could receive a TrustLabel for a particular trust level rating
437			and later change its policies before the TrustLabel has expired. To
438			address this need, Trust Authorities should execute agreements with
439			TrustLabel recipients to provide legal remedies to discourage this
440			behavior.
441
442
443			6. SUMMARY
444
445			This document presents an extension to the state management protocol
446			defined in RFC2109. It describes only changes to that protocol. Any
447			parts of the state management not explicitly described here are assumed
448			to remain as defined in RFC 2109.
449
450			The protocol described here allows a user agent to verify that the
451			origin server is using cookies in a manner consistent with the privacy
452			expectations of the user, by providing a certificate. or TrustLabel,
453			issued by a trusted authority.
454
455
456			7. ACKNOWLEDGEMENTS
457
458			This document represents extensive work by Toby Bloom, as well as input
459			from Dave Kristol, Yaron Goland, Jonathan Stark, and Dan Connolly.
460
461
462			8. REFERENCES
463
464			[PICS] Jim Miller et al, PICS Label Distribution label Syntax and
465			Communication Protocol, Version 1.1, REC-PICS-labels-961031
466			http://www.w3.org/pub/WWW/PICS/labels.html
467
468			[Kristol] Kristol, David M., HTTP State Management Mechanism (rev 1).
469			Internet Draft <draft-ietf-http-state-man-mec-01.txt>
470			ftp://ietf.org/internet-drafts/draft-ietf-http-state-man-mec-01.txt
471
472
473
474
475
476
477			Jaye draft-ietf-jaye-trust-state-00.txt [Page 7]
478
479
480
481
482
483			INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) March 19, 1997
484
485
486
487			9. AUTHOR'S ADDRESS
488
489			Daniel Jaye
490			Engage Technologies
491			100 Brickstone Square
492			1st Floor
493			Andover, MA 01810
494
495			Phone: (508) 684-3641
496			FAX: (508) 684-3636
497			Email: djaye@engagetech.com
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546			Jaye draft-ietf-jaye-trust-state-00.txt [Page 8]
547
548