Re: userPassword and non-ASCII characters

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:46 AM 5/22/2003, Peter Marschall wrote:
>Hi,
>
>On Thursday 22 May 2003 03:05, Kurt D. Zeilenga wrote:
>> If the application knows the password is textual, it should
>> 1) trancode the string to Unicode, 2) prepare the string for
>> matching (by the octetStringMatch rule), 3) and encode using
>> UTF-8.  To prepare the string, minimally normalize the
>> string to Form KC.   Presently, the IETF is considering
>> recommending that the SASLprep algorithm here.  See
>> draft-ietf-sasl-saslprep-xx.txt for details (available
>> at http://www.ietf.org/).
>
>Could you give an example ?
>How would the string "Hägar" (the 2nd character is the german umlaut-a)
>look like after each of the steps 1 - 3 ?

The 1st and 3rd steps are no different from those you would use
to store "Hägar" in an attribute of Directory String syntax.

For this string, SASLprep is a no-op.  That is,
SASLprep(Unicode("Hägar")) yields Unicode("Hägar").

Now, if instead the user had inputted the "ä" as "a"+umlaut,
then we see normalization kick in.

>I have tried to do it myself (Please correct me if/where I'm wrong)
>1) "Hägar" -> "Hägar"
>   This should hold for most characters  in ISO-8859-X, X = 1 .. 15
>   except for super/subscripts which should be replaced by their
>   "regular" counterparts  [Example: "¹" -> "1"])
>   and fractions which should be replaced by the characters forming
>   them  [Example "¼" -> "1/4"])

I believe ISO 8859-1 is transcoded directly for all code points.
"¼" -> "1/4" would be done in step 2.

>2) "Hägar" -> "Hägar"
>   What do I need to do here ?

As noted above, SASLprep is a no-op for this string.

>3) "Hägar" -> "Hägar" (this is "H\xC3\xA4gar")
>Is this correct ?

Ask iconv.

>What do I do if I do not know whether the password is textual ?

Pass the value as is.

>What do I do if I want to search the password (for editing) or if I want to 
>compare the password with the one on the LDAP server (ldapcompare) ?

If textual, apply same algorithm.

>How can one application that retrieves the password know 
>the "textuality" of a password that another application has generated ?

It doesn't.  That's why applications should prepare textual
values they provide to the directory so that other applications
(and the directory) can just treat them as octet strings.

Kurt