Re: utility functions for handling Distinguished Names

[Kurt D. Z. <Ku...@Op...>]

At 01:07 PM 2002-04-23, Norbert Klasen wrote:


>--On Dienstag, 23. April 2002 15:59 +0100 Graham Barr <gb...@po...>=
 wrote:
>
>>But you code also expanded
>>
>>  CN=3D\a0   to    'CN' =3D> chr(160)
>>
>>Which means in canonical_dn both end up as
>>
>> CN=3D\a0
>>
>>which is wrong
>>
>> CN=3D\a0  is not the same as CN=3D#a0
>>
>>The first is a value of 1 character length and its type, for comaprisons,
>>is the type of CN. The second is a value of unknown type and so cannot be
>>compared to the first.
>
>After rereading RFC2253 it seems to me that CN should not be used as an=
 examaple here since it is a type that has a string representation.
>One could argue that CN=3D#xxxx is illegal altogether.

One can argue many things...

# was specifically designed for CN (and other attributes of
directoryString syntax).  See section 7.2 of RFC 2253.  The
IETF LDAPbis WG is working on clarifying this.

>>The #xxxxxx is normally a BER encodeing so to get the examples right
>>
>>  CN=3D\01\01\42  is not the same as CN=3D#010142 nor is it the same
>>  as CN=3D\42
>>
>>So you need to make sure that DNs of CN=3D#....  get returned from
>>canonical_dn as #... and DN that don't start with # do not.
>
>As long as we do not want to make canonical_dn schema aware, I think it=
 should be enough for canonical_dn to encode AttributeTypes of the=
 dotted-decimal form as #xxxx. Additional attriubte types can be specified=
 by the (renamed) ber parameter.

In our C API, we provide functions which do schema neutral
normalizations.  We don't convert between native string and
BER value forms as that requires knowledge of schema.  Instead,
we just indicate whether the value is in native form or
in BER form.  We do convert the hex to an octet string containing
the BER suitable for (BER) decoding.

>One question that remains is whether and how ldap_explode_dn should mark=
 values exploded from #xxxx. (BTW do such things really occur in DNs?) I=
 would argue that there is no need for this:

I would argue that if multiple encodings of the value can be
returned (native v. BER), then there needs to be some indicatation
as to which encoding is being used.

>- Only AttributeValues which are of a type which does not have a string=
 representation defined for it are encoded as #xxxx. [RFC2253]

No.

>- "clients MUST NOT assume that an unrecognized syntax is a string=
 representation" [RFC2252]

This statement is meant to imply that a client cannot assume that
the native string encoding is displayable.  For example, the
native string encoding for audio is not displayable.

>So an application that supports attribute types without a string=
 representation will know how to handle their values and therefore needs no=
 extra help by perl-ldap.

No.  PKI applications often have to use CN=3D# where the directory
string choice is T61 (as transliteration between T.61 and UCS
is not one-to-one).

>Attached patch to perl-ldap-0.25_01:
>- additional comments and documentation
>- renamed binary parameter in canonical_dn to ber
>- canonical_dn uses ldap_explode_dn reverse functionality
>- #xxxx encode dotted-decimal attribute types
>- don't use refs for #xxxx values
>- handling of empty DNs
>
>--=20
>Norbert Klasen, Dipl.-Inform.
>DAASI International GmbH                 phone: +49 7071 29 70336
>Wilhelmstr. 106                          fax:   +49 7071 29 5114
>72074 T=FCbingen                           email: nor...@da...
>Germany                                  web:   http://www.daasi.de
>
>
>