Jeffrey Hutzelman <jhutz(_at_)cmu(_dot_)edu> writes:
On Thursday, April 20, 2006 03:05:43 PM +0200 Simon Josefsson
<jas(_at_)extundo(_dot_)com> wrote:
An example of the type of change that appears to be just a small
correction from one perspective but may be problematic from another
was the correction to the normalization definition in 2004 [Unicode-
PR29].
I believe it should be noted here that this was discovered after
Unicode 3.2 was published, and consequently doesn't apply to the
original Unicode 3.2. I.e., change 'PR29].' into:
Corrigendum #5, which fixes the inconsistency causing the problem
described in PR29, _does_ apply to versions of Unicode from 3.0.0
through 4.0.1, including 3.2.
Right, what I meant was that it does not apply _retroactively_. The
Unicode 3.2 NFKC steps as referenced by StringPrep does not include
the PR-29 fix.
It is also worth noting that even for implementations which were based
on the (normative but incorrect) text of the original 3.2 spec rather
than the (non-normative but correct) sample code, changing to the
corrected model will not "break backwards compatibility in Unicode for
most European languages", because those combining sequences which
trigger the inconsistency "do not constitute well-formed text in any
known language" (Unicode corrigendum #5).
You are quoting me out of context. I believe the proposed changes in
section 4.3 of the IAB document will break European languages. I am
well aware that the PR-29 problem doesn't apply to well-formed text,
but only specially crafted sequences.
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.
I suggest that folks who are interested in this issue read PR29 for
themselves, rather than relying on Simon or myself for information.
Always a good idea.
I suggest replacing 'incompatibilities.' with:
incompatibilities, despite that the change does not apply to the
version of Unicode that IDNA uses.
This statement would be incorrect. The statement _does_ apply to the
version of Unicode that IDNA uses.
Ok, right, but it isn't included in the specific reference in IDNA,
and thus meant to not apply for StringPrep implementations. Allow me
to change my suggestion to:
incompatibilities, despite that the change is not meant to modify
how the version of Unicode that IDNA reference is implemented.
Thanks,
Simon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf