On Fri, 21 Apr 2006, Simon Josefsson wrote:
On the other hand, potential security issues caused by instability in
the original (erroneous) definition are at least as serious as the
potential incompatibilities caused by the change.
Can you expand on this?
Can you give an example of how a system that contain components that
all properly implement StringPrep and the NFKC from Unicode 3.2, that
is without the PR-29 fix, have a serious security issues?
I haven't seen any such example. I believe examples can be
constructed when one StringPrep implementation in a system implement
the original Unicode 3.2 NFKC semantics and one component implement
the "fixed" NFKC. If you don't see it, I can try to produce a
complete scenario.
The problem is that the original NFKC isn't just "different"; it's
_unstable_. That is, there exist strings for which you get different
results depending on _how many times_ you apply NFC or NFKC. Systems
which use normalization to ensure that a security-related identifier is
always represented in the same way may break in the face of an unstable
normalization.
Of course, this only happens for the same highly-unlikely sequences...
incompatibilities, despite that the change is not meant to modify
how the version of Unicode that IDNA reference is implemented.
Except I still think you're trying to put words in the UTC's mouth that it
did not intend to say. As I understand it, a corrigendum like this _is_
intended to modify the existing standard, including existing references.
It's roughly the equivalent of RFC errata - they're saying "there's a bug
in the text; it says X but we always meant for the spec to be Y".
Now, you can argue that the IETF should take the position that any of its
specs which refer to Unicode 3.2 and were published prior to corrigendum
#5 should be construed to mandate the use of the original, flawed
algorithms for NFC and NFKC. But you seem to be taking the position that
the _Unicode Technical Committee_ had that intent with respect to existing
users of its standard, and I don't think that's true.
I also don't think the IETF should explicitly mandate the use of the
flawed algorithm by implemntations of preexisting specs. As it turns out,
one of the justifications for making the retroactive change to Unicode was
that a significant number of implementations, including whatever reference
or test implementation they used when writing the spec _and_ the sample
code which appears _in_ the spec, get it right.
-- Jeff
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf