W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

FW: revised trusted cookie spec

From: Jaye, Dan <DJaye@engagetech.com>
Date: Wed, 13 Aug 1997 20:18:39 -0400
Message-Id: <c=US%a=_%p=CMG%l=ANDEXC01-970814001839Z-3003@wilexc01.cmgi.com>
To: "'http-wg@cuckoo.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, "'http-state@lists.research.bell-labs.com'" <http-state@lists.research.bell-labs.com>
Delivery of this message failed the first time... Here is a resend:



Here is the spec:

 


As promised:

Summary of changes:

Tries to be consistent with vocabulary work of the IPWG at the CDT and 
the Vocab and Architecture working groups or the P3 project (aka OPS). 
Does NOT incorporate PICS 2.0 or PICSrulz.  Assumes PICS 1.1.

Use of the PICS-Label header for trust labels instead of 
Set-PICS-Cookie.

Uses W3C Digital Signatures working draft for signing of trust 
labels.

Discusses user privacy preferences and server privacy practices.

Includes four well-known privacy practice ratings.

DOES NOT REQUIRE A TRUST AUTHORITY... but... to be determined by 
market?

Distinguishes between no exchange of information and
no exchange of personally identifying information.

Recommends default user privacy preferences for acceptance of cookies 
from verifiable transactions if server practice is noexchange, 
anonymousexchange, or noshare or unrated.

Recommends a default user privacy preference for acceptance of cookies 
from unverifiable transactions only if server practice is noexchange 
or anonymousexchange and trust label has been digitally signed by a 
recognized trust authority.

Fixes numerous errors by author in first draft pointed out by DMK and 
others.

More explicit references to draft-ietf-http-state-mgt-mec-03.

DOES NOT include:
  Attribute group or attribute level rules for cookie handling.

  Grammar for expressing who has what authorization to modify cookie 
data,
  duration of data on the server, consequences of the data, etc.

  Revocation of server-collected data, etc.

  Stuff coming in PICS-2.0, and P3.

  Level of enforcement of trust authorities; to be established by 
market?  Audits,
  selective audits with contracts and penalties...










HTTP Working Group                      Daniel Jaye
INTERNET DRAFT                    Engage Technologies


<draft-ietf-http-jaye-trust-state-01.txt>
August 12, 1997                 Expires February 12, 1998


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


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 draft-ietf-http-state-man-mec-03[Kristol].  The intent is



Jaye            draft-ietf-jaye-trust-state-01.txt            [Page 1]





INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) August 12, 1997



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 
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 certify the privacy practices of servers regarding cookies.


2. TERMINOLOGY

The terms user agent, client, server, and origin are used as in [Kristol].
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 digitally signed PICS label[PICS].
The term Trust Authority represents the authority who established the 
valid PICS label values and assigns 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 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.  The user agent may then use that information 
to guide the acceptance or rejection of the cookie.

3.1  Syntax: General

This specification describes how the PICS-Label header, described in 



Jaye            draft-ietf-jaye-trust-state-01.txt            [Page 2]





INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) August 12, 1997



[PICS], is used to convey the privacy practices of the server to the user
agent.  The syntax of the state management header, Set-cookie2, is 
specified in [Kristol].  The new PICS-Label header syntax is specified 
below:

trusted-cookie  = 1*Set-cookie2 trust-label
trust-label     = "PICS-Label:" labellist

"labellist" is as specified in the PICS 1.1 label syntax in [PICS], except as extended by the digital signatures working draft [DSIG], some options are not used, and we require some of the optional elements, as specified below.  The trust-label applies to the immediately preceding Set-Cookie2 label. 

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 labels are specifically Trust-Labels.

labellist       = "(" version 1*service-info ")"
version         = "PICS-1.1"
service-info    = serviceID "label" 1*label
serviceID       = quotedURL
label           = labelattr "ratings" "(" privacy-practice ")" [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

"quotedname", "quotedURL", "rating",  and "quoted-ISO-date" are as defined
in the PICS specification [PICS].  ServiceID references a quoted URL that
represents the Trust Authority.  The labelattr clauses are optional in the
PICS spec, but all are required here. "for" is the URL or root URL for 
which this label applied.  "by" is the email address of the issuing trust 
authority.  The "gen" boolean 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.  SigBlock is the 
digital signature extension as described in the digital signature working



Jaye            draft-ietf-jaye-trust-state-01.txt            [Page 3]





INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) August 12, 1997



draft[DSIG].  

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 or transmit your 
personal 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 personal information or implicit information
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 or will share that information with 
third parties.  The trust authority should provide information about the 
purposes for which that information is being used.

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 = for-URL on-date exp-date privacy-practice

for-URL          = quotedURL
exp-date         = quoted-ISO-date

for-URL is the URL to which the privacy practice applies as listed in the 
"for" attribute in "labelattr".  Exp-date is the expiration date of the 
trust label as listed in the "exp" attribute of "labelattr".




Jaye            draft-ietf-jaye-trust-state-01.txt            [Page 4]





INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) August 12, 1997



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 immediately following the cookie header(s).  The trust 
label is assumed to apply to all cookies in the response that match the 
domain and path of the trust label according to the matching rules for 
matching cookies to request URI's described in [Kristol].

Any server wishing to provide digitally signed trust labels 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 rating 
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 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 followed by a 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 receives a trust label with a 
recognized privacy practice rating, it is assumed to be a trust label 
for the cookies in the response as long as the domain and path of the 
cookie match the domain and path of the trust label according to the 
matching rules described in [Kristol].  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 a few well-known Trust Authorities, the user agent 
implementer should store public keys from standard trust authorities 
to avoid extra round trips. 

The digital signature is valid if the decrypted trust-label-data 



Jaye            draft-ietf-jaye-trust-state-01.txt            [Page 5]





INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) August 12, 1997



satisfies the following criteria:

1) that the domain portion of the URL specified in the for-URL attribute 
domain matches the domain of the cookie according to the matching 
rules as sort forth in [Kristol];

2) that the path portion of the URL specified in the for-URL attribute is
compatible with the path of the cookie.  If the trust label is generic, 
then the for-URL path must be a prefix of the cookie's path.  If the 
trust label is not generic, then it must match exactly. 

3) that the "on-date" attribute of the trust label is less than or equal
to the current date;

4) that the "exp-date" attribute of the trust-label-data is greater than
or equal to the current date.

If the digital signature is invalid, then the cookie should be rejected.

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.  

User Agents should have default preferences that allow "noexchange 1", 
"anonymousexchange 1", and "noshare 1" rated cookies to be accepted from
verifiable transactions and that allow "noexchange 1" and 
"anonymousexchange 1" rated cookies to be accepted from unverifiable 
transactions.

The User Agent should have a default preference to reject "third-party-
exchange" cookies from unverifiable transactions.  

For example, a user may wish to accept cookies rated anonymousexchange by
a recognized trust authority, rather than relying on an unsigned trust 
label or a trust label signed by an unrecognized entity.

3.3.3  User intervention
The user agent may prompt the user to verify that it wishes to reject a 
cookie in certain conditions where the cookie is being rejected based on a 
default preference.



Jaye            draft-ietf-jaye-trust-state-01.txt            [Page 7]





INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) August 12, 1997



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, but the protocol depends on user trust in that
authority.  The Trust Authority must understand the scope in 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.

3.4.1 Issuing trust labels
On receiving a trust label request, 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 well known values established by each Trust Authority, several of which are proposed in this document.


4. EXAMPLES

4.1 Example 1




Jaye            draft-ietf-jaye-trust-state-01.txt            [Page 7]





INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) August 12, 1997



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-Cookie: Customer="WILE_E_COYOTE"; Max-Age = 94608000; 
        Version="1"; Path="/acme" 
      PICS-Label: (PICS-1.1 "http://www.aaa.org" label 
        by "paranoid@aaa.org" gen true
        for "http://www.acme.com/"
        exp "1997.12.31T23:59-0000" 
        ratings (noshare 1))

    A cookie that includes the users identity and an unsigned PICS
    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: acme.com
      [form data]

    User requests page with embedded IMG SRC reference to
    "http://www.roadrunnermaps.com/cgi-bin/maps?TER=deserts&FE=cliffs"



Jaye            draft-ietf-jaye-trust-state-01.txt            [Page 8]





INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) August 12, 1997



3.  Server -> User Agent
      HTTP/1.1 200 OK
      Set-PICS-Cookie: Customer="0000000123"; Max-Age = 94608000; 
        Version="1"; Path="/birds" 
      PICS-Label: (PICS-1.1 "http://www.aaa.org" label 
        by "paranoid@aaa.org" gen true
        for "http://www.acme.com/"
        exp "1997.12.31T23:59-0000" 
        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 user agent because the rating "noshare 1" is compatible with the 
    user agent privacy preference.

4.  User Agent -> Server

      GET cgi-bin/maps?TERR=deserts&FEAT=cliffs HTTP/1.1
      Host: roadrunnermaps.com

    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-PICS-Cookie: Customer="0000000123"; Max-Age = 94608000; 
        Version="1" 
      PICS-Label: (PICS-1.1 "http://www.aaa.org" label 
        by "paranoid@aaa.org" gen true
        for "http://www.acme.com/"
        exp "1997.12.31T23:59-0000" 
        extension 
          (optional "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" "8E53B19D35A3F19D35A38930E53FD35A7B215B2158")))
        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 rating "anonymous" is acceptable to the
    user agent's privacy preferences for cookie policy for unverifiable 
    transactions.



Jaye            draft-ietf-jaye-trust-state-01.txt            [Page 9]





INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) August 12, 1997



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 need, Trust Authorities should execute agreements with 
trust label 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 trust label, 
issued by a trusted 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., 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/






Jaye            draft-ietf-jaye-trust-state-01.txt            [Page 9]





INTERNET DRAFT HTTP Trust Mechanism for State Mgt (Rev1) August 12, 1997



9. AUTHOR'S ADDRESS

Daniel Jaye 
Engage Technologies 
100 Brickstone Square 
1st Floor
Andover, MA 01810

djaye@engagetech.com
508 684-3641 voice
508 684-3636 fax






































Jaye            draft-ietf-jaye-trust-state-01.txt            [Page 11]
Received on Wednesday, 13 August 1997 17:20:58 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:51 EDT