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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 12:44 PM 2002-11-22, Christopher Oliva wrote:
>> There are clients which expect: 

Note that I said this in a particular context.  That is,

There are clients which ask for "userCertificate" and expect either:
>>         a) return the certificate using "userCertificate;binary" or 
>>         b) return the certificate using "userCertificate". 

That is, a server which does a) won't interoperate with a client
which expects b) and a server which does b) won't interoperate
with a client which expects a).

>This sounds like a strong argument that supports updating servers to achieve interoperability with both groups.

It's a damn good argument for clients which ask for "userCertificate"
to be upgraded to ask for "userCertificate;binary" as the LDAPv3
specification has told them to do 5 years ago.

We should be careful not to add new requirements as we should
not unnecessarily require changes to deployed LDAPv3-conformant
systems.

>That's why I would prefer a solution that requires updated servers to support the native encoding of certificates (as would be returned when "userCertificate" is requested).

As noted above, a server which does a) or b) will not interoperate
with the group of clients which expect the other.  We should let
server implementors choose wether they want to support a) or b)
or say "no".  That is, we shouldn't detail non-standard behaviors.

>> As a server cannot support both at the same time, there is 
>> clearly an interoperability divide between implementations 
>
>Why is it that a server cannot support both groups ? 

Well, a server could return the attribute twice, once labelled
"userCertificate" and "userCertificate;binary".... but that
might confuse clients which expect an attribute to be returned
only once.

>If it remains the server's choice of whether or not to support group B, the interoperability divide remains unchanged.

If we force servers to support group B, then we disallow servers
from supporting group A.  If we force servers to support group
A, then we disallow servers from supporting group B.

>I believe the proposal should define the native encoding so that interoperability with group B can be attempted. This should not involve any comments about deprecation as server implementations may takes this as a reason not to support a request for "userCertificate". And there can be text indicating clients SHOULD request "userCertificate;binary".

We should require no server which is support a particular odd group
to stop supporting that odd group.  But we certainly should deprecate
both group A and B as both are odd.  That is, we should everyone in
group A and group B to the standards following group, group IETF.