Subject: Re: LDAP ISSUE

From: Steve Hanna <[email-masked]>
Date: Fri, 19 Jul 2002 01:21:32 +0-900

Actually, there is a good reason for the position of the LDAP
group on this issue.

The reason that new keywords for attribute types in X.500 DNs
cannot be sent on the wire in LDAP protocol messages is that
old LDAP servers won't know what the new keywords mean. 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.

Also, this is not a new position. RFC 1779 (for LDAPv2)
allowed new keywords and defined an IANA registry. But no
new keywords were ever defined. I suspect that people
realized the problems that would ensue. RFC 2253 (for LDAPv3)
does not allow new keywords. And the revised version of 2253
(draft-ietf-ldapbis-dn-07.txt) also does not.

Steve

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 18 Jul 2002 15:07:02 -0400

Steve,

That sounds like a presentation issue, and perhaps that's what
you meant to imply by emphasizing "on the wire".

Would it not be reasonable for new DN attribute keywords to
be registered with IANA, and permit newly developed clients
to translate between keywords (for human consumption)
and OIDs (on the wire)?

Dave

---

From: David Chadwick <[email-masked]>
Date: Fri, 19 Jul 2002 01:36:32 +0100

Steve Hanna wrote:
> old LDAP servers won't know what the new keywords mean.

Steve

we have two cases here.
i) a new attribute is defined along with a new string keyword. 
-- this wont cause a problem because the old server wont have any
entries with that name and will return an error message to the client

ii) an old server does have entries with that name but is used to seeing
OIDs in the request, and the clients that go with it also send the OIDs
(they cant do otherwise). Then the string name (which is already defined
anyway and known about, because the client can use it when asking for
the attribute) is defined for use in DNs as well. There will be a
migration problem only if the clients start to use the string keyword
before the server. Therefore once the keyword is defined in an Internet
draft, servers should be configured to start to expect it.

> For

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)

> realized the problems that would ensue. 

No, I think it was because everyone built their DITs using only the
keywords defined. But now PKIX has defined some new attributes for use
in DNs, and therefore the keywords for these should also be supported.

David

>RFC 2253 (for LDAPv3)

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

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

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

---

From: David Chadwick <[email-masked]>
Date: Fri, 19 Jul 2002 01:39:13 +0100

Dave

Once the keywords are reggistered with IANA, the client wont need to do
the mapping. It can send the keywords in the protocol. It has to do the
mapping now for some of the keywords, and not for others, since only
some of the mappings are known to the server. This is an odd situation
to be in, and burdens the client. Once the keywords are registered, the
clients wont need to know about or use any of the OIDs.

David