"Joseph Salowey (jsalowey)" <jsalo...@cisco.com> writes:
> "4.3.6. Internationalization of Display Strings
>
>
> The payload MAY provide a standard attribute format that supports
> international strings. This attribute format MUST support encoding
> strings in UTF-8 [RFC3629] format. Any strings sent by the server
> intended for display to the user MUST be sent in UTF-8 format and
> SHOULD be able to be marked with language information and adapted to
> the user's language preference as indicated by RFC 4646 [RFC4646].
> Note that in some cases, such as when transmitting error codes, it
> is acceptable to exchange numeric codes that can be translated by the
> client to support the particular local language. These numeric codes
> are not subject internationalization during transmission. "
>
> "4.5.2. Internationalization
>
>
> The password authentication exchange MUST support user names and
> passwords in international languages. It MUST support encoding of
> user name and password strings in UTF-8 [RFC3629] format. The method
> MUST specify how username and password normalization is performed in
> reference to SASLPrep [RFC4013] or Net-UTF-8 [RFC5198].
There is some discussion about SASLprep on the i...@ietf.org mailing
list right now that you may want to review.
One of my experiences with SASLprep is that it makes sense to normalize
passwords (because they are input to hashes so some ambiguities needs to
be resolved) but it does not always make sense to normalize usernames.
Some characters that may occur in a username are converted to other
characters by SASLprep, a simple example is SASLprep('ยช') = 'a.' So
using SASLprep for usernames may prevent otherwise reasonable usernames
from being usable.
Another concern with SASLprep is that it is based on Unicode 3.2 and
does not support newer Unicode versions.
Perhaps you want to consider an approach where passwords are normalized
using Net-UTF-8 and usernames are sent as-is but mandate that
username-to-username comparisons use Net-UTF-8 on both strings before
comparing them.
Username and passwords strings are somewhat different beasts, and it
does not necessarily make sense to use the same normalization or
comparison algorithms for both strings.
/Simon
> Any strings sent by the server during the password exchange and
> intended
> for display to the user MUST be sent in UTF-8 format and SHOULD be
> able to be marked with language information and adapted to the user's
> language preference as indicated by RFC 4646 [RFC4646]. Note that in
> some
> cases, such as when transmitting error codes, it is acceptable to
> exchange
> numeric codes that can be translated by the client to support the
> particular local language. These numeric codes are not subject
> internationalization during transmission. "
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
