RE: grrp-reqs-06, 11. Security Considerations [3]

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

>-----Original Message-----
>From: Eric Brunner-Williams in Portland Maine
>[mailto:brunner@nic-naa.net]
>Sent: Friday, February 16, 2001 11:36 AM
>To: Hollenbeck, Scott
>Cc: ietf-provreg@cafax.se; brunner@nic-naa.net
>Subject: Re: grrp-reqs-06, 11. Security Considerations [3] 
>
>
>Scott,
>
>Well I knew it wasn't added at my request as I recall mentioning onward
>transport, jurisdictional issues, and data collection at San Diego.
>
>You make two points:
>
>	1. a mechanism capable of articulating a policy is not necessary
>	   for session policing (A & I excepted, naturally), as contract
>	   enforcement is available.
>
>	2. a mechanism capable of articulating data collection policy or
>	   the applicable jurisdiction of the data providor and 
>collector
>	   would be complex.
>
>Having finished last November a consortia activity for the 
>bulk transport
>of customer profile data, which presumes the data originates from http
>activity policed via P3P, and which looks dead similar to our notion of
>social information, I'm convinced neither point is defensible.
>
>Consider the case of intra-entity social data flows, the 
>motivation that
>brought IBM and HP to CPExchange, which is equivalent to the problem
>NSI-as-Registrar and NSI-as-Registry-Operator face. How does 
>contract law
>protect the participants? J-Random-Reseller originates 
>Registrant-J's data
>to NSI-as-Registrar, which onward-transports J's data to 
>NSI-as-Registry,
>and a policy botch is detected. Is the remedy J or 
>J-Random-Reseller forcing
>NSI-as-Registrar to sue NSI-as-Registry for breach or specific 
>performance?

The remedy should be well-defined in whatever legal arrangement exists
between the parties involved.

>Next, consider the case of inter-entity social data flows, without any
>jurisdictional complications (67 RegistRARs and one Registry merrily
>playing in CONUS only). No entity may make recourse to transaction- or
>session-specific mechanisms to associate policy (other than A 
>& I, sigh)
>with any datum. Everything better look like a nail.
>
>Finally, the above with jurisdictional complications, Sven 
>Moers in Berlin
>goes to a local reseller who uses Harald Alvestrand's 
>Oslo-based regional
>reseller who uses a UK-based Registrar to access a US-based 
>Registry. All
>hypothetical, but in real life Sven works at the Berlin Data Protection
>office. Jurisdiction shopping (the communicating parties have 
>some sort of
>legal arrangement in place) will either be entertaining, or 
>everything better
>look like a Deleware Nail.
>
>Do you assert that there no requirement for data collection 
>considerations,
>equivalent to your first point?

If I made that assertion the current requirement [3] (though I agree that
the meaning may not be clear; see below) would not exist, and my offer to
create such a section would not have been made.  

>(as I understand your first point, typing words on someone 
>else's keyboard
>at least as error-prone as typing on myown keyboard)
>
>If so then there is no reason to look at any mechanism to see 
>if one or more
>offer tractible solutions to an inextant requirement, however 
>I can't help
>but point out that from draft-jaye-http-trust-state-mgt-01.txt 
>to Section 4
>of the P3P CR draft we managed to express data collection in a 
>few bytes,
>and we've fewer than the old RIP limit on the number of 
>hops-to-Registry, so
>record route is also tractible, and if we look at the set of 
>meaningfully
>distinct statutory or contractual data collection practices, 
>the range of
>usefully unique identifiers hardly motivates OIDs or URIs or other junk
>in-band.
>
>I wouldn't have made the suggestion if I hadn't already 
>written the dtds,
>and morphing the syntax to asn.1 or bnf, or schema is 
>standards overhead,
>not operational overhead.

True, but moving policy identification data around _is_ operational
overhead, and I'm not convinced that it's necessary overhead in this
environment.

>Eric
>
>P.S. Just what exactly does [3] assert as a requirement other 
>than there
>     exists a mechanism exists to to distinguish technical from social
>     information? When I read it I thought "that doesn't say 
>anything the
>     cutting room floor doesn't already say -- data that 
>didn't get into
>     the zone file". Delete for lack of distinct meaning.

The issue I am trying to address is one of privacy WRT what a registry can
do with social data.  [3] is supposed to assert that the protocol must
provide a way to identify specific social data elements that require special
handling based on privacy policies.  For example, a registry's policy may
require publication of a registrant's name via whois or protocol query, but
it may allow registrants to opt-out of having other social information (such
as address and/or telephone number) published via whois or protocol query.
Would this re-wording be more clear:

[3] Some of the social information exchanged between a registrar and
registry can be considered personal, private, or otherwise restricted from
public disclosure.  Disclosure of such information MAY be restricted by laws
and/or business practices.  A generic protocol MUST provide services to
identify social information that is subject to disclosure restrictions
levied by laws and/or business practices.

<Scott/>