RE: RFC2253bis: "a published table"

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

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

I aggree. Customers use private attributetypes in DN's.
> 
> >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.
> 
> How does the client determine which names it can use?

It is dependant on the features of the client. I think the most clients
can only use hardcoded forms for the names. There are clients
which use string based names and at least they can give all kinds of
names.

> Should it attempt to construct the member DN using the OID form
>   so that it read the controlling schema associated with the DN?

I think the most clients can work without schema eploration.

> What if there is no entry associated with the DN (or it's not
>   accessible or it's controlling subschema is not accessible)?

What is the problem if there is no entry associated with the DN.
e.g. I put CN=Kurt,o=OpenLdap in  a accessControlList in my directory
and allow him to read my entry. If you authenticate with Certificate based
client authentication my Directory Server get your DN during authentication
and can use it without having te entry.
 
> Would the server holding the group object recognize the names
>   used (so that it can do equality matching)?

yes.

> Should the client use the schema controlling the group object
>  to construct the member value?

no.

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

how will this happen?

Helmut
> 
>         Kurt
> 
>