[idn] Re: :Re: Last Call: Preparation of Internationalized Strings ('strin

[Simon Josefsson <simon+idn@josefsson.org>]

Patrik Fältström <paf@cisco.com> writes:

> --On 2002-05-30 14.24 +0200 Simon Josefsson <jas@extundo.com> wrote:
>
>> A further security consideration of IDNA could be that whenever such
>> modifications is done in the Unicode standards, they may be exploited
>> and it should be an operational consideration to never register
>> domains, issues PKIX certifices for domains, create Kerberos realms,
>> create PGP keys, etc, for IDNs that contains characters that have
>> their decomposition mapping changed by the Unicode consortium.
>> 
>> It seems as if a modification of this kind occured between Unicode 3.0
>> and 3.1: http://www.unicode.org/versions/corrigendum2.html.
>> 
>> The conclusion here is that this isn't a practical problem -- only one
>> character changed normalization between 3.0 and 3.1 and none between
>> 3.1 and 3.2 AFAIK.  I am more worried about the transcoding problem.
>
> (a) There was one change between 3.1 and 3.2.

So the Unicode consortium has already broken the promise?

The assumption that normalization tables are not changed in a
backwards incompatible way should be stated in the security
considerations IMHO, as the security of IDN depends on that.
Especially if the assumption doesn't hold in all cases.

> (b) If Unicode consortium decides to make a change which "we" (in the form
> of IETF community) don't think is safe enough, then we can choose to _NOT_
> follow the update of Unicode, and stay with the version we are following
> (which include the errors which Unicode Consortium corrects to the new
> version).
>
> I.e. just because the documents point at a specific version of Unicode, we
> have to choice of not following and upgrading. That's the emergency break
> we have.

This means Unicode-based systems will implement two versions of
Unicode (normalization, encoding etc) at the same time.  One
implementation for IDNA, one for the rest of the system that need new
features in Unicode.  That should probably also made more clear; that
an implementator MUST NOT use Unicode 3.2 or any other Unicode version
provided by the system, but must pick Unicode 3.1 (without the
Corrigendum, it seems, since they aren't referenced in IDNA),
otherwise security may be jeopardized.

Again, it would be useful to see a study on how serious these problems
are in practice.  I'm not sure if this (and the transcoding)
discussion is purely theoretical or, at the other extreme, there will
not only be security problems but even interoperability problems
(application A can connect to bank with funny characters but
application B cannot connect, all because of differences in
normalization and/or transcoding mapping tables).

> Still, I (aswell as Unicode Consortium as you can see in their statement
> which you pointed at) don't want to see this happens. The day it does, if
> it does, we can talk again about it.

If indeed there was a change between 3.1 and 3.2, the day has already
come.