Re: Text change for wsc-ui Petnames

On 2008-09-17 17:29:12 +0000, Close, Tyler J. wrote:

>> I fear there's some confusion going on here. The "effective
>> TLD" is limiting the level up to which labels can be dropped
>> from an origin, to take into account effects like co.uk.  So,
>> the "effective TLD" of www.bbc.co.uk is co.uk.

> Based on my reading of the Mozilla documentation, I think the
> concept you're discussing is called "public suffix".

Well, strictly speaking, "effective TLD" isn't really showing up
(except as the name of the service); "public suffix" is probably the
right term there, right.

> That same documentation also uses the term "base domain" for the
> concept I am thinking of. 

Let's stick to that for the moment, even though using it in the spec
will draw the ire of the DNS community.

> The base domain concept is what I meant and what I have
> implemented.

>> (The navigation policy depends on (a) the origin, and (b)
>> client/child relationships between different windows.  It's
>> different from the policy that governs other object access. The
>> only point where the "effective TLD" might come in here is in
>> limiting what suffixes of its current value document.domain
>> might be set to.)

> Which in turn determines what frames you can script. For example,
> pages and one.example.org and two.example.org can shorten their
> document.domain to example.org and so script each other.

We're saying the same thing in different words here, I think. Yes,
the "base domain" is the shortest domain name that document.domain
can ever be shortened to, but what governs the policy itself is
document.domain (plus the various browsing context related
complexities for navigation).

>> I suspect that you mean the "base domain" (in the lingo of the
>> Firefox documentation).  Either way, I'm concerned that we'd
>> lose any benefits that the petnames proposal would currently
>> offer in the self-signed case -- effectively, by depending on
>> domain names in certificates, the usefulness of the petname
>> proposal would be limited to domain-validated certificates, no?

> No. In fact, the current text for petnames explicitly says that
> the information from the certificate MUST NOT be used for pinned
> self-signed certificates. 

Whooops, I had a much older iteration of the proposal in mind.

So, in the case of a binding to a site that has shown a pinned
self-signed certificate, the petname is shown when:

- the destination to which the petname was bound is navigated to, AND

- a certificate pinned to the destination OR a domain validated
  certificate is shown

... and the change that you propose would actually only affect the
DV (and better) case, by dumping the association with wildcards
that's currently in there.

I.e., the scope of petnames would only ever shrink if we adopted
your change.

> These always used the hostname from the page's URL. That's
> unchanged in the new proposal. Obviously we can't trust
> information taken from a self-signed certificate.  We can only
> trust the binding between a hostname and a certificate that the
> user specified when pinning the certificate. It's the bound
> hostname that we key off of, not anything contained in the
> certificate.

Right.

Apologies for the misunderstanding.

The remaining question is then, why do you propose using the "base
domain" instead of the domain name?

Thanks,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Wednesday, 17 September 2008 17:50:41 UTC