RE: RFC2253bis: "a published table"

["Volpers, Helmut" <helmut.volpers@icn.siemens.de>]

Steven,

> -----Original Message-----
> From: Steven Legg [mailto:steven.legg@adacel.com.au]
> Sent: Mittwoch, 8. November 2000 07:18
> To: 'Volpers, Helmut'
> Cc: ietf-ldapbis@OpenLDAP.org
> Subject: RE: RFC2253bis: "a published table"
> 
> 
> 
> 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. 

That is a real problem. It should not happen.

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 ?

I think for your server it refers to your local schema.

 A sophisticated name to OID translation
> function could take account of the context (i.e. o=Foobar Inc., c=de)

I don't like it so much.

> 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.

What other ways do you mean ?

Regards,

Helmut
> 
> Regards,
> Steven
> 
> [snip]
> 
> > 
> > Helmut
> > > 
> > >         Kurt
> > > 
> > > 
> > 
>