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

RE: Private email re LDAP and ;binary



Title: RE: Private email re LDAP and ;binary

In my experience, the ldap servers that exhibit a problem with ";binary" do not distinguish between ldapv2 or ldapv3 in a search request (when it comes to ";binary"-correctness). They treat both identically.

I have also noticed that some of these servers tend to respond based on how a request was constructed - if the search asked for ";binary", then the ";binary" is used in the response and vice versa.

There is a more problematic category of server ... for these, one version of the search (;binary or not) will fail. Usually, this depends on how the attribute was added to the server in the first place. If it was added with ";binary" then only ";binary" will work (even in ldapv2). If it was added without ";binary" (even in ldapv2), then a search using ";binary" (even in ldapv3) will fail.

The next question will be: how should a server respond when the attribute name isn't explicitly requested?

Current servers will do one of two things:

1) use ";binary" only if ";binary" was used when the attribute was added (regardless of whether this was done in ldapv2 or ldapv3)

2) return ;binary by default in ldapv3. Some will remove the ";binary" in an ldapv2 response, which, in my opinion, is the correct thing to do.

If I had to pick an option, it would be (2).

I will spare you from talking about what happens when you use a search filter like "userCertificate=*" or "userCertificate;binary=*" which only result in more chaos. I also will only mention that trying to follow referrals between such servers is quite challenging. You may also ask why I care about ldapv2 - because there are customers using ldapv2 that must migrate to ldapv3.

In my opinion, ";binary" has caused more problems then it solved. It should either be eliminated or neutralized. That is why the changes that have been proposed must be applied.

Chris.


-----Original Message-----
From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com]
Sent: Tuesday, February 19, 2002 7:06 PM
To: David Chadwick; Mark C Smith
Cc: Christopher Oliva; Sharon Boeyen; LDAP BIS
Subject: RE: Private email re LDAP and ;binary


I think you've left out

V2 client sends certificate;binary to V3 server which replies with
certificate, which may not be handled properly by the client.

It would be interesting to know how the common servers respond to a request
for certificate, sans ;binary.

Ron.

-----Original Message-----
From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk]
Sent: Wednesday, 20 February 2002 8:06
To: Mark C Smith
Cc: Christopher Oliva; Sharon Boeyen; LDAP BIS
Subject: Re: Private email re LDAP and ;binary




Mark C Smith wrote:

> Do you care about backwards compatibility?

Yes. We must be backwards compatible with LDAPv3 as a minimum. But note
that up until now, LDAPv3 has not defined matching rules for any X.509
stuff, nor the syntax for many of the X.509 data structures. SO the PKIX
document is the first one in which syntaxes have been specified for
everything in X.509. Thus my point is, once syntaxes are specified and
known about, then the attributes and assertion values can be carried in
their known-about syntaxes, without any special instructions (such as
;binary) being needed. ;binary becomes an anachronism from the past and
can quietly die.
But it will be needed during a period of migration for those LDAPv3
servers that DONT know the
syntaxes of the X.509 stuff so that they will still be able to transfer
it correctly.
Therefore we should allow for both now, with the intention of phasing
out ;binary in the next version (or when it goes to full standard, say).


Thus my suggestion is that if ;binary is not used, the client and the
server must know what they are dealing with, and what its syntax is.
Values are carried in BER format. However, if ;binary is used, those
products that understand the syntax simply ignore the ;binary, those
that dont know the syntax, know they have to transfer the data as BER
encoded octets.

>Any change to the on-the-wire
> protocol for retrieving certificates over LDAPv3 makes me nervous. The
> entire installed base of LDAPv3 servers and clients uses an
> AttributeDescription of userCertificate;binary, as mandated by RFC 2252.

I agree, they do (or should do!!)

But note that the entire installed base of LDAPv2 clients and servers
(if there are many left) dont use ;binary and can still transfer X.509
stuff successfully. So ;binary is not essential for certificates to
work.

> Now you are suggesting that we change all clients and servers to use
> userCertificate.

No, not at all. Here's how it would work in practice

                  V3 Server              Older V3 Server
                  Understands            Does not understand

Client sends         OK                  Error
userCertificate                 


Client sends
userCert;binary     OK                  OK


So we have a problem with older LDAPv3 servers who dont know much about
the
syntax of the X.509 stuff they are storing, just that it should be sent
and received in BER format using ;binary. (they wont know how to match
on values either). Clearly if a client tries to add a certificate to one
of these servers without using ;binary, (this could be a v3 client
evolved from a v2 one for example) the server should reject it. Thats
OK. If another client uses ;binary the certificate can be stored, but if
the original client then tries to retrieve it, it will fail. So the rule
for clients is, to be on the safe side in the short to medium term, use
;binary.

My question to the server guys is "once you understand the syntax of
X.509 attributes and assertion values, why do you want ;binary to be
there?" You probably dont, so will be glad to see it go.

My question to v2 client migrators is "what is the big deal in adding
;binary to the X.509 attribute requests, since you will have to be
making other changes anyway when you migrate to v3"

> What value does such a change really have? Why propose
> such a change when it will very likely break some existing
implementations?
>

I guess in short, it tidies things up for the future, and removes an
anomaly from the standard.

David

> -Mark Smith
>   Netscape

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

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 161 745 8169
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@salford.ac.uk
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

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