Re: [idn] Re: Fwd: Unicode letter ballot

["Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>]

Simon Josefsson <jas@extundo.com> wrote:

> Authentication identity "admin", authorization identity U+4711,
> password X.  For the argument, let's say U+4711 decomposes into U+1234
> in Unicode 3.2 but is later changed to U+4321.
>
> The SASL library, acting as a proxy in front of the application
> software, implements the current libstringprep correctly.  It checks
> that admin's password is X and that he is authorized to log in as
> U+1234 (which is the result after stringprep of U+4711, which was sent
> because the client hadn't been updated to use stringprep, which should
> cause no problem) and says OK to the application.
>
> Now, in 1a the application is using updated tables from a more recent
> stringprep that incorporates the fixed decomposition mapping, causing
> it to admit the user to an account U+4321.  This is bad.
>
> In 2a, the application sees that the characters are deprecated due
> to its decomposition mapping changed, and rejects the user.  This is
> good.

It looks like the security hole in 1a stems from the existence of two
Unicode strings X and Y such that now Stringprep(X) != Stringprep(Y)
(so that two distinct accounts for X and Y can be created), but later
(after the update of the decomposition mappings) Stringprep(X) ==
Stringprep(Y), so the two accounts will get confused.

But I think the same phenomenon can happen with 2a.  There are CNS
11643 strings A and B such that now Stringprep(CNS11643toUnicode(A))
!= Stringprep(CNS11643toUnicode(B)) (so that two distinct accounts for
A and B can be created), but later (after the deprecation and addition
of Unicode characters, and the subsequent update of CNS11643toUnicode
to use the new Unicode characters instead of the deprecated ones)
Stringprep(CNS11643toUnicode(A)) == Stringprep(CNS11643toUnicode(B)),
so again the two accounts get confused.  No deprecated characters are
going to be seen and rejected, because no CNS 11643 characters are
deprecated, and the deprecated Unicode characters do not appear in the
new CNS11643toUnicode table.

An approach that would really avoid this pitfall would be to deprecate
these characters not only in Unicode, but also in CNS 11643 and any
other character sets that contain them, and create new characters
in all these character sets, and leave all the mappings of the old
deprecated characters unchanged in both the Unicode database and the
WhateverToUnicode tables.

AMC