[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Textual/non-textual passwords and SASLprep

Hallvard B Furuseth wrote: 

Even if the option is "if the password is taken from a file,
don't translate" if that's what you have in mind.

Even if passwords are read from file they can be textual ;-) and the application MUST have the a-priori knowledge to decide what to do with passwords stored in file. Which mainly boils down to that you also have to specify your file format exactly and your application following the format correctly.

It makes little sense to say, in effect, the client SHALL treat textual
and non-textual passwords differently, but not to give the slightest
hint how to decide when a password is textual.

The client does not decide whether an arbitrary password is textual. The client application simply MUST have the a-priori knowledge about passwords being textual or non-textual and whether to apply SASLprep or not. Most times the client application locally decides that derived from the source (e.g. keyboard, configuration file) the password is received from.

Example:
In case of my web application the user is definitely not able to send arbitrary binary data in the password input field. Therefore it's save to assume in my application that I have to convert the user's input from known input character set (<form accept-charset="..">) to UTF-8-encoded Unicode.

Hm?  I've read through the 'more SASLprep/protocol problems' thread and
the 'Schema: encrypted 8-bit userPassword and SASLprep' thread, but I
don't find answers to what I wrote.


Hallvard, I have to admit that I don't see your problem at all... :-/

I hate to repeat myself but I'd like to emphasize again that personally I'm very happy about having such a SASLprep statement now. It will lead to greater interoperability fixing real-world issues if all LDAP client implementors follow that rules.

Ciao, Michael.