Re: [DNSOP] Public Suffix List

[Eric Brunner-Williams <[e-mail]>]

Gervase,

The Dan Jay (and later) cookie policy drafts had a dsig in the payload 
so that the data collection policy (DCP) asserted in a cookie could be 
verified. The xml dsig draft wasn't ready, so we took off that part of 
the payload, leaving only the DCP. At the W3C P3P Spec WG meeting in San 
Jose a _large_ vendor agreed to implement what had been protoyped in 
Mozilla, replacing a no-3rd-party-cookies policy (there's reasonable 
policy claims on both sides of that) with parse-the-policy-user-decide 
policy (again, there's reasonable ...).

It's not unreasonable to revisit how we know an assertion about a DCP is 
true, or provably false, as xml dsig is now mature.

Turning to the list it self, I'm working on proposals (to ICANN) for new 
generic TLDs with string lengths greater than four bytes, and the latest 
estimate (by ICANN staff) is that they anticipate between 300 and 600 
applications in 2009, zero or more of which may be operationalized in 
2010. Additionally, a subset of the existing iso3166 code-point 
associated registries may elect to apply to add non-ASCII (well, 
technically, ACE junk) labels to the root.

My point here is that two of the safe assumptions (byte count < mumble & 
( sizeof(rootzone) & compositionof(rootzone) ) are quasi-static) has a 
two-year or less shelf-life remaining.

It isn't unreasonable to expect registry operators under contract (to 
ICANN) to publish SLD data directly, so you (and others) don't have to 
wikipedia (not that wikipedia isn't generally a better source of data), 
and you'd probably want that in From [e-mail]  Mon Jun  9 10:47:46 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id CE6763A69B5;
	Mon,  9 Jun 2008 10:47:46 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B06703A691F
	for <[e-mail]>; Mon,  9 Jun 2008 10:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 
	RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id wjmpz3aUhOx3 for <[e-mail]>;
	Mon,  9 Jun 2008 10:35:53 -0700 (PDT)
Received: from nic-naa.net (unknown [65.99.1.131])
	by core3.amsl.com (Postfix) with ESMTP id 71A483A67FB
	for <[e-mail]>; Mon,  9 Jun 2008 10:35:53 -0700 (PDT)
Received: from clam-local.local (dpc67142250094.direcpc.com [67.142.250.94])
	by nic-naa.net (8.14.2/8.14.2) with ESMTP id m59CWlXo088278;
	Mon, 9 Jun 2008 08:32:50 -0400 (EDT)
	(envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Mon, 09 Jun 2008 10:35:53 -0700
From: Eric Brunner-Williams <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Gervase Markham <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Mailman-Approved-At: Mon, 09 Jun 2008 10:47:44 -0700
Cc: [e-mail], [e-mail]
Subject: Re: [DNSOP] Public Suffix List
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

Gervase,

The Dan Jay (and later) cookie policy drafts had a dsig in the payload 
so that the data collection policy (DCP) asserted in a cookie could be 
verified. The xml dsig draft wasn't ready, so we took off that part of 
the payload, leaving only the DCP. At the W3C P3P Spec WG meeting in San 
Jose a _large_ vendor agreed to implement what had been protoyped in 
Mozilla, replacing a no-3rd-party-cookies policy (there's reasonable 
policy claims on both sides of that) with parse-the-policy-user-decide 
policy (again, there's reasonable ...).

It's not unreasonable to revisit how we know an assertion about a DCP is 
true, or provably false, as xml dsig is now mature.

Turning to the list it self, I'm working on proposals (to ICANN) for new 
generic TLDs with string lengths greater than four bytes, and the latest 
estimate (by ICANN staff) is that they anticipate between 300 and 600 
applications in 2009, zero or more of which may be operationalized in 
2010. Additionally, a subset of the existing iso3166 code-point 
associated registries may elect to apply to add non-ASCII (well, 
technically, ACE junk) labels to the root.

My point here is that two of the safe assumptions (byte count < mumble & 
( sizeof(rootzone) & compositionof(rootzone) ) are quasi-static) has a 
two-year or less shelf-life remaining.

It isn't unreasonable to expect registry operators under contract (to 
ICANN) to publish SLD data directly, so you (and others) don't have to 
wikipedia (not that wikipedia isn't generally a better source of data), 
and you'd probably want that in mamachine readable form, with an update 
mechanism, and it might be useful if that request got incorporated into 
the process I mentioned above before it "goes live".

The PROVREG WG added a DCP into EPP, however, the intended scope was 
simply to announce the DCP of registry operators to registrars, who may 
then communicate the registry's DCP, and their own, towards the eventual 
registrant. We didn't provide a mechanism for registrants to announce 
the DCPs that they would be implementing from the resources they 
obtained by registering domains, or a mechanism for registries to 
announce DCPs scoped to a particular namespace.

FYI, the elephant in the room for P3P is we didn't provide a means to 
assert linkage to data collected by other means, so data collectors 
don't have a means to announce if they do, or don't, link cookie data 
with credit-report data obtained by other means.

We did, over the objections of one of the major deterministic personal 
profile vendors, now owned by a _large_ search engine operator, make 
linked data disclosure manditory through the include/exclude statements.

Eric

Gervase Markham wrote:
> Dear HTTP and DNS Operations WGs,
>
> The following email message will shortly be sent to the technical
> contact for all TLDs. Yngve Pettersen at Opera suggested that I also let
> you both know about it.
>
> The technology in question, including a version of the list, is about to
> ship in Firefox 3, but we'd like to verify and improve the quality of
> the underlying data.
>
> Please let me know if you see any way I can improve the email, the
> explanatory website, or the submission process.
>
> Gerv
>
> <snip>
> Dear Technical Contact,
>
> The Mozilla Project (http://www.mozilla.org/), responsible for the
> Firefox web browser, requests your help.
>
> We are maintaining a list of all "Public Suffixes". A Public Suffix is a
> domain label under which internet users can directly register domains.
> Examples of Public Suffixes are ".net", ".org.uk" and ".pvt.k12.ca.us".
> In other words, the list is an encoding of the "structure" of each
> top-level domain, so a TLD may contain many Public Suffixes. This
> information is used by web browsers for several purposes - for example,
> to make sure they have secure cookie-setting policies. For more details,
> see http://publicsuffix.org/learn/.
>
> We would like your help to make sure, now and in the future, that the
> entries for your TLD(s) are correct. It is in your interest as a
> registry to make sure that this is so. Any errors may either cause your
> customers (domain owners in your TLD) to not be able to set cookies when
> they should, or cause cookie information to be leaked between two
> domains without a trust relationship. Neither of these things is desirable.
>
> Therefore, we are writing to ask your technical team to view the current
> list and, if it is incorrect, to submit updated data. A description of
> the format of the list, and details for sending updates is at:
>
> http://publicsuffix.org/submit/
>
> We also ask you to send updated information whenever you change your
> registration policies in a way which affects the list.
>
> Thanking you in advance,
>
> Gervase Markham
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>   

_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop


chine readable form, with an update 
mechanism, and it might be useful if that request got incorporated into 
the process I mentioned above before it "goes live".

The PROVREG WG added a DCP into EPP, however, the intended scope was 
simply to announce the DCP of registry operators to registrars, who may 
then communicate the registry's DCP, and their own, towards the eventual 
registrant. We didn't provide a mechanism for registrants to announce 
the DCPs that they would be implementing from the resources they 
obtained by registering domains, or a mechanism for registries to 
announce DCPs scoped to a particular namespace.

FYI, the elephant in the room for P3P is we didn't provide a means to 
assert linkage to data collected by other means, so data collectors 
don't have a means to announce if they do, or don't, link cookie data 
with credit-report data obtained by other means.

We did, over the objections of one of the major deterministic personal 
profile vendors, now owned by a _large_ search engine operator, make 
linked data disclosure manditory through the include/exclude statements.

Eric

Gervase Markham wrote:
> Dear HTTP and DNS Operations WGs,
>
> The following email message will shortly be sent to the technical
> contact for all TLDs. Yngve Pettersen at Opera suggested that I also let
> you both know about it.
>
> The technology in question, including a version of the list, is about to
> ship in Firefox 3, but we'd like to verify and improve the quality of
> the underlying data.
>
> Please let me know if you see any way I can improve the email, the
> explanatory website, or the submission process.
>
> Gerv
>
> <snip>
> Dear Technical Contact,
>
> The Mozilla Project (http://www.mozilla.org/), responsible for the
> Firefox web browser, requests your help.
>
> We are maintaining a list of all "Public Suffixes". A Public Suffix is a
> domain label under which internet users can directly register domains.
> Examples of Public Suffixes are ".net", ".org.uk" and ".pvt.k12.ca.us".
> In other words, the list is an encoding of the "structure" of each
> top-level domain, so a TLD may contain many Public Suffixes. This
> information is used by web browsers for several purposes - for example,
> to make sure they have secure cookie-setting policies. For more details,
> see http://publicsuffix.org/learn/.
>
> We would like your help to make sure, now and in the future, that the
> entries for your TLD(s) are correct. It is in your interest as a
> registry to make sure that this is so. Any errors may either cause your
> customers (domain owners in your TLD) to not be able to set cookies when
> they should, or cause cookie information to be leaked between two
> domains without a trust relationship. Neither of these things is desirable.
>
> Therefore, we are writing to ask your technical team to view the current
> list and, if it is incorrect, to submit updated data. A description of
> the format of the list, and details for sending updates is at:
>
> http://publicsuffix.org/submit/
>
> We also ask you to send updated information whenever you change your
> registration policies in a way which affects the list.
>
> Thanking you in advance,
>
> Gervase Markham
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>   

_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop