Re: LDAP Certificate transfer syntax

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

I think adding a LDAP-specific "native" encoding to certificate
is a bad idea and will actually cause more problems than it
solves.

AFAIK, there are no interoperability problem between clients
and servers which adhere to the technical specification.  Things
are basically okay.

This I-D attempts to resolve interoperability problems between
non-conforming implementations and conforming implementations
by altering the specification to require conforming implementations
to accept and support the syntax and semantics of non-conforming
implementations.  However, there are a number of different
ways implementations have not conformed to the specification.

I have seen, in the wild, clients which:
	a) request "userCertificate" and expect the return of
	"userCertificate" using the (updated) LDAPv2 native
	string encoding.
	b) request "userCertificate" and expect the return of
	"userCertificate;binary" using binary transfer.
	c) request "*" and expect the return of
	"userCertificate;binary" using binary transfer.

This I-D caters to case a) in a manner which disallows servers
from supporting case b) and c).   I believe cases b) and c)
are actually for more common than case a).  I know of
implemenations which are liberal in accepting b) or c).  While
there may be implementations which are liberal in accepting
a), it should be noted that a) requires the server not to
be strict in what it sends.

I also note that b) and c) are generally the result of
the specification not be as clear as it should have been.
Where a) is the result of someone apply LDAPv2 syntax and
semantics to LDAPv3.

However, my objection to adding this I-D is that it that
client and server implementations of it won't interoperate
with existing server and client implementations which
conform to the existing specification.

I suggest we only make the minimal changes necessary to
resolve the issues which caused this schema to be removed
from the LDAP "core" technical specification.  It was
removed become of normative reference issues (e.g.,
2nd v 3rd v ... edition of X.500) and to align the
schema with that provided by X.509 (e.g., matching rules).

I note that it was NOT removed because of lack of multiple
independently developed implementations.  We need to
be careful to not to require changes to implementations
which have already demonstrated interoperability.

Kurt