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

RE: LDAP Certificate transfer syntax

At 12:32 PM 2002-04-03, Sharon Boeyen wrote:
>>From the PKIX perspective, I firmly believe that backward compatibility 
>with the PKIX LDAP specs is a very important issue.

I think there is some confusion here as to regards to
"compatibility".  This is an update/revision of an LDAPv3
technical specification.  We are implicitly talking about
compatibility of (conformant) implementations of the
existing LDAPv3 technical specification and future
(conformant) implementations of a future LDAPv3 technical
specification.

LDAPv2 and LDAPv3 are distinct on-the-wire protocols.
Directory add, delete, modify, rename, or search operations
either has LDAPv2 syntax and semantics or has LDAPv3 syntax
and semantics.

Here we are talking about changes to LDAPv3 technical
specification and how they would or wouldn't affect LDAPv3
implementations.

These changes have ZERO impact on LDAPv2 implementations.


>I believe that what 
>David is proposing satisfies that important criteria and support the 
>proposal.
In David's table, he shows that existing LDAPv3 implementations
are "OK".   That is, LDAPv3 is not broken in this regard.  The
specification is clear and there multiple interoperable
LDAPv3 implementations.

Removing the "MUST" request and use certificate attributes using
;binary will cause interoperability problems and will force
unnecessary changes to BOTH LDAPv3 clients and LDAPv3 servers.
This is because LDAPv3 does not provide any mechanism for
an LDAP peer (client or server) to discover which options its peer
(server or client) to discover which attribute descriptions
it supports.

That is, this suggest change will implementations to updated to
support it.  This will include some clients (such as those which
as for "*" and expect userCertificate;binary) and most (if not
all) servers.  That's bad!

Hence, for LDAPv3 interoperability sake, the specification needs
to continue to MUST the use of ;binary for these attributes except
where the client and server have a prior agreement that the
OPTIONAL native encoding is to be used.

Of course, one ought to wonder why any LDAPv3 implementation
would support this OPTIONAL native encoding when the REQUIRED
encoding is more broadly implemented and provides the same
functionality.   It seems redundant to me.

Kurt