|
Are DNs really globally unique? It'd be cool if they were, but
because there's no "directory namespace" I don't think they are. I imagine there
are more than a few objects out there named o=acme.
I prefer that strong language is used to warn against
using other attribute names, but not to make a hard restriction. Again, this is
solely due to the large installed base of servers that I believe don't enforce
this restriction.
Jim
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 11/2/00 12:38:36 PM >>> At 10:31 AM 11/2/00 -0700, Jim Sermersheim wrote: >While the idealist in me says this is a good direction, the realist is quivering in fear of the lynch mob of customers that would ensue as a result of implementing this restriction. > >Currently, NDS allows any attribute name to be used in a DN as long as it's defined in the schema and is a valid naming attribute for the object class. This name is also returned in the DN (as opposed to an OID). I suspect that many other vendors behave this way as well. >Can you go into more detail as to why allowing any attribute name in a DN is a bad thing? DN are globally unique identifiers. In general attribute names are not globally unique. Allowing any attribute name into a DN means that DNs are no longer globally unique. This is very bad thing. I believe the authors of 1779 and 2253 recognized this problem and put in specific provisions to restrict the set of names which could be used. However, both have language which appear to suggest that additional names can be used. I would not object to having similar language in RFC 2253 as long as it noted that use of additional names may cause the DN not to refer to the intended object and, of great concern to security applications, it may refer to a different entry! Example: Suppose a client wants to construct an LDAP DN from a BER DN it has (say from a X.509 certificate) and it wants to provide store as a member attribute value of some group object which is not in the same naming context (nor administrative control) as the member. How does the client determine which names it can use? Should it attempt to construct the member DN using the OID form so that it read the controlling schema associated with the DN? What if there is no entry associated with the DN (or it's not accessible or it's controlling subschema is not accessible)? Would the server holding the group object recognize the names used (so that it can do equality matching)? Should the client use the schema controlling the group object to construct the member value? Would the server holding the member recognize the names? What if the server recognizes the names as being different attribute types resulting in the DN referring to a different object than intended? Kurt |