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