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

["Soobok Lee" <lsb@postel.co.kr>]

If  new version of Unicode is not proved to be safe enough, we have choices

  1) wait until newer , correc, mature and stable version of Unicode come out

  2) go with previous version of Unicode, regardless of whether the version has errors or not.

if we choose 2), we have the following chance of failures and security concerns

  NFKC3.1(CaseFold3.1(IDN1)) != NFKC3.2(CaseFold3.2(IDN1))
  NFKC3.1(CaseFold3.1(  NFKC3.2(CaseFold3.2(IDN1))  ))  !=  NFKC3.2(CaseFold3.2(IDN1))

This may happen when ,for example, Canonical XML (which use NFC) facility applies new NFC3.2
  to IDN-containing tag values ,and that canonicalized IDN go through
    NFKC3.1 in further nameprep/ACE coding.

This issues were raised at the time of IDN WG last call,  3 months ago.

Soobok Lee


----- Original Message -----
From: "Patrik Fältström" <paf@cisco.com>
To: "Simon Josefsson" <jas@extundo.com>
Cc: <idn@ops.ietf.org>
Sent: Thursday, May 30, 2002 10:20 PM
Subject: [idn] Re: :Re: Last Call: Preparation of Internationalized Strings ('strin


> --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.
>
> (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.
>
> 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.
>
>    paf
>