SASLprep200x

[Martin Duerst]

At 09:05 07/01/05, John C Klensin wrote:

>But, beyond that, the two may diverge and it may be desirable to
>make the profiles a little "thicker".  For example, if we could
>figure out how to prohibit mixed-script labels in IDNA and get a
>lot of leverage from it, we would probably do so.  I think it is
>fairly clear at this point that we cannot, so this example is
>probably moot, but it may still make a good illustration.   But
>we might want to actually encourage script-mixing in
>pass-phrases and some other security credentials, just as we
>encourage odd mixtures of case, numerals, and assorted symbols
>and punctuation in all-ASCII environments today.  The latter are
>illustrative of a difference that already exists: ASCII special
>characters are common and encouraged in passwords and
>pass-phrases, but prohibited in domain name labels by the LDH
>rule.

You can certainly encourage mixed-script passwords, but you
will only get so far. Changing the script you input is usually
visible on-screen. It takes additional keystrokes to do it.
If a script change isn't visible on-screen, you have blind
multi-modality (i.e. whoever inputs the password has to
rember very well in which script input mode they currently are).
Some scripts are notoriously difficult to use for passwords,
because they don't have a simple keystroke-to-character
relationship (when inputing Japanese, what you get may
depend on what kind of words you used just before, which
is okay when you can see and fix it, but not for passwords).

Similar caution applies for exotic symbols. Immagine a smiley
in a password: Very effective, because who would guess that?
Also, you may have figured out how to input one on your local
machine. But then immagine being somewhere else, and having
to figure out how to input a smiley on an unknown machine.
And for passwords, you won't want to ask your host how to
do it :-).

What will remain are probably mostly symbols that are potentially
available by default on keyboards for a specific script, the
same way the symbols on Western keyboards can be used for
ASCII passwords now.


>We may also not be able to make a general rule here because the
>right conventions for passwords may not be the right conventions
>for credential or certificate names.

My guess would be "very much so indeed."

>The optimal requirements
>for latter may be somewhat closer to the optimal requirements
>for IDNs.  Or they may not.

I guess they are. There is still a big difference between
IDNs and credentials/certificate names, because IDNs are
much more visible to everybody.

Regards,    Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst at it.aoyama.ac.jp