[Date Prev][Date Next] [Chronological] [Thread] [Top]
RE: Tw bobs worth on TOP, LDAP standards process and subschemasub entry attribute usage in rootDSE

To: "'hahnt@us.ibm.com '" <hahnt@us.ibm.com>, "'ietf-ldapext@netscape.com '" <ietf-ldapext@netscape.com>, 'David Chadwick ' <d.w.chadwick@iti.salford.ac.uk>
Subject: RE: Tw bobs worth on TOP, LDAP standards process and subschemasub entry attribute usage in rootDSE
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Date: Sun, 04 Jul 1999 06:18:17 +1000
Resent-date: Sat, 03 Jul 1999 13:31:12 -0700 (PDT)
Resent-from: ietf-ldapext@netscape.com
Resent-message-id: <"lqpUxB.A.ULH.-Fnf3"@glacier>
Resent-sender: ietf-ldapext-request@netscape.com
 Dear all - There has been some off list discussion with this issue of
TOP - as defined by 2.5.6.0 by the ISO-ITU and the X.500 standards. As
it seems that a few "directory" suppliers have done this.

However, it is not been made very clear to this list what the
implications of doing these modifications to TOP are.

For instance if one adds different attributes to TOP that deal with
subschema - then management/knowledge applications will be written to
use these attributes in these places in all objects.

ie there will be proprietary directory system management applications.

For instance if one adds different attributes to TOP that deal with User
authentication and access controls - then  security and authentication
applications will be written to use these attributes in these places (in
all objects).
ie there will be proprietary User logon on processes and security
management applications


For instance if one adds attributes to TOP that deal with certificates
and key management - then  security and authentication applications will
be written to use these attributes in these places in all objects.
ie there will be proprietary PKI and CA applications


It strikes me that redefining TOP and using the OID of the ISO-ITU is
WRONG

1. It is saying that the data represented by this OID is that of the
standard and its memeber bodies - when it is not.
ie. IMHO If I took the OID of XX, GOV, Defense, SecurityAgency, sec-alg1
and redefined the data for use within public systemse - I have stollen
the authority of the Sec Agengy's registration authority , potentially
undermined its security efforts and jepordised its systems.

2. By adding attributes to TOP for DIT management, certificate
management, User identification, logon processes, entry classification ,
etc - one is forcing applications to be written to these non standard
information models - ie Making an application and information mess for
the customers out there in the market place who have to pay for this
"techno-ego-mess".

3. And it is absolutely pointless standardising on LDAP as the protocol
if the basis for the information over that protocol at the very
rudimentary levels of User access, authentication and schema management
is PROPRIETARY..


No doubt many on this list will ignore this.. However what is really
good is that customes who want large scale distributed directory systems
for single use logon etc for their business are realising the above re
these "proprietary LDAP non distributed servers" and that they  are
nothing more than yet another protocol with yet another database - and
are just adding to their problems and cost.

I really do recommend that those on this list who are responsible for
their directory developments within their companies stand back and look
at what is being delivered in this LDAP process and non Compliant TOP
definitions... Non standard LDAP with Non standard extensions with non
standard information and security models...

I hope your marketing and finance guys appreciate that...


In closing - can anyone advise me what is the standrd for directory
services within the IETF - as we now have a protocol "LDAP" that has too
many single server based ( non distributed) extensions to be of  wide
scale use - and the desire to use TOP in so many ways that the whole
information  and application  model for directories for the business
user is becoming a mess.

Is the LDAP standard development process broken?

Please note for those who do not understand X.500 - It standardised
protocols for access, distribution, replication and management that
relate and cannot be disconnected from a standard information model, a
standard schema and User access control model, a DIT management and
knowledge model an authentication and mutual authentication model that
all relies on a standard definition and application of TOP.

If you mess up top you mess up the whole of the directory service..



...
regards alan



----------
From: David Chadwick
To: hahnt@us.ibm.com; ietf-ldapext@netscape.com
Sent: 6/29/99 5:00:28 AM
Subject: Re: subschemasubentry attribute usage in rootDSE

Date forwarded: 	Fri, 25 Jun 1999 04:16:04 -0700 (PDT)
From:           	hahnt@us.ibm.com
Send reply to:  	hahnt@us.ibm.com
To:             	ietf-ldapext@netscape.com
Date sent:      	Fri, 25 Jun 1999 07:12:15 -0400
Subject:        	subschemasubentry attribute usage in rootDSE
Forwarded by:   	ietf-ldapext@netscape.com

> Hello,

Timothy,

You are correct. This is indeed a bug. The intent is as follows:
Each entry contains a single pointer to the subschema subentry that 
controls it. This attribute is single valued, as an entry can only be 
controlled by a single subschema subentry. This is part of the X.501 
model, and is there to ensure that an entry is not controlled by 
multiple conflicting subschema definitions (remember the recent 
debate about MS's top object class) and also it is more efficient than 
having to retreive subschema definitions from multiple places in the 
DIT to work out what actually controls this entry. (Access controls on 
the other hand are different in X.501, as multiple access control 
subentries can control access to a single entry, and there are pre-
defined rules for working out the results of conflicting permissions).

This is how the subschema bug probably arose. In X.501 it is very 
clear how to find the subschema subentry when navigating down 
from the root of the DIT - it is immediately below an administrative 
point. LDAP does not have/know about administrative points, so 
instead, a pointer was stuck in the root DSE to point to the 
subschema subentry. But here is where the problem comes. A 
directory server can have multiple administrative domains (easily 
solved in X.501 by having multiple administrative points each with a 
subschema subentry beneath it) but in LDAP servers this will cause 
multiple pointers to be added to the single valued 
subschemaSubentry attribute in the root DSE (which is impossible 
of course). The reason no-one has noticed the bug until now is 
probably because everyone running pure LDAP servers is only 
holding information from a single management domain, and 
therefore only needs a single pointer to subschema definitions in the 
root DSE.

The solution is quite simple, and it is this. Define a new attribute
type 
for top, with exactly the same syntax as now, but make it multiple 
valued. Lets call it: 

subschemaSubentries

Then we have the single valued attribute in each entry, and a 
multiple valued attribute in the root DSE

David

> 
> In reading RFC 2251 and RFC 2252, I have stumbled across a question
> regarding the use of the subschemasubentry attribute type.
> 
> RFC 2251, in section 3.2.1, indicates that every entry mastered by a
> server will have an attribute type included within it called
> subschemasubentry.  This attribute type's value will be a
distinguished
> name that 'points to' the subschema entry in the namespace that
describes
> the schema for which the entry conforms to.  Quoting the RFC:
> 
> - subschemaSubentry:  the Distinguished Name of the subschema entry
>      (or subentry) which controls the schema for this entry.
> 
> 
> RFC 2252 in section 5.1.5, indicates that the subschemasubentry
attribute
> type is SINGLE-VALUE.  Quoting the RFC:
> 
> 5.1.5. subschemaSubentry
> 
>    The value of this attribute is the name of a subschema entry (or
>    subentry if the server is based on X.500(93)) in which the server
>    makes available attributes specifying the schema.
> 
>     ( 2.5.18.10 NAME 'subschemaSubentry'
>       EQUALITY distinguishedNameMatch
>       SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
>       SINGLE-VALUE USAGE directoryOperation )
> 
> 
> Later on in RFC 2251, Root DSE is described in section 3.4.  In this
> section, it
>  seems that a slightly different use of subschemasubentry is
described. 
>  Quoting the RFC:
> 
>  - subschemaSubentry: subschema entries (or subentries) known by this
>      server.
> 
> Now my question:  The plurarlity in the sentence about
subschemasubentry
> in the Root DSEsection of RFC 2251 implies that this attribute type is
> multi-valued in the Root DSE.  Is this the intent?  Is it the intent
of
> the RFC that the subschemasubentry attribute type be allowed to be
> multi-valued when contained in the Root DSE, regardless of its
definition
> as being SINGLE-VALUE as defined in RFC 2252?
> 
> Thanks in advance for this clarification,
> Tim Hahn
> 
> Internet: hahnt@us.ibm.com
> Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
> phone: 607.752.6388     tie-line: 8/852.6388
> fax: 607.752.3681
> 
> 
> 


***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
*NEW* Mobile +44 790 167 0359 *NEW*
Email D.W.Chadwick@iti.salford.ac.uk
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************
Follow-Ups:
- Re: Tw bobs worth on TOP, LDAP standards process and subschemasub entry attribute usage in rootDSE
  - From: Mark Wahl <M.Wahl@INNOSOFT.COM>
Prev by Date: I-D ACTION:draft-rharrison-bulkldif-00.txt
Next by Date: Re:Heathers web cam
Index(es):
- Chronological
- Thread