[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Revised Matched Values Draft

Date sent:      	Tue, 11 Jul 2000 18:01:38 -0700
To:             	d.w.chadwick@salford.ac.uk, "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
From:           	Bruce Greenblatt <bgreenblatt@directory-applications.com>
Subject:        	Re: Revised Matched Values Draft
Copies to:      	ietf-ldapext@netscape.com

> I'll voice the same reservations this time that I voiced last time.

Bruce

there are two separate though inter-related issues addressed in 
your ID.
i) the first concerns the DIT structure and the storage of multiple, 
possibly related, attribute values in separate entries rather than in a 
single entry
ii) the second concerns matching on complex attribute values.

Matched values assumes for i) that separate entries will not always 
be employed, and so helps in cases where they are not. 
Interestingly, for the first issue you describe a DIT structure that is 
very similar to the family of entries structure I proposed in <draft-
chadwick-families-00.txt> (now expired). I think that this 
sort of structure is sensible for grouping single values 
together and has lots of uses. We agree that we should try 
to standardise schema and controls for handling this type 
of subtree, as it has wide applicability (and is already in 
use in many directory implementations). However, even if we 
can agree on a standard approach to creating subtrees of 
related entries, there is no guarantee that every DIT will 
always use this approach, so there is still some value in 
the matchedValues ID.

For the matching issue your proposal is that we actually 
dissect a complex attribute into its component parts, 
create separate attributes for each part and then put them 
together in a single entry. I dont like this approach for 
several reasons. Firstly it puts the onus on someone to 
read an attribute, dissect it, create separate attributes, 
and store them together, and make sure that the whole bunch 
are kept atomic. This is not a sensible approach as it puts 
a huge burden on some administrator or the creation of a 
new administration tool to do this. It also is a way of 
introducing errors since you are duplicating data. Secondly 
it mandates the subtree of entries approach and cannot work 
without it. Thirdly, it is not secure in the case of 
certificates (your example). A certificate is a digitally 
signed construct that cannot be manipulated. Your set of 
simple attributes are not digitally signed and therefore 
can be manipulated. There is no security control (outside 
of directory access controls) that stops this manipulation, 
and nothing that allows the user to check that these simple 
attributes are correct (either due to tampering or 
negligence or simple error), other than retrieving the 
certificate and comparing it to his matching criteria (i.e. 
he cannot trust the directory to perform correct matching). 
The better approach (I believe) is to define a matching 
rule that will match on a complex attribute. The matching 
software only has to be implemented in the server (in fact 
it is usually a combination of simple already-existing 
matching rules that need to be combined) and then we remove 
the overhead of dissection and attribute creation which is 
an ongoing process (we also significantly reduce storage 
space as well). Finally it will work with both subtrees of 
related entries and with single entries with lots of 
values. The new ID <draft-pkix-ldap-schema-00.txt> proposes 
an LDAP schema for this.

> 
> Use of this control solves a problem that normally exists due to poor
> schema and DIT design.  There is no obvious reason why an entry should
> have so many values of an attribute that an LDAP client would have a
> problem retrieving them all. 

I suggest that subschema publishing is one such set of attributes 
that have this property. And this is mandatory to support in every 
LDAPv3 server. Thus the authors of LDAPv3 and X.500 are poor 
schema designers by implication. The other point is that every 
LDAPv3 will need a matchedValues type control if it is to return 
individual schema definitions.

> Do not put hundreds of values (or
> however many you have in mind) in the attribute.  The introduction
> uses the userCertificate attribute as an example.  While it is true
> that a single user in the real world may have numerous certificates,
> this should not translate into an LDAP entry that has numerous
> userCertificate attribute values.  IMHO, this is poor schema/DIT
> design.  By creating this control, we only encourage this type of
> design, when we really need to discourage it.  In my mind it is
> analogous to encouraging non-normalized SQL schemas.  I wrote a little
> draft a while back
> (http://www.ietf.org/internet-drafts/draft-greenblatt-ldap-certinfo-sc
> hema-02.txt) that recommends a schema/DIT design for holding
> certificate information in the schema that allows for selective
> retrieval of certificates without requiring any protocol extensions
> (or even any new syntaxes).  I have had several people ask me
> privately about this draft with indications that they were interested
> in implementing it.
> 
> Additionally, I believe that implementation of this control could
> place an unnecessary burden on the server for sifting through the
> attribute values, when it should be done on the client (perhaps this
> is more of a stylistic issue). 

We have had this discussion previously and several messages to 
the list said that sorting through complex attributes was a task that 
should be performed by the server and not the client.

David

> In any case, I would not be in favor
> of promoting this draft along the standards track.  Last time this
> came up, and I voice this same objection to the draft, I received
> several notes supporting my position.  I think that we need to think
> carefully about what kinds of protocol extension that should be
> standardized, and how they benefit LDAP applications.  In my mind this
> extension provides no benefits to LDAP applications.
> 
> Bruce
> 
> 


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

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@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

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