[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt
Thanks, those are very good points. A few notes on your proposed
changes to the security considerations:
At 8:20 PM +0200 5/27/02, Simon Josefsson wrote:
>+Domain names are used by users to identify and connect to Internet
>+servers. The security of the Internet is compromised if a user
>+entering a single internationalized name is connected to different
>+servers based on different interpretations of the internationalized
>+domain name.
That seems fine, and expands from what we had before to cover your
larger concern.
> When all systems use ASCII or Unicode, different
>+interpretations are not allowed in this specification.
I think that goes too far. A user system that "uses Unicode" could
still make wrong judgements between the keyboard and the encoding.
For example, on the Mac, typing Option-8 inserts a bullet character.
There are many different bullet characters in the Unicode character
repertoire, so entering a host name that includes one of those bullet
symbols might get the wrong result. Thus, I'd rather not use that
last sentence.
>+When involved systems use non-ASCII and non-Unicode characters (such
>+as ISO-8859-1 and ISO-2022-JP, which are common on the Internet),
We're not concerned with what is common on the Internet, but what is
common in systems.
>+however, this specification leaves the transcoding problem up to the
>+application. Thus there can not be any assurance that two
>+applications will not implement different transcoding rules. When two
>+applications implement different transcoding rules, they will
>+(assuming both domains exists) contact different servers. Note that
>+the problem can not just easily be solved by using a security protocol
>+such as TLS to identify and authenticate to end points, unless these
>+protocols have already solved the problem which IDNA is trying to
>+solve.
That seems like a good addition.
--Paul Hoffman, Director
--Internet Mail Consortium