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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf