[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Revisited: NON-ASCII chars in userPassword
"Ramsay, Ron" wrote:
>
> 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.
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.