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

Re: ;binary migration solution

My view is that most widely used client and server implementations will need to support the old way and the new way, because many existing implementations will NEVER be updated. But your proposal does allow new servers that do not need to support old clients to NOT implement ;binary.

One more comment: it might be better to use http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-features-04.txt instead of a control for this.

-Mark Smith
 Netscape


David Chadwick wrote: 
Dear All

I have a suggestion to solve the migration of systems that currently use
;binary for certificates, to future ones that wont (according to the
latest spec).

A new control is defined "Dont Use ;binary" that is always set to
critical by new systems (clients) that implement the latest LDAPv3
protocol.

An old (existing) LDAPv3 server that supports ;binary wont understand
the control and will reply "unavailable critical extension". The client
will then remove the control and expect to receive
userCertificate;binary in the reply.

A new LDAPv3 server that understands the control and knows that ;binary
has been removed from LDAPv3, and that the native encoding for
certificates as defined in the PKIX draft is BER encoding, will return
the certificate without ;binary.

Old clients and old servers will continue to use ;binary for
certificates until they migrate.

An old client wont set the new control, so a new server that has removed
the need for ;binary must still send the certificate using ;binary
attribute descriptions, so as to cater for the old client.

Once all systems have moved over to not using ;binary, (ie. all clients
and servers understand the new control) then the need for the new "Dont
Use ;binary" control can be deprecated as it is no longer necessary.

Comments?