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

Re: Textual/non-textual passwords and SASLprep



(Lifting snippets from here and there) How does this sound?
 
Textual passwords (consisting of a character sequence with a known character set and encoding) SHALL be transferred as [UTF-8] encoded [Unicode]. 
The determination of whether a password is textual is a local client matter.   
Prior to transfer, clients SHOULD prepare text passwords by applying the [SASLprep] profile of the [Stringprep] algorithm. 
Passwords consisting of other data (such as random octets) MUST NOT be altered. 

Jim

>>> Michael Ströder <michael@stroeder.com> 11/12/03 7:38:55 AM >>>
Hallvard B Furuseth wrote:
> Michael Ströder writes:
> 
>>
>>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.

There's no text in my former posting stating that textual passwords can't be 
read from a file.

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

Not necessarily. That's simply subject of local definition.

>>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"),

Then we go for "it's the client's responsibility to know this a priori". ;-)

> or to drop the SHALL/MUST treat
> textual and non-textual passwords differently.

No!

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

Even "passwords typed in by users" could be binary. ;-)

Since you cited my former posting I'll grab text from there:

"More formally one could define textual passwords as a character sequence 
with a known character set and encoding."

Ciao, Michael.