referencing IDNA2008 (and IDNA2003?)

Peter Saint-Andre stpeter at stpeter.im
Thu Oct 21 23:05:32 CEST 2010


On 10/21/10 2:56 PM, Adam Barth wrote:
> On Thu, Oct 21, 2010 at 1:08 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> On 10/21/10 1:25 PM, Adam Barth wrote:
>>> On Thu, Oct 21, 2010 at 12:02 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>>> On 10/21/10 11:56 AM, John C Klensin wrote:
>>>> I think part of the question here is: what will be source and format of
>>>> the inputs to the canonicalization algorithm described in this I-D? And
>>>> how will the outputs be used?
>>
>> Adam, could you perhaps shed some light on that topic? I *think* the
>> input here is the name of the HTTP server to which the user agent sent
>> its request and from which it receives a response containing a
>> Set-Cookie header field.
> 
> That's correct.  It's the thing that gets serialized into the HTTP
> host header (without the port business).
> 
>> The name could be an IPv4 or IPv6 address, a
>> mere machine name (e.g., on a local network), a traditional domain name
>> (containing only ASCII characters), or an internationalized domain name
>> (IDN). For IDNs, the user agent (or the DNS library it uses) might
>> support either IDNA2003 or IDNA2008, so the actual input to the c14n
>> algorithm might be either an A-label or a U-label. However, the output
>> of the algorithm is used only for internal comparison within the user
>> agent, not communication to another entity, so as far as I can see
>> (which, I admit, might not be very far!) the user agent only needs to
>> process the inputs consistently -- it doesn't matter all that much
>> whether it uses IDNA2003 (including the Nameprep profile of stringprep)
>> to do that or whether it uses IDNA2008 (optionally including UTS-46 or
>> RFC 5395 to map characters).
> 
> I believe you can detect how this processing works.  Although the
> value is never sent to anyone, the value is compared against a value
> received over the network.
> 
> IMHO, all of this is a tempest in a teapot.  User agents are going to
> use whatever IDNA algorithm they're going to use.  They're not going
> to use a different one for cookies.  Trying to have the cookie tail
> wag the HTTP dog doesn't sound like a promising approach, hence the
> text in the draft that acknowledges this reality.

In which case, perhaps all we really need is text to the effect that
"when you're comparing two domain names (e.g., comparing a
domain-attribute against a request-host), you need to do so in a way
that ensures that the two strings really are equivalent; either IDNA2003
or IDNA2008 will serve this purpose, and which approach to use is a
matter of implementation".

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20101021/93377101/attachment.bin>


More information about the Idna-update mailing list