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

Re: A plan for PKIX, LDAPv3, and ;binary



>  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)

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     <chk@pobox.com>