Re: Textual/non-textual passwords and SASLprep

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Michael Ströder writes:
>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 ;-)

I quite agree, but that seemed to be what you suggested in article
<http://www.openldap.org/lists/ietf-ldapbis/200305/msg00112.html>, which
you referred me to when I asked how to tell if a password was 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.

So the password file contains a mark which says whether the following
password is textual or not, or something like that?  OK.

>> 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.

That's exactly my point:-)

> 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.

OK if that configuration file offers a format which says 'this password
is non-textual'.

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

I want [Protocol] to either say something about how to decide if a
password is textual or not (even if it's just "it's the client's
responsibility to know this"), or to drop the SHALL/MUST treat
textual and non-textual passwords differently.

At least, I want someone who writes a client which can bind as both
users with textual and with non-textual passwords, to have some clue
what is required of them.  For example, am I doing anything wrong if I
declare that passwords given to my client are always non-textual, even
passwords typed in by users, maybe unless the user gives an option
saying they are textual?  That's in violation of what people are saying
about typed-in passwords in this thread, but it's not in violation of
anything [Protocol] says.

-- 
Hallvard