Subject: RE: A plan for PKIX, LDAPv3, and ;binary

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Nov 2002 20:15:24 -0500

At 06:42 PM 2002-11-21, Christopher Oliva wrote:
>I have a question about point 4. Specifically the sentence: 
>
>" Rather than be silent, we suggest that the PKIX syntax and schema document state the LDAP-specific encoding used in transfer without the ;binary option but deprecate its use. "
>
>What will be the impact of "but deprecate its use" to server implementations? 

I would hope the impact would be that ALL implementations
use "userCertficate;binary".

>I would prefer to remove the last 4 words of that sentence.
>
>I would like to see a more clear statement that servers will have to support requests for userCertificate as well as userCertificate;binary.

The current LDAPv3 technical specification [RFC 3377] does not
state what is to be returned when "userCertificate" is requested
(as this is a non-conformant request).  There are clients which
expect:
        a) return the certificate using "userCertificate;binary" or
        b) return the certificate using "userCertificate".

(as well as clients which accept either)

As a server cannot support both at the same time, there is
clearly an interoperability divide between implementations
of these behaviors.  To preserve interoperability on either
side of that divide, no statement is made which would require
a server implementation to cross the divide.

That is, it is suggested that servers not be restricted in
how they respond to a non-conformant request so as to allow
current interoperability with ill-behaving clients.

Kurt

---

From: Harald Koch <[email-masked]>
Date: Fri, 22 Nov 2002 09:47:44 -0500

>  There are clients which

The problem is complicated by the fact that there are LDAPv3 *servers*,
some that expect 'userCertificate;binary' and some that expect
'userCertificate'.

Then there are servers that support either, and will return whichever
attribute name they think is correct, regardless of the request.

Then there are implementations that perform searches on, and return,
whichever name was used to store the certificate, without treating the
;binary transfer option specially. Requesting 'userCertificate' would
not return any 'userCertificate;binary' attribute stored in the entry,
and vice versa.

(IIRC, one older server could even store *both* userCertificate and
 userCertificate;binary in a single directory entry as separate,
 multi-valued attributes :-).

So sadly, the only thing a truly interoperable client can do is request
both and accept both; performing two searches and merging the results.
Nothing else covers all current implementations, in my implementation
experience.

-- 
Harald Koch     <[email-masked]>