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

[Alan DeKok <[e-mail]>]

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.

> 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.

>  There are some indication that the algorithm of
> comparing two strings for equality is simpler to make robust and
> ambigious-free than an algorithm that normalize strings.

  Yes.  The systems which do end-user input likely have enough
information to normalize the data.  No one else does.  As a result,
everyone else should compare the two strings for equality.  They should
not normalize the strings.

> 2) Passwords sent to servers.  This has similar properties as 1) but
> there could be differences in how they are treated.
> 
> 3) Passwords sent to servers only in hashed form.  This has stricter
> normalization requirements than 1) and 2) -- NFC is most certainly
> needed, and probably something more, similar to SASLprep but preferably
> without some of the problems that SASLprep has.

  I beleive that (2) and (3) are the same case.  For (3), we will end up
checking for:

	hash(p1) == hash(p2)

  For strong hashes, the simplest way to ensure this is true is if:

	p1 == p2

> 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.

  Alan DeKok.