NameAndOptionalUID (was: OpenLDAP 2.4.16: can not add multiple 'member' attributes to object groupOfNames)

[Michael Ströder <michael@stroeder.com>]

Howard Chu wrote:
> The NameAndOptionalUID syntax in LDAP is completely stupid and cannot be
> parsed reliably or logically.
> 
> The X.520 definition of NameAndOptionalUID is:
> 
>     NameAndOptionalUid    ::=    SEQUENCE {
>         dn            DistinguishedName,
>         uid            UniqueIdentifier OPTIONAL }
> 
> The LDAP transformation into "dn [ # uid ]" is first of all useless
> because it overlooks the possibility of "#" being an actual part of the
> rightmost DN component,

And UniqueIdentifier is BIT STRING. Looking at section 3.3.21. of RFC
4517 it's declared like this:

      NameAndOptionalUID = distinguishedName [ SHARP BitString ]
[..]
      Example:
         1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B

This could also be a valid DN.

So the way it is used in various deployments with values like

  uid=user1,dc=example,dc=com#user1

is invalid either. AFAICS nobody uses BitString syntax for real-world
attribute values at all. Well, others are confused too by
UniqueIdentifier not being a normal string-based UID:

https://issues.apache.org/bugzilla/show_bug.cgi?id=45107

> and is secondly illogical because while at a superficial level it
> appears to preserve the order specified in X.500, it actually
> associated the uid to the wrong RDN.

I don't understand this sentence. Could you please elaborate on that?

> A DN is a sequence of RDNs from most superior to most inferior. E.g.,
> for the DN "cn=foo,ou=users,dc=example,dc=com" the actual ASN.1 encoding
> should be in this order:
> {    dc com
>     dc example
>     ou users
>     cn foo }
> 
> The uid is associated to the object named by the full DN; it is thus
> logically associated to the object whose RDN is "cn=foo". So a
> NameAndOptionalUID value with the above dn and uid=101 should look like
> {{    dc com
>     dc example
>     ou users
>     cn foo }
>     uid 101 }
> 
> Since the LDAP designers screwed up and reversed the order of DNs in
> their string construction, the logical LDAP format for
> NameAndOptionalUID should have been "[ uid # ] dn" e.g.
>     101#cn=foo,ou=users,dc=example,dc=com
> 
> This would have been perfectly unambiguous, perfectly parseable, and
> completely logical - keeping the uid associated to the DN element that
> it actually applies to.

I don't understand that either. How is "uid 101" related to the DN at
all? From my understanding the UniqueIdentifier could be just any unique
identifier represented as BitString and may be part of the referenced
entry e.g. in attribute 'x500UniqueIdentifier'. How the DSA would make
use of this UniqueIdentifier is completely implementation-specific.

I agree that

  NameAndOptionalUID = BitString SHARP distinguishedName

would have been better. But then the UID could not be optional.

Anyway this is all academic. I don't see a real use-case for
groupOfUniqueNames->uniqueMember either...

Ciao, Michael.