- From: Richard Gibson <richard.j.gibson@oracle.com>
- Date: Thu, 10 May 2018 11:35:16 -0400
- 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>
- Message-ID: <88480b28-97bf-f152-4a5b-f4d33eb89934@oracle.com>
There may also be an opportunity to align with the DNS specifications, which have the analogous concept of "delegation-centric zone" (cf. https://tools.ietf.org/html/rfc7719#page-16 ). On 05/10/2018 11:19 AM, Patrick McManus wrote: > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__httpwg.org_http-2Dextensions_draft-2Dietf-2Dhttpbis-2Drfc6265bis.html-23terminology&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=yzrLlKRxElIcQkuxiEY3pvQZ3pbY0S-TG1OKbsNhYLQ&s=Qj8OTv1qz-idFYIn2uzeNNOzyPvQvw502q4GKNUmQNE&e=> > > "The term “public suffix” is defined in a note in Section 5.3 of > [RFC6265] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__httpwg.org_http-2Dextensions_draft-2Dietf-2Dhttpbis-2Drfc6265bis.html-23RFC6265&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=yzrLlKRxElIcQkuxiEY3pvQZ3pbY0S-TG1OKbsNhYLQ&s=cf5d9JvDL4XR2S_dh6YUyLoFhrAp3dKQHbFUFuSMTfo&e=> > as “a domain that is controlled by a public registry”, and are also > know as “effective top-level domains” (eTLDs). For example, > example.com <http://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://urldefense.proofpoint.com/v2/url?u=https-3A__httpwg.org_http-2Dextensions_draft-2Dietf-2Dhttpbis-2Drfc6265bis.html-23PSL&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=yzrLlKRxElIcQkuxiEY3pvQZ3pbY0S-TG1OKbsNhYLQ&s=JTwXYs4coubIOQzP7nVBzy43CP-YkTMCyEWZyV7cq7c&e=>. > > > 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 > <http://example.com>. This concept is defined more rigorously in [PSL] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__httpwg.org_http-2Dextensions_draft-2Dietf-2Dhttpbis-2Drfc6265bis.html-23PSL&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=yzrLlKRxElIcQkuxiEY3pvQZ3pbY0S-TG1OKbsNhYLQ&s=JTwXYs4coubIOQzP7nVBzy43CP-YkTMCyEWZyV7cq7c&e=>, > 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 > <mailto: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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__httpwg.org_http-2Dextensions_draft-2Dietf-2Dhttpbis-2Drfc6265bis.html-23storage-2Dmodel&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=yzrLlKRxElIcQkuxiEY3pvQZ3pbY0S-TG1OKbsNhYLQ&s=JhUKutYkjHg6Hhfxm__XggYezkp5cNwuIX8zd3o5tFQ&e=> > > 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 > <mailto:ekr@rtfm.com>> wrote: > > Hi HTTP WG members, > > https://tools.ietf.org/html/draft-ietf-tokbind-https-15 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtokbind-2Dhttps-2D15&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=yzrLlKRxElIcQkuxiEY3pvQZ3pbY0S-TG1OKbsNhYLQ&s=I3FBbAaHs50ovXXf_o_YdfHiq_y2X0-rKRSzSV8oRtE&e=> > 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:36:01 UTC