W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: Referencing ETLD+1.

From: Patrick McManus <mcmanus@ducksong.com>
Date: Thu, 10 May 2018 15:19:55 +0000 (UTC)
Message-ID: <CAOdDvNq=mLbKERze02z1MZh7j0h6sMV5WC+3ozwY1h7fK_muSg@mail.gmail.com>
To: Patrick McManus <mcmanus@ducksong.com>
Cc: Eric Rescorla <ekr@rtfm.com>, HTTP Working Group <ietf-http-wg@w3.org>, IETF Tokbind WG <unbearable@ietf.org>, Alissa Cooper <alissa@cooperw.in>
A further refinement if you just want to define etld+1, (but I think you
need the previous one for 'how to bind cookies' - but that might just be a
distraction for you.)
https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#terminology

"The term “public suffix” is defined in a note in Section 5.3 of [RFC6265]
<https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#RFC6265>
as “a domain that is controlled by a public registry”, and are also know as
“effective top-level domains” (eTLDs). For example, example.com’s public
suffix is com. User agents SHOULD use an up-to-date public suffix list,
such as the one maintained by Mozilla at [PSL]
<https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#PSL>.

An origin’s “registered domain” is the origin’s host’s public suffix plus
the label to its left. That is, for https://www.example.com, the public
suffix is com, and the registered domain is example.com. This concept is
defined more rigorously in [PSL]
<https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#PSL>,
and is also know as “effective top-level domain plus one” (eTLD+1)."




On Thu, May 10, 2018 at 5:01 PM, Patrick McManus <mcmanus@ducksong.com>
wrote:

> Perhaps Mark or Mike West will have a better idea, but I think what you
> need is in the active 6265bis work: https://httpwg.org/http-
> extensions/draft-ietf-httpbis-rfc6265bis.html#storage-model
>
> 6265bis is making very slow (but steady) progress - taking a normative
> dependency on its completion would have, imo, a predictable consequence of
> blocking publication of token binding for quite a while. While there hasn't
> been a consensus call on the language in that section of 6265bis there is
> no controversy around it (other than the normal iterative vs declarative
> style questions)- so my advice would be to use it as a template for
> describing what you need and engaging the author and http wg for review and
> any updates that might be required.
>
> Sorry I don't have a better pointer at hand. Perhaps someone will come up
> with a normative source.
>
> -P
>
>
>
>
> On Thu, May 10, 2018 at 4:26 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>> Hi HTTP WG members,
>>
>> https://tools.ietf.org/html/draft-ietf-tokbind-https-15 says:
>>
>>    The scoping of Token Binding key pairs generated by Web browsers for
>>    use in first-party and federation use cases defined in this
>>    specification (Section 5), and intended for binding HTTP cookies,
>>    MUST be no wider than the granularity of "effective top-level domain
>>    (public suffix) + 1" (eTLD+1).  I.e., the scope of Token Binding key
>>    pairs is no wider than the scope at which cookies can be set (see
>>    [RFC6265]), but MAY be more narrow if cookies are scoped more
>>    narrowly.
>>
>> Alissa points out that somewhat surprisingly 6265 doesn't actually
>> say this. We obviously want the binding to be tied to eTLD+1, so
>> the question is really how we write this up. Could the HTTP WG provide
>> some guidance here?
>>
>> -Ekr
>>
>>
>>
>
Received on Thursday, 10 May 2018 15:20:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:20 UTC