[Json] Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT)
nico at cryptonector.com
Wed Jan 21 17:22:10 CET 2015
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
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:
Is my memory wrong about that?
More information about the Idna-update