[Json] Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT)

[Barry Leiba]

All, can we please take this up in a separate message thread?  It's a
useful discussion to have, but it has nothing to do with my DISCUSS
and comments on the document.

Thanks,
Barry

On Wed, Jan 21, 2015 at 11:22 AM, Nico Williams <nico at cryptonector.com> wrote:
> On Wed, Jan 21, 2015 at 01:04:22PM +0900, "Martin J. Dürst" wrote:
>> >John Klensin
>> >has explained the problem well in Section 2 of
>> >draft-klensin-idna-5892upd-unicode70-03.txt.  You may wish to review
>> >that work, and ask i8n program for a copy of the draft statement,
>> >because it may have security implications on your work, in as much as
>> >i-json is used to pass identifiers.
>>
>> Given that JSON implementations, in contrast to IDNA, compare object
>> member names codepoint-by-codepoint, the much more obvious addition
>> to the security section would be to point out the potential
>> consequences for precomposed/decomposed confusions in general. The
>> chance that this becomes an actual issue is much much higher
>> (although still rather low) in e.g. French or German than in Fula,
>> where Arabic isn't even the main script used for writing the
>> language.
>
> A JSON implementation could normalize as it hashes (if it hashes) the
> keys, though, of course, RFC7159 says nothing about this.
>
> Implementations of form-insensitive Unicode character string comparison
> and hashing functions do exist that basically normalize one _character_
> (not codepoint) at a time.  The reason for doing it this way is
> performance: there's no need to allocate memory dynamically for this,
> and in many cases most characters in the input string(s) have just one
> form or are already in canonical form.
>
>> P.S.: Please note that the comments above don't mean that I'm happy
>> with the inclusion of U+08A1 in Unicode 7.0.0, and that I sincerely
>> hope the Unicode Consortium will weight the problems of identifier
>> confusability higher in their future decisions.
>
> I thought that NFC was closed to new precompositions though new
> precompositions might be added to Unicode.  That is, the NFC form of
> U+08A1 must be the same as the NFD form of U+08A1, which is to say:
> U+0628 U+0654.
>
> Is my memory wrong about that?
>
> Nico
> --
>