Re: IETF ldapbis WG Last Call: draft-ietf-ldapbis-user-schema-05.txt

[Michael Ströder <michael@stroeder.com>]

Ramsay, Ron wrote:
> Yes, thanks, I did see the discussion. I am just saying that I wasn't
> moved by it. I don't see how you can actually talk meaningfully about
> 'textual' passwords

I would define 'textual' passwords as passwords manually typed in by a user
on the keyboard or a similar character-based input device. More formally one
could define textual passwords as a character sequence with a known
character set and encoding.

As current practical experience shows arguing that you can stuff anything
(here an arbitrary character sequence and encoding) into an Octet String
leads to bad interoperability of LDAP applications.

At the moment the only almost safe way is to limit passwords to ASCII since
ISO-8859-1 and UTF-8 both used by some applications share the very same byte
encoding for ASCII. But there might be users who don't have a single ASCII
character on their input device...and there might be an application stuffing
UTF-16 into the password.

> - do you scan a password first to see if it is valid
> UTF-8 and, if so, convert it to unicode and apply stringprep?

No, off course!

Usually you can differentiate in the LDAP application where your password 
comes from. Most times the application receives the password from the user 
by some input device/input form etc. And then you know which character set 
it is and you can easily convert it to UTF-8.

> I can't get excited about that.

Let us clarify things:
Octet Strings for passwords are used because there could be a "locally 
defined" mechanism for using arbitrary Octet Strings in Simple Bind (e.g. 
automatically generated tickets, scanned mouse moves, biometric data or 
similar). In this scenario an LDAP application will likely not interact with 
a human user through a keyboard to ask for a password. This is still 
possible with Kurt's recommendation.

Ciao, Michael.