Subject: Re: LDAP ISSUE

From: Steve Hanna <[email-masked]>
Date: Fri, 19 Jul 2002 17:28:43 +0-900

David Chadwick wrote:
>we have two cases here.

What about the case where a server returns a keyword to a
client that doesn't understand it? I agree that you can define
new keywords if all the software is updated or reconfigured
whenever a new keyword is defined. But this isn't realistic.

>> For
>> user input and output, new keywords can be added. But you
>> can't expect existing LDAP servers to automagically understand
>> what a new keyword means when they see it on the wire. OIDs
>> are the best way to handle this.
>
>Actually OIDs are the best alround, and keywords should never have been
>defined! But given that they are, we should be consistent in their
>application, and not require keywords for some things and OIDs for
>others, within the same protocol item (a DN)

We agree that OIDs are the best solution for the on-the-wire
protocol. The best way forward seems clear to me. Don't define
new keywords to be used on the wire. Can you provide any reason
why it would be good to define more keywords?

>But now PKIX has defined some new attributes for use
>in DNs, and therefore the keywords for these should also be supported.

Following that logic, we'll have to add new keywords whenever
anyone comes up with another attribute. Each keyword will
introduce another potential compatibility issue. That sounds
pretty undesirable to me.

Thanks,

Steve

---

From: David Chadwick <[email-masked]>
Date: Tue, 23 Jul 2002 12:07:50 +0100

Steve

sorry for the late reply, but I was travelling in Japan all the week
after the IETF meeting.

> client that doesn't understand it? 

This is exactly why LDAP invented the use of keywords. The argument is
that clients who dont understand the new attribute type, if it is
identified by an object identifiers then displaying these OIDs to the
users is pointless. However, if an unknown attribute is identified by an
unknown keyword e.g. Pseudonymn is returned to the client, it simply
displays it to the human user as is, in anticipation that it will make
sense to the user. Certainly the keyword will make more sense to the
human than the OID. Thus your third case above is one that actually
supports the use of keywords rather than OIDs.

>I agree that you can define

Its just as realistic as reconfiguring the software when a new attribute
OID is defined. The whole point of LDAP using keywords was that unknown
keywords were easier for dumb clients to handle than unknown OIDs.

> protocol. 

Actually I just gave an example when they werent!. But if we had a clean
sheet for defining the LDAP protocol I would never have suggested
inventing keywords and would have stuck with OIDs to be compatible with
X.500. But there are many folk who think that keywords in protocol are
far preferrable all the time to OIDs, since it makes debugging much
easier (e.g. would you prefer to see 1.2.986.2345.26.3.4.67 or ssNumber
when it occurs in protocol).

>The best way forward seems clear to me. Don't define

Yes I just have done above. Could you also answer my point that already
more than 50 keywords exist, and servers know how to map these into
attribute types (and OIDs) when they exist in requests for attributes,
but not when they exist in DNs. Can  you explain why this situation is
tenable?

> pretty undesirable to me.

No so, if the keyword is registered when the new attribute OID is
registered, then both will appear at the same time.

David

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
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
PGP Key ID is 0xBC238DE5

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