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

Re: userPassword and non-ASCII characters



At 10:36 AM 5/31/2003, Peter Marschall wrote:
>Hi,
>
>On Thursday 22 May 2003 17:00, Kurt D. Zeilenga wrote:
>> At 06:46 AM 5/22/2003, Peter Marschall wrote:
>> >On Thursday 22 May 2003 03:05, Kurt D. Zeilenga wrote:
>> >> If the application knows the password is textual, it should
>> >> 1) trancode the string to Unicode, 2) prepare the string for
>> >> matching (by the octetStringMatch rule), 3) and encode using
>> >> UTF-8.  To prepare the string, minimally normalize the
>> >> string to Form KC.   Presently, the IETF is considering
>> >> recommending that the SASLprep algorithm here.  See
>> >> draft-ietf-sasl-saslprep-xx.txt for details (available
>> >> at http://www.ietf.org/).
>
>Do these 3 steps apply to all attributes with syntaxOctet string
>(provided the app knows the value ist textual)

no.

>or is this procedure specific to the userPassword attribute ?

no.  It should be applied elsewhere textual passwords are
presented to the directory service as octet strings.

>If this is only specific to userPassword: How should a generic
>LDAP client treat attributes with syntax octetString ?

as octet strings.

>Especially: shall non-ASCII input be converted somehow 

Depends on the application semantics.

>or is octetString syntax (OID: 1.3.6.1.4.1.1466.115.121.1.40)
>in the end an equivalent to Binary syntax 
>(OID: 1.3.6.1.4.1.1466.115.121.1.5)

binary syntax is for BER-encoded data, not arbitrary binary
data.  For arbitrary binary data, one should use octet string
(if 8-bit aligned) or bit string (otherwise).