Re: [Dbound] Draft problem statement and IETF "bar BoF"

[Casey Deccio <[e-mail]>]

Hi Gerv,

Thanks for the feedback.

On Tue, Nov 4, 2014 at 12:55 PM, Gervase Markham <[e-mail]> wrote:

> On 04/11/14 15:42, Casey Deccio wrote:
> > Please find attached a draft DBOUND problem statement, resulting from
> > the action items taken at the bar BoF in Toronto on the same subject.
> > Please take a read and comment on the document.  There is probably a
> > better format for this, but it's a start for now...
>
> Here are some comments:
>
> * Your "Contrived PSL Entries" table is a little sub-optimal, in that
> one would never see those first two entries in the same PSL.
>
> example:   example is public
> *.example: All children of example are public
>
>
The goal was for a simple demonstration of how it works, with minimal
entries, but I can understand how the non-matching entry makes this a less
effective example.  I'll make some changes.  Thanks for the feedback.

Of course, future modifications make some of the remarks below moot, but
just to be sure we're on the same page...


> The first of these rules suggests that foo.example is private, the
> second that it is public


Well, technically the first rule only indicates the example is public.
Whether or not foo.example is effectively private depends on the complete
algorithm, not the stand-alone entry, correct?


> Your Table 2 is therefore wrong, because the
> PSL algorithm states that the longest matching rule applies, and so
> foo.example is public, not private (by the second rule).
> https://publicsuffix.org/list/ has the algorithm.
>

But there is a wildcard exception !foo.example (the third line), and the
algorithm explicitly gives precedence to exceptions.  Doesn't that mean the
third entry (!foo.example) wins?

In fact, I see this example on the public suffix site:
-----
*.tokyo.jp
!metro.tokyo.jp

Cookies *may* be set for foo.bar.tokyo.jp.
Cookies *may not* be set for bar.tokyo.jp.
Cookies *may* be set for metro.tokyo.jp, because the exception overrides
the previous rule.
-----

I read this more generically as:
-----
*.tokyo.jp
!metro.tokyo.jp

foo.bar.tokyo.jp is private
bar.tokyo.jp is public
metro.tokyo.jp is private
-----

Isn't that the same as the following?
-----
*.example
!foo.example

baz.bar.example is private
bar.example is public
foo.example is private
-----


> Perhaps the rules are intended to stand as 3 standalone examples, but
> that's not clear from the presentation.
>

I'll make the examples more clear.  Thanks for the suggestions.


>
> * "When an SSL certificate is for a wildcard domain, the entire range of
> names covered by the wildcard needs to be under the same control."
>
> It's not as simple as that. Google is allowed a cert for *.blogspot.com,
> but by your definitions, foo.blogspot.com and bar.blogspot.com are not
> under the same control. This is why the PSL is split into two sections -
> "ICANN DOMAINS" and "PRIVATE DOMAINS". (Naming is hard.)
>
>
In the document I've defined the terms more generically.  If I understand
correctly, "ICANN DOMAINS" translates to what are referred to in the
document as "public domains in unbroken public scope", and "PRIVATE
DOMAINS" translates to names "under islands of private scope" (referred to
in the third paragraph of Section 3 and opening paragraph of Section 4).
In the former case, each name in the ancestry is of public scope through
the public boundary in question.  In the latter case, there are one or more
names of private scope prior to the public boundary in question.  There are
probably shorter/better terms for this.


> I think that this issue, which is separate from the one in the paragraph
> immediately above it, needs a little more elaboration.
>
>
In the document I think you're suggesting that I note that (at least in the
case of the SSL wildcard) the different types of public domains might be
treated differently.


> * The PSL was originally concieved by Mozilla community members, but is
> positioned as a project for the benefit of the whole internet. The fact
> that the canonical copy lives in the Firefox source code is an accident
> of history, and something we are trying to change:
> https://bugzilla.mozilla.org/show_bug.cgi?id=991749
>
>
And I think the list a great contribution.  Thanks!

Thanks also for the pointer to the bug reports.  I was unaware of the
efforts.


> * "The issue of determining relationships between domains that are
> lineally connected (i.e., one is an ancestor of another) and within the
> same public/private scope is not addressed by the PSL"
>
> Actually, I think it is. If a fictional PSL had:
>
> example
> foo.bar.example
>
> Then you would have example being public, bar.example being private, and
> foo.bar.example being public. Or is that not what the quoted sentence is
> saying?
>

The sentence is a bit cryptic.  But what it means is the following.  Given
the following two domains, both "private" as far as PSL processing is
concerned:

sub.foo.example
foo.example

Are the two "related"?  The PSL cannot tell us.  It can only tell us
(assuming entries are correct) that there is no public/private boundary
between them.

Casey