[Date Prev][Date Next]
Re: Characters in DN
This is something that I came across late last year. I also noticed that dn_validate/dn_normalize functions did not perform enough processing to always match two identical DNs. In addition to the example you cited, the functions also could not compare plain text with quoted text, text with escaped characters, or BER encoded text. For example, the following 4 DNs should all match:
I wrote some code that could normalize all of these, but it has not yet been included into the main development branch of the code. What I have written is available for download at http://csrc.nist.gov/pki/testing/openLDAP_contrib.html, however, as it is several months old, the patch will probably not work against the current code base.
I will download the current code in the development branch of the CVS tree, integrate my code with it, and then post an updated patch file as soon as I can.
At 01:52 PM 7/10/01 +0200, Pierangelo Masarati wrote:
>I note from RFC 2253 that
> > If the UTF-8 string does not have any of the following characters
> > which need escaping, then that string can be used as the string
> > representation of the value.
> > o a space or "#" character occurring at the beginning of the string
> > o a space character occurring at the end of the string
> > o one of the characters ",", "+", """, "\", "<", ">" or ";"
> > Implementations MAY escape other characters.
>but OpenLDAP's dn parsing functions don't seem to consider anything
>but dn and rdn separators (see for instance servers/slapd/dn.c:dn_validate
>and macro RDN_NEEDSESCAPE in servers/slapd/slap.h).
>I guess it should read
>#define RDN_NEEDSESCAPE(c) ((c) == '\\' || (c) == '"' || (c) == '<' || (c) == '>')
>as a consequence, if I add an entry of the form
>and then an entry
>they are treated like they're the same (correct) but only because
>the escapes '\' of chars that do not need escape (according to
>RDN_NEEDSESCAPE) are ignored when validating dns. I guess
>the second example (cn=<Ando>,dc=my,dc=org) should rather
>be treated as an error.
>should I go on and fix it?