Subject: RE: Revisited: NON-ASCII chars in userPassword

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 31 Oct 2001 19:10:59 +1100

Yes, I was thinking more clearly AFTER I wrote the message than during!
Latin-1 has to be transcoded into UTF-8. I don't know about 'passwords',
though, as I don't see that they need be words from some language, unless
this is the meaning you would like LDAP to give them. I don't think UTF-8
helps anyway as the password may not have a representation in another
language and so would have to be treated as a sequence of bytes. The fact
that the bytes are syntactically UTF-8 is of no help.

To put it another way, if the password is e'te' (e-acute t e-acute), the
only way I could send it to a server would be to pass an opaque octet string
as (obviously) I cannot type it in.

-----Original Message-----
From: Michael Ströder [mailto:[email-masked]]
Sent: Wednesday, 31 October 2001 18:42
To: Ramsay, Ron
Cc: [email-masked]
Subject: Re: Revisited: NON-ASCII chars in userPassword

"Ramsay, Ron" wrote:
> 
> Personally, I can't see the connection between LDAP credentials and user
> logons. And what is a user logon?

I'm not sure what you mean. I'm solely talking about simple bind:
You need a bind DN and a password credential for the "logon". The
syntax of the bind DN is already well-defined in RFC2253. The syntax
of the password is not. It should be mandated to be UTF-8 encoded
ISO-10646 Unicode for clients having a chance to be interoperable.

Today e.g. Netscape Navigator sends ISO-8859-1 and MS Outlook sends
UTF-8 encoded Unicode.

> It would be interesting to see the data generated by a logon in Japan.

No problem with UTF-8 encoded Unicode.

> I say, leave it alone. It is a piece of data that a client provides to
> authenticate to a server.

Yes, that's exactly what I'm talking about. The client has to know
in advance which character set and encoding to use for passwords.

> PS Isn't 8859-1 a subset of UTF-8? (rhetorical)

Actually you're mixing character set and character encoding here...
(also rhetorical ;-)

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 31 Oct 2001 09:54:46 +0100

> as (obviously) I cannot type it in.

The LDAP application has to transliterate from the OS's native
character set to a "LDAP character set". This is well-defined in
LDAPv3 for all textual strings (UTF-8 encoded Unicode) - except
passwords when doing simple bind. Therefore the LDAP client
application is free to choose any character set/encoding when
1. setting the password and
2. providing the password during simple bind.
IMHO the standard is simply incomplete in this regard.

Today the LDAP server compares the password just byte-by-byte
against the stored password set before. It's completely coincidence
if that works for anything else than ASCII or not.
To make matters worse: The very same LDAP application could choose
different character sets for setting the password and providing the
password during simple bind and still be compliant with LDAPv3 and
various other LDAP-related standards (e.g. password syntax in RFC
2307 and RFC 3112, password setting in RFC 3062).

I plan to propose more changes to all standards relevant for setting
and verifying passwords if my proposed change for simple bind is
accepted.

Ciao, Michael.