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

Thanks for the extensive review and feedback!


I will incorporate your comments except as noted below:

>-----Original Message-----
>From:	Dave Kristol [SMTP:dmk@research.bell-labs.com]
>Sent:	Wednesday, March 25, 1998 1:00 PM
>To:	Jaye, Dan
>Cc:	http-state@lists.research.bell-labs.com; http-wg@cuckoo.hpl.hp.com
>Subject:	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.
>
>    privacypractice = "purpose" 1*purposerating 
>	--> 1*purposerating is inconsistent with the later examples,
>	which show things like "0:4" (several places).
>[Include and indent original message text]  I will incorporate the full BNF
>for PICS ratings which supports enumerated rating numbers and ranges.
>
>    trust-label-data = labelattr-data privacy-practice [cookielist]
>    ...
>    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.
>[Include and indent original message text]  This should be explained in the
>document referenced by commenturl.
>
>    "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.
>[Include and indent original message text]  It is meant to imply subsequent
>out-of-band contact.  Displaying of a banner ad for example does not imply
>contact.
>
>    "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.
>
>[Include and indent original message text]  
>P3P will go into greater detail but I will expand this in the document.
>
>
>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.
>[Include and indent original message text]  You are absolutely correct.  This
>is a holdover of a version where purposerating 4 was still safe.  Out of band
>contact should definitely not be a default.
>
>	--> There's no mention above of *signed* trust labels.  IMO
>	cookies for unverifiable transactions should require a signed
>	label (by default).
>
>[Include and indent original message text]  
>Part of the issue is the lack of maturity of digital signature
>infrastructure.
>I am interested in feedback on simplifying the sigblock options to explicitly
>state RSA encryption given that RSA labs has given permission for use of
>their implementation for non-commercial software for PICS Labels.
>
>
>	--> 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.
>[Include and indent original message text]   This sounds right to me.  I will
>word this as:
>MUST include "by" or sigblock.  SHOULD include sigblock.
>

Received on Thursday, 26 March 1998 18:58:29 UTC