comments on draft-ietf-http-trust-state-mgt-02.txt

Here are my comments on draft-ietf-http-trust-state-mgt-02.txt.  I
think the default settings for the use of trust labels and cookies need
to be discussed more.  See below, under 3.3.2.

Dave Kristol
==============

Substantive:

3.1  Syntax: General
    the optional label attributes "by" "gen" "for" "on" and "exp" 
        are required. 

    -> except that the syntax shows that "by" is still optional.

    privacypractice = "purpose" 1*purposerating 
	--> 1*purposerating is inconsistent with the later examples,
	which show things like "0:4" (several places).

    trust-label-data = labelattr-data privacy-practice [cookielist]
    ...
    "cookielist" refers to the list of cookie names in the cookieblock 
    extension.
	--> It would be better to create a "cookielist" non-terminal
	in the grammar (and use it for non-terminal "cookieinfo").

    purpose. Services that disclose that they use data for "other" purposes 
    should provide human readable explanations of those purposes. 
	--> The specification needs to say where/how to get them.

    "Contacting Visitors for Marketing of Services or Products" 
						     value = 4
	--> I'm unclear what this means.  Does it mean that the cookie
	accompanies (and is) the "contact", or does it imply there's
	some kind of subsequent or out-of-band contact?

	For example, a cookie from an (third-party) advertising site
	might be construed as purpose 4.

    "non-identifiable"                               value = 0
    "identifiable"                                   value = 1
	--> This begs for a definition of what comprises "information
	gathered ... in identifiable form", or, at the very least, an
	example.

3.3.1 Interpreting the trust-label
    A trust-label is ignored if the "exp-date" attribute of labelattr
    is less than or equal to the current date.
	--> Wouldn't it also make sense to do likewise if the exp-date
	attribute is <= the Date: header in the server's response?

    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.

	--> I don't think this is quite right.  If I understand how
	this stuff works,
	    1) The user agent calculates its own cleartext signature
	    for the trust-label-data; and
	    2) It compares the result against the decrypted sigblock
	    value.
	That is, the attributes themselves don't get decrypted.  Also,
	it's important to emphasize how the user agent should
	canonicalize the attributes when it does its calculation.

	Therefore, I think the wording should be something like this:

    The user agent validates the signature as follows.  It calculates
    its own signature for the trust-label from labelattr-data,
    privacy-practice, and cookielist, using the canonicalization rules
    of [DSIG].  (That is, it must mimic the trust authority's
    calculation.)  It then uses the public key of the trust authority
    to decrypt the sigblock value and compares the result against its
    own calculation.  The signature is valid if the two values agree.
    ------

    If the digital signature is invalid, then the trust-label should be 
    ignored and the cookie should not be set.
	--> I think the user agent should do whatever it would do when
	it receives a cookie that has no trust label, rather than
	always not set the cookie.  I think that's more consistent.

3.3.2	Accepting or rejecting Cookies
    User agents should have the following default preferences:
      Automatically accept:
	Cookies from verifiable transactions with trust-labels with 
	  purposerating 0 through 4 and dourating 0;
	Cookies from unverifiable transactions with trust-labels with 
	  purposerating 0 through 4 and idrating 0 and 
	  dourating 1.
      Automatically reject:
	Cookies from unverifiable transactions without trust-labels.

	--> IMO the default purposerating should be 0-3.  If you want to
	create an installation option that asks users ("opt in") whether
	4 is okay, fine.

	--> There's no mention above of *signed* trust labels.  IMO
	cookies for unverifiable transactions should require a signed
	label (by default).

	--> As the specification is now written, the "by" attribute is
	optional, as are signatures.  So a site need not even name a
	trust authority, can invent trust labels, and can bypass the
	"protections" the defaults should provide.  It also makes it
	even simpler to work around the admittedly weak "protections"
	in state-man-mec-08.  That's unsatisfactory.

	I think the spec. should require, at a minimum, either a "by"
	or a sigblock.  The "by" is a lame protection, but at least if
	a site fraudulently sends an unsigned label by a bogus trust
	authority there might be some recourse under consumer fraud
	rules.

Nits:

In a couple of places, the formatting is broken:  lines extend beyond
the margin:  Domainofuse; 3.4.3 Discovery ...; 5.2 False ...; 7.;
ACKNOWLEDGEMENTS.

There are a couple of references to RFC 2109.  Should they be changed
to state-man-mec-08?

There are a couple of instances of expired "exp" attributes in the
examples:  exp "1997.12.31T23:59-0000".

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 
    ^-- change: a

3.1  Syntax: General
    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.
	REWORD AS
    The PICS label applies to the cookies listed in the cookieinfo
    extension, or to all compatible cookies if no cookies are
    explicitly listed.

    an extension to include a list of the specific cookies to 
        to which the trust-label applies;
	== -> delete

    the optional label attributes "by" "gen" "for" "on" and "exp" 
        are required. 
	REWORD AS (and see note, earlier, about "by")
    the optional PICS label attributes "by", "gen", "for", "on", and
	"exp" are required by this specification.

    serviceID       = 
	  "http://www.w3.org/PICS/systems/P3P-http-trust-state-01.rat" |
	^-- insert: <">					 insert <"> --^
	    --> it's supposed to be quoted

    The Identifiable rating specifies whether the information gathered is in 
    identifiable form, is associated with identifiable information, or used 
    						       insert: "is" --^
    to derive personal identity.

3.3 	User Agent Role

    The user agent receives a cookie headers and trust-labels from
    			    = -> delete

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.
    			   ^-- insert: when

3.4.3 Discovery of privacy-practice ratings
    well-known rating service, http:\www.w3.org\PICS\1.0\P3P\v1.0,
 		   change to: http://www.w3.org/PICS/1.0/PRP/v1.0
    is referenced in this document.

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 rating of 
    "domainofuse 0".
	-> REWORD AS
    In this example, the user agent has a preference for automatically
    accepting cookies from domains that have a valid rating of 
    "domainofuse 0", and the user agent does not require signed labels.

4.2 Example 2
    "domainofuse 0" or "domainofuse 1 by www.aaa.org.
    				     ^-- insert: "

(Under 5)
    www.aaa.org" is acceptable to the user agent.
    ^-- insert: "

5.2 False representation
    site's adherence to its stated privacy practice.  However, if the
    site digitally signs the label, then that may represents a legally
    						  delete --^
    binding contract on the site to follow the professed privacy
    ...

7. ACKNOWLEDGEMENTS

    This document represents input from Dave Kristol, Yaron Goland,
					==== -> "David M.", please.
    Joseph Reagle, and Jonathan Stark..

Received on Wednesday, 25 March 1998 11:27:12 UTC