RE: RFC2253bis: "a published table"

["Steven Legg" <steven.legg@adacel.com.au>]

Helmut,

> -----Original Message-----
> From: owner-ietf-ldapbis@OpenLDAP.org
> [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Volpers, Helmut
> Sent: Sunday, 5 November 2000 4:34
> To: 'Kurt D. Zeilenga'; Jim Sermersheim
> Cc: ietf-ldapbis@OpenLDAP.org
> Subject: RE: RFC2253bis: "a published table"
> 
> 
> Hi,
> 
> > -----Original Message-----
> > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> > Sent: Thursday, November 02, 2000 8:39 PM
> > To: Jim Sermersheim
> > Cc: ietf-ldapbis@OpenLDAP.org
> > Subject: Re: RFC2253bis: "a published table"

[snip]
 
> > >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 think DN's are unique in their Universe. That means if I build up a
> directory in 
> an Enterprise the DN is unique in this directory (distributed or not).
> I personal prefer that attribute names are globally unique 
> (what is the
> case if you use ObjectIdentifier). 
> > 
> > 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.
> 
> What is the real problem with this? Why is it a problem to 
> create a member 
> attribute value which exist in a foreign namespace.

The problem is if the member value (of DN syntax) contains an ambiguous
attribute type name. Suppose I have a server with a schema that
defines an attribute type called employeeNumber, and that you also
have a server with a schema that defines an attribute type called
employeeNumber, but with a different OID and perhaps even a different
syntax. Now suppose that some client wants to take a DN from your
namespace, e.g. cn=John Smith + employeeNumber=999, o=Foobar Inc., c=de
and put it into a groupOfNames entry in my server. How is my server
to know that the employeeNumber attribute type name refers to the
type definition in your schema instead of the attribute of the same
name in my local schema ? A sophisticated name to OID translation
function could take account of the context (i.e. o=Foobar Inc., c=de)
in which the attribute name has been used, but there are other ways
in which foreign attribute names could be encountered where there
wouldn't be any useful context.

Regards,
Steven

[snip]

> 
> Helmut
> > 
> >         Kurt
> > 
> > 
>