- From: Jaye, Dan <DJaye@engagetech.com>
- Date: Tue, 28 Oct 1997 12:17:45 -0500
- To: "'http-state@lists.research.bell-labs.com'" <http-state@lists.research.bell-labs.com>, "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
- Message-Id: <c=US%a=_%p=CMG%l=ANDEXC01-971028171745Z-2581@wilexc01.cmgi.com>
Here is the revision to the HTTP Jaye Trust State Mgt draft. Summary of Changes: Trust-label headers no longer apply to the preceding Set-Cookie header. Instead, they either apply to all cookies in the server response or to specific cookies listed in an extension to the PICS label. This PICS Label extension is a mandatory extension and is also used to identify the label as a trust label and to make legacy or document label parsers ignore the label. The extension definition is currently going through the Note submission process at the W3C. Matching rules for trust-labels and cookies were clarified as well as the process for verifying the digital signature against the plaintext trust-label. Incorporated various corrections and suggestions from Dave Kristol. Of course this draft (submitted last week) refers to the (now superceded) version of Dave Kristol's State Mgt Mech draft v03 instead of v04 which was released today. Daniel Jaye djaye@engagetech.com Chief Technology Officer v(508) 684-3641 Engage Technologies f(508) 684-3636 100 Brickstone Square, 1st Floor, Andover, MA 01810
HTTP Working Group Daniel Jaye
INTERNET DRAFT Engage Technologies
<draft-ietf-http-jaye-trust-state-02.txt>
October 23, 1997 Expires April 23, 1998
HTTP Trust Mechanism for State Management
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 2.06.
ABSTRACT
HTTP TRUST MECHANISM PROPOSAL FOR STATE MANAGEMENT
October 23, 1997
1. ABSTRACT
This document specifies an addition to the state management protocol
specified in draft-ietf-http-state-man-mec-03[Kristol]. The intent is
to provide a mechanism that allows user agents to determine the privacy
practices of a server and to accept or reject cookies based on those
practices. Allowing the user to establish preferences for how to handle
cookies based on the server's practices provides a practical mechanism
Jaye draft-ietf-jaye-trust-state-02.txt [Page 1]
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997
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 PICS ratings representing server privacy practices. It then
issues trust-labels, in the form of digitally signed PICS 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 PICS-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.
2. TERMINOLOGY
The terms user agent, client, server, proxy, and origin server have the
same meaning as in the HTTP/1.1 specification [RFC 2068]. The terms
domain-match, verifiable transaction, and unverifiable transaction are
defined in [Kristol], and those definitions are also used here.
The term trust-label is used to mean a PICS label [PICS] used to
communicate the cookie-related privacy practices of a server.
The term Trust Authority refers to the PICS label rating service for
trust-labels who may issue digitally signed trust-labels to domains.
3. OUTLINE
The server sends a Set-Cookie and/or a Set-Cookie2 header to the user
Agent along with a PICS-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.
3.1 Syntax: General
This specification describes how the PICS-Label header, described in
[PICS], is used to convey the privacy practices of the server to the
user-agent The new PICS-Label header syntax is specified below:
trust-label = "PICS-Label:" labellist
The header is recognized as a trust-label by the existence of the
cookieinfo extension. This trust-label applies to cookies in the
response that are compatible (as described in section 3.3.1) with
the domain and path of the "for" labelattr of the PICS-Label header.
Jaye draft-ietf-jaye-trust-state-02.txt [Page 2]
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997
The specific cookies are listed in the cookieinfo extension to the
PICS label or to all compatible cookies if no cookies listed in the
cookieinfo extension. "labellist" is as specified in the PICS 1.1 label
syntax in [PICS], except for the following changes:
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.
The modified PICS label syntax is listed here.
labellist = "(" version 1*service-info ")"
version = "PICS-1.1"
service-info = serviceID "label" 1*label
serviceID = quotedURL
label = labelattr "ratings" "(" privacy-practice ")"
cookieinfo
[sigblock]
labelattr = "by" quotedname
"gen" boolean
"for" quotedURL
"on" quoted-ISO-date
"exp" quoted-ISO-date
privacy-practice
= "noexchange 1"
| "anonymousexchange 1"
| "noshare 1"
| "thirdpartyexchange 1"
| rating
cookieinfo = "extension" "(" "mandatory" <">
"http://www.w3.org/PICS/extensions/cookieinfo-1_0.html"
<"> *cookiename ")"
cookiename = NAME
"quotedname", "quotedURL", "rating", and "quoted-ISO-date" are as
defined in the PICS specification [PICS].
ServiceID references a quoted URL that defines and describes the rating
service and references the rating system.
"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].
Jaye draft-ietf-jaye-trust-state-02.txt [Page 3]
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997
The sigblock must contain the SigCrypto token within the SigData block.
The SigCrypto token 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.
Four well-known privacy-practice values are described here to provide
recognized values that should be handled by user agents.
The "noexchange 1" rating indicates that the Trust Authority has
verified that the server will not use the cookie to collect persistent
user information.
The "anonymousexchange 1" rating indicates that the Trust Authority has
verified that the server will not use the cookie to collect or transmit
personally identifying information (e.g., name, address, telephone
number, email address, etc.) but may collect anonymous or aggregated
personal information (e.g., gender, geographic region, approximate age,
derived data such as clickstream, etc.) or implicit information (such as
web usage patterns) as long as it will never be associated with
personally identifying information. The server may collect IP Addresses
but they must not be associated with personally identifying information
to be elegible for this rating.
The "noshare 1" rating indicates that the Trust Authority has verified
that the server may use the cookie to collect or transmit personally
identifying information (e.g., name, address, telephone number, email
address, etc.) but will never share that information with companies
other than the company to which the user provided the information.
The "thirdpartyexchange 1" rating indicates that the Trust Authority has
verified that the server may use the cookie to collect or transmit
personally identifying information (e.g., name, address, telephone
number, email address, etc.) and may share that information with
third parties.
All other items above are as described in the PICS label syntax [PICS]
or in the Digital Signatures working draft [DSIG].
3.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).
Jaye draft-ietf-jaye-trust-state-02.txt [Page 4]
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997
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.
3.3 User Agent Role
The user agent receives a cookie headers and trust-labels from
an origin server.
3.3.1 Interpreting the trust-label
User agents interpret cookies as described in RFC 2109. In addition
to the cookie attributes, the user agent must now interpret the
trust-labels as well. If the user agent receives a PICS 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:
1) 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].
2) 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
implementer should cache public keys from standard trust authorities
to avoid extra network traffic.
Jaye draft-ietf-jaye-trust-state-02.txt [Page 5]
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997
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.
3.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 rated "anonymousexchange 1" and signed by a
recognized Trust Authority.
User agents should have the following default preferences:
"noexchange 1", "anonymousexchange 1", and "noshare 1" rated cookies
from verifiable transactions are accepted;
"noexchange 1" and "anonymousexchange 1" rated cookies from
unverifiable transactions are accepted;
"thirdpartyexchange 1" cookies from unverifiable transactions are
rejected.
3.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.
3.3.4 Cookie request header syntax
The syntax for the Cookie request header has not been modified.
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 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 the specified privacy rating.
Jaye draft-ietf-jaye-trust-state-02.txt [Page 6]
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997
3.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.
3.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.
3.4.3 Discovery of privacy-practice ratings
Privacy-practice ratings are defined in the PICS label rating system
referenced by the Trust Authority's label rating service. One
well-known rating system is proposed in this document.
4. EXAMPLES
4.1 Example 1
1. User Agent preferences:
In this example, the user agent has a preference for automatically
accepting cookies from domains that have valid ratings of
"anonymousexchange 1" or "noshare 1".
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"
PICS-Label: (PICS-1.1 "http://www.aaa.org" label
by "auditor@aaa.org" gen true
for "http://www.acme.com/"
exp "1998.12.31T23:59-0000"
Jaye draft-ietf-jaye-trust-state-02.txt [Page 7]
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997
extension
(mandatory
"http://www.w3.org/PICS/extensions/cookieinfo-1_0.html")
ratings (noshare 1))
A cookie that includes the user's identity and an unsigned trust
label header are sent back to the user agent with the request. The
cookie is accepted because rating "noshare 1" is acceptable
according to the privacy preferences of the user agent.
4.2 Example 2
1. User Agent preferences:
In this example, the user agent has a preference for automatically
accepting cookies that are rated "noexchange 1",
"anonymousexchange 1", or "noshare 1" or from cookies in
unverifiable transactions that are rated "noexchange 1" or
"anonymousexchange 1" 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"
PICS-Label: (PICS-1.1 "http://www.aaa.org" label
by "auditor@aaa.org" gen true
for "http://www.acme.com/"
exp "1997.12.31T23:59-0000"
extension
(mandatory
"http://www.w3.org/PICS/extensions/cookieinfo-1_0.html")
ratings (noshare 1))
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 the rating "noshare 1" is compatible with
the user agent privacy preference.
4. User Agent -> Server
GET cgi-bin/maps?TER=deserts&FE=cliffs HTTP/1.1
Host: www.roadrunnermaps.com
Jaye draft-ietf-jaye-trust-state-02.txt [Page 8]
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997
User requests an image via CGI script from a third party map
provider. This is an unverifiable transaction.
5. Server -> User Agent (unverifiable transaction)
HTTP/1.1 200 OK
Set-Cookie2: Customer="0000000123"; Max-Age = 94608000;
Version="1"
PICS-Label: (PICS-1.1 "http://www.aaa.org" label
by "auditor@aaa.org" gen true
for "http://www.roadrunnermaps.com/"
exp "1997.12.31T23:59-0000"
extension
(optional
"http://www.w3.org/PICS/extensions/cookieinfo-1_0.html"
Customer)
extension
(mandatory "http://www.w3.org/PICS/DSig/sigblock-1_0.html"
("AttribInfo"
("http://www.w3.org/PICS/DSig/X509.html"
"base64-x.509-cert"))
("Signature" "http://www.aaa.org/trust.html"
("byName" "aaapublickey")
("SigCrypto"
"8E53B19D35A3F198930E5D815B235A38930E53FDA815B2158")))
ratings (anonymousexchange 1))
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 rated "anonymous 1" in
an unverifiable transaction signed by "http://www.aaa.org" is
acceptable to the user agent and the Customer Cookie
5. SECURITY CONSIDERATIONS
5.1 Revocation of trust-labels
A site could receive a trust-label for a particular trust level rating
and later change its policies before the trust-label has expired. To
address this Trust Authorities should execute agreements with trust
label recipients to provide legal remedies to discourage this behavior.
5.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.
Jaye draft-ietf-jaye-trust-state-02.txt [Page 9]
INTERNET DRAFT HTTP Trust Mechanism for State Mgt October 23, 1997
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 mechanism 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 trust-label which may be signed
by a Trust Authority.
7. ACKNOWLEDGEMENTS
This document represents contributions 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 Protocols, Version 1.1, REC-PICS-labels-961031
http://www.w3.org/PICS/labels.html
[Kristol] Kristol, David M., Montulli, Lou, HTTP State Management
Mechanism (Rev 1).
Internet Draft <draft-ietf-http-state-man-mec-03.txt>
ftp://ietf.org/internet-drafts/draft-ietf-http-state-man-mec-03.txt
[DSIG] Philip DesAutels et al, DSIG 1.0 Signature Labels, Version 1.0,
WD-DSIG-label-970605
http:/www.w3.org/TR/WD-DSIG-label.html/
9. AUTHOR'S ADDRESS
Daniel Jaye
Engage Technologies
100 Brickstone Square, 1st Floor
Andover, MA 01810
djaye@engagetech.com
978 684-3641 voice
978 684-3636 fax
Jaye draft-ietf-jaye-trust-state-02.txt [Page 10]
Received on Tuesday, 28 October 1997 09:26:40 UTC