Re: Revisited: NON-ASCII chars in userPassword

["Jim Sermersheim" <JIMSE@novell.com>]

Okay, I'm betraying my ignorance here, but how does the server "check if the credential is UTF-8 encoded Unicode"? How do I know when it's UTF-8 versus a machine-generated string of octets?

Jim

>>> Michael Ströder <michael@stroeder.com> 10/31/01 02:06AM >>>
Steven Legg wrote:
> 
> Jim Sermersheim wrote:
> > Couldn't a server just provide an administrative setting that
> > it uses to specify the character encoding for the simple
> > password?
> 
> Every client would have to read this administrative setting to know
> how it should convert the password characters typed by the user
> into the server's configured character encoding.
> 
> It is less trouble to simply nominate that the chosen encoding
> will be UTF8 for everyone.

Absolutely.

> > It's *very* difficult to make a case for changing
> > the ASN.1 in the specification.
> 
> Michael isn't proposing a change to the ASN.1. The existing
> specification uses OCTET STRING. The proposal is to change
> that to LDAPString which is also an OCTET STRING. The difference
> is that LDAPString requires the contents of the OCTET STRING
> to be UTF8 encoded characters whereas at the moment it is
> the client's unrestricted choice.

Exactly.

> > At the very least, we'd need
> > to determine what ill-effects this would have on existing
> > implementations. Worst case it that we have to rev the protocol doc.
> 
> If we require servers that are using the proposed revision to
> accept non-UTF8 character encodings in the "simple" component
> LDAPString (i.e. accept apparent violations of the LDAPString
> constraint), for the sake of backward compatibility, then everything
> should work fine (i.e. no worse that the current situation).

Steven, you've got exactly the point. The only ill-effect that I can
imagine is that LDAP clients like Netscape Navigator which use
something else than UTF-8 encoded Unicode are no more formally
*compliant* to LDAP standard. But that's not worse than today
because they are already *incompatible* to most other LDAP client
implementations out there.

Well, I'm not an expert in using the keywords described in RFC 2119
but I'll have a try:
A LDAP server MUST check if the credential is UTF-8 encoded Unicode
and use the appropriate charset transliteration and matching rule to
verify the password. If the credential violates LDAPString
constraint the server MAY switch back to byte-by-byte comparison for
the sake of backward compatibility.

Ciao, Michael.