referencing IDNA2008 (and IDNA2003?)

[Adam Barth]

On Fri, Oct 22, 2010 at 11:59 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> On 10/22/10 12:38 PM, Adam Barth wrote:
>> I'm not sure I quite understood everything that was mentioned during
>> this thread.
>
> Don't worry, it takes a long time to grok i18n, let alone grok it in
> fullness. I for one feel like I'm always standing at the foot of the
> mountain and not making any progress toward the summit...
>
>> Concretely, here's what cookies need to do:
>>
>> 1) We receive a sequence of octets from the network, which we convert
>> to lower case.  Let's call this X.
>> 2) We have a URL that the user agent has used to generate an HTTP
>> request.  Let's call the host name component of this URL Y.
>> 3) X is a sequence of octets that's has all the crazy xn-- stuff.
>
> Yep, it's an A-label.
>
> Possible trap: is the domain-value provided by the HTTP server in the
> Set-Cookie header really an A-label (if the domain is an IDN)?

I believe so.  Or rather, I think they'll need to be to work properly
today.  We could run some experiments to be sure, but I was told that
putting non-ASCII characters in HTTP headers is bad news bears.

>> 4) We need to transform Y to the crazy xn-- form to see if it's in
>> some relation to X.
>> 5) For our sanity, we'd like to use octet-by-octet comparison, without
>> reference to any kind of folding (e.g., case-folding, IDNA-folding,
>> etc).
>
> One conclusion from this thread is that it will come to you already
> folded (lowercase, in simplified terms) because that's the way an
> A-label is.

Great.

>> As an added constraint, we don't feel its our place to mandate to user
>> agents whether they ought to use IDNA2003 or IDNA2008.  User agents
>> are free to make the decision independently of what the cookie spec
>> says.  You should feel free to lobby them one way or another, but
>> we're not going to impose that requirement on them in this document.
>
> Right -- the user agent should use whatever IDNA technology it already
> has, although we hope that they'll migrate to IDNA2008 (but that hope is
> out of scope for the cookie spec = draft-ietf-httpstate-cookie).
>
>> My understanding is that the text in the spec meets our requirements.
>> If that's not the case, please let me know.
>
> Here's where our understandings diverge. :)

Ok.  :)

> My reading
> <http://www.alvestrand.no/pipermail/idna-update/2010-October/006770.html> of
> this thread is that in the cookie spec it would be best to proceed as
> follows...
>
> 1. Expunge the concept of a "canonicalized host name" and thus Section
> 5.1.2.
>
> 2. In Section 5.3, wherever we say this:
>
>      If the domain-attribute is identical to the canonicalized
>      request-host:
>
>   Change it to something like this:
>
>      If the domain-attribute and the request-host are identical
>      according to the domain comparison rules of the implementation,
>      including comparison of internationalized domain names (IDNs)
>      using either IDNA2003 or IDNA2008:

This text seems symmetric.  The user agent needs to know that it
should not apply the U-label => A-label conversion to the
domain-attribute but that it should apply the conversions to the
request-host.

>   Similarly change this:
>
>      Set the cookie's domain to the canonicalized request-host.
>
>   To:
>
>      Set the cookie's domain to the request-host.
>
>   (I don't see a strong need to "canonicalize" it before storing it.)

We need to canonicalize it before storing to make the rest of the
storage model work out properly.  In particular, we count the number
of cookies that share common host names, etc.  Rather than having to
do IDNA-folding comparisons everywhere, we canonicalize and then do
simple octet-comparisons.

>   Etc.
>
> 3. Remove Section 6.3 entirely.
>
> Adam, do you read this thread differently?

That approach doesn't meet requirement (5).  In particular, this text
uses IDNA-folding comparisons instead of first canonicalizing and then
applying octet-by-octet comparisons.

Adam