Ordering of RDN components: ldapd broken?

peter (pww@bnr.ca)
Mon, 8 Jan 1996 23:00:58 -0500

In some tests I have been doing, I have set up a DSA in which users are
named using serialNumber and commonName; a fairly typical DN looks like

serialNumber=43255 + cn=J Smith, o=NSN, c=CA

If I use dish to search for and view this entry, it doesn't matter
whether I specify the DN as

@c=CA@o=NSN@cn=j smith%serialNumber=43255


@c=CA@o=NSN@serialNumber=43255%cn=j smith

In other words, the ordering of components in the RDN doesn't matter,
which is correct behavior.

However, my 3.1 ldapd does care: if I specify the DN as

serialNumber=43255 + cn=J Smith, o=NSN, c=CA

everythign is fine, but if specify it as

cn=J Smith + serialNumber=43255, o=NSN, c=CA

the DSA reports "no such object, matched c=CA@o=NSN".

My working assumption is that ldapd thinks that the entry's RDN is

cn="J Smith+serialNumber=43255"

In other words, ldapd took everything between "cn=" and "," and assumed
it was the commonName. The DSA translates this into

@c=CA@o=NSN@cn=J Smith+serialNumber=43255

and, not surprisingly, returns an error.

Has anyone else run into this problem? If so, where did you go to apply
the fix?

If you haven't run into the problem, any ideas on where the fix goes?
I've looked some, haven't found it, and have other pressing problems to
solve, so any help or hints would be welcome.


ps AFAIK, there is no mandated way to sort components of an RDN when
returning them to a user, either in X.500(1996), or in RFC 177[789].
QUIPU and dish present them in decreasing order of OID, both in
display and in logs, while ldapd seems to do the same. If not,
should there be?