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 |
|