[idn] Re: :Re: Last Call: Preparation of Internationalized Strings

[simon+idn@josefsson.org]

[Resending with different From: address.]

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

> --On 2002-05-30 12.16 +0200 Simon Josefsson <simon+idn@josefsson.org> wrote:
>
>> This is interesting -- has the Unicode consortium promised to always
>> update the CK normalization tables in a forward compatible way?
>
> Yes.

The reference for that statement seem to be (correct me if I'm wrong)
http://www.unicode.org/unicode/standard/policies.html:

,----
| Normalization. Once a character is encoded, its canonical combining
| class and decomposition mapping will not be changed in a way that will
| destabilize normalization.
`----

Which looks good.  However, reading on:

,----
| The decomposition mapping may only be changed at all in the following
| _exceptional_ set of circumstances:
| 
| + when there is a clear and evident mistake identified in the Unicode
|   Character Database (such as a typographic mistake), and
| 
| + when that error constitutes a clear violation of the identity
|   stability policy (#4), and
| 
| + when the correction of such an error does not violate constraints (a)-(d)
`----

So it appears as if the statement isn't strictly true?

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.