Consensus Call Tranche 6 (Character Conversions)

[Simon Josefsson]

"Mark Davis" <mark at macchiato.com> writes:

>>
>> Place your reply here:
>>
>
> NO, they open up a significant security and interoperability hole.

I found Mark's discussion convincing, so it is a NO for me.

Generally, I think these documents must discuss more about stability and
security consequences than they do today.  I am sorry that I don't have
more spare time to propose actual text.

/Simon

>
>>
>>
>> COMMENTS:
>>
>
> 1. Section 4.2 of Protocol could be interpreted as only requiring Unicode
> Strings to be in NFC *if* they resulted from conversion from a legacy
> character encoding, rather than requiring it also of Unicode strings that
> did not result from such an encoding. The text needs to be fixed so that it
> is very clear that the NFC requirement is also true of strings that did not
> require conversion, as is the intent. I don't think this part is
> controversial -- it just makes it clearer and more consistent with 5.5.
>
> 2. In terms of validation (the subject of this tranche), the second
> paragraph of 4.2 and the section 5.3 open up an unpleasant interoperability
> and security hole, since it places no limits on the mappings that can be
> applied to forbidden characters.
>
> Take the following 3 strings:
>
>    1. HTTP://SCHAFFER.DE
>    2. HTTP://SCHÄFFER.DE <HTTP://xn--schffer-7wa.DE>
>    3. HTTP://SCHÆFFER.DE <HTTP://xn--schffer-oxa.DE>
>
> This section allows any implementation to map *any* of these to *any* of the
> following:
>
>    1. http://schaeffer.de
>    2. http://schäffer.de <http://xn--schffer-7wa.de>
>    3. http://schaffer.de
>
> That is, one implementation could map #2 to #3, while another implementation
> could map #2 to #1. Or, for that matter, many other variants. It allows YENİ
> KAPI.TR to be mapped to any of yenikapı.tr <http://xn--cfa.tr>,
> yenıkapi.tr, or other dotted vs dotless i variants. As
> a matter of fact, a conformant implementation could map
> РУССКИЙ.RU<http://xn--h1acbxfam.RU>
>  to sarapalin.ru, since no limits are placed on the kinds of mappings that
> can be done.
>
> This was also brought up before.
>
> Mark
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update