Subject: Re: Textual/non-textual passwords and SASLprep

From: John McMeeking <[email-masked]>
Date: Wed, 12 Nov 2003 11:57:51 -0600

Works for me.

John  McMeeking

                      "Jim Sermersheim"                                                                                
                      <[email-masked]>          To:       <[email-masked]>                                
                      Sent by:                    cc:                                                                  
                      owner-ietf-ldapbis@O        Subject:  Re: Textual/non-textual passwords and SASLprep             
                      penLDAP.org                                                                                      

                      11/12/2003 09:45 AM                                                                              

(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 <[email-masked]> 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.

---

From: "Roger Harrison" <[email-masked]>
Date: Thu, 13 Nov 2003 06:39:46 -0700

This looks good to me.

Roger

>>> "Jim Sermersheim" <[email-masked]> 11/12/2003 9:45:11 AM >>>
 
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

Hallvard B Furuseth wrote:
> < http://www.openldap.org/lists/ietf-ldapbis/200305/msg00112.html >, which

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

> responsibility to know this"),

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

No!

Ciao, Michael.