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

userPassword and non-ASCII characters



Hi,

How should I encoded strings containing non-ASCII characters
that I want to store in the userPassword attribute.
I have searched the RFCs but I have not found whether I have 
to encode the value in UTF-8 before stroing it in the value or not.

If I do not encode it in UTF-8 I may end up with another password 
when sitting on a keyboard with another locale.
If I do, does it conform to the octetString syntax ?

Or shall I store / request it using the ;binary option ?


Speaking of the ;binary option:
RFC2251 states:

4.3.1  Binary Transfer of Values

   This encoding format is used if the binary encoding is requested by
   the client for an attribute, or if the attribute syntax name is
   "1.3.6.1.4.1.1466.115.121.1.5".  The contents of the LDAP
   AttributeValue or AssertionValue field is a BER-encoded instance of
   the attribute value or a matching rule assertion value ASN.1 data
   type as defined for use with X.500. (The first byte inside the OCTET
   STRING wrapper is a tag octet.  However, the OCTET STRING is still
   encoded in primitive form.)

   All servers MUST implement this form for both generating attribute
   values in search responses, and parsing attribute values in add,
   compare and modify requests, if the attribute type is recognized and
   the attribute syntax name is that of Binary.  Clients which request
   that all attributes be returned from entries MUST be prepared to
   receive values in binary (e.g. userCertificate;binary), and SHOULD
   NOT simply display binary or unrecognized values to users.

Does this mean I am free to store and request any attribute either in
its normal form or in binary and the server has to give it to me the
way I want it ?

Does that mean that the server has to UTF8-decode regular strings
when binary transfer was requested ?

Does OpenLDAP support it ? 
My tests with ldapsearch indicate it doesn't, but maybe I misunderstood it.

Peter
-- 
Peter Marschall
eMail: peter@adpm.de