Re: [Emu] Revised sections for Issue #18 (Internationalization)

[Simon Josefsson <[e-mail]>]

Alan DeKok <[e-mail]> writes:

> Simon Josefsson wrote:
>> Should we suggest that passwords are sent over the wire at all?  In good
>> systems that should be the exception.
>
>   It is widely deployed today with TTLS.  I think that allowing this
> practice to continue is a requirement.

I agree, but that does not necessarily mean that
passwords-sent-over-the-wire and passwords-sent-hashed must have the
same internationalization treatment or considerations.

>> 1) Usernames.  Should be sent over the wire as-is, or possibly
>> Net-UTF-8.  It is not clear to me that the even the weak NFC part of
>> Net-UTF-8 is always a good idea for usernames, you could just send the
>> username as-is and require that COMPARISONS are done in a way that
>> reduces ambitious.
>
>   Ouch.  I fundamentally disagree.  See RFC 4282, and my attempt to
> update it, based on real-world deployment experience:
>
> http://tools.ietf.org/html/draft-dekok-radext-nai-00
>
>   My document explains why it's difficult (i.e. impossible) for third
> parties to "normalize" the data.

Interesting!  It is good to see work in this area, and your reasons
appears good to me.  I believe it is desirable to reduce the amount of
string normalization that happens, and instead use comparison-rules when
possible, but sometimes normalization is required for one reason or the
other.  As soon as normalization rules are suggested, I believe it is
worthwhile to evaluate why comparison-rules are not sufficient, and your
document address that.

>> The problem with normalization early is that you end up with a interop
>> problem where both the client and server needs to implement the exact
>> same normalization algorithms for things to be robust.  If normalization
>> only happens in one implementation, things will be predictable.
>
>   RFC 5198 specifies a normalized form.  If two implementations
> "normalize" to the RFC 5198 form differently, one of them is wrong.

Sure, but see section 4 of RFC 5198.  If it happens that NFC backwards
compatibility is broken, you end up with the interop problem.  This has
happened before for NFKC which has caused (theoretical) interop problems
for IDNA and SASLprep -- if two implementations of RFC 3454 use
different Unicode versions, they don't necessarily interop.

/Simon