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]