Subject: ;binary migration solution

From: David Chadwick <[email-masked]>
Date: Thu, 14 Nov 2002 21:23:37 +0000

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?

Regards

David

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: [email-masked] (Mark C Smith)
Date: Thu, 14 Nov 2002 17:18:15 -0500

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

---

From: Michael Ströder <[email-masked]>
Date: Thu, 14 Nov 2002 23:54:27 +0100

> instead of a control for this.

+1

Ciao, Michael.

---

From: [email-masked] (Mark C Smith)
Date: Thu, 14 Nov 2002 17:47:50 -0500

Mark C Smith wrote:
> But your proposal does allow new 

I retract the above comment. Your proposal is that new servers must 
support old clients.  This is quite a mess from an interoperability 
point of view. If all servers support the old and new method and if the 
functionality is equivalent, why would a client implementor ever bother 
using the new way?

-Mark

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 15 Nov 2002 10:58:22 +0100

How about defining ;binary to do nothing, except that if the client
requests ;binary on an attribute, it receives it with ;binary (whether
or not the attribute was added with a ;binary option)?

Also, maybe if an attribute was added with ;binary but the client
requests the attribute without ;binary, it receives it without ;binary.

-- 
Hallvard

---

From: David Chadwick <[email-masked]>
Date: Fri, 15 Nov 2002 14:23:38 +0000

> functionality is equivalent, why would a client implementor ever bother

Because I envisaged that the LDAPv3 protocol would remain as now i.e.
;binary is removed. And that this control is in a separate RFC called
"LDAPv3 - PKI  migration" or similar, which can describe the migration
path from the old LDAPv3 to the current LDAPv3. 

David

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 17 Nov 2002 10:33:21 -0500

While presently the revised LDAPv3 core TS I-Ds (produced by
LDAPBIS WG) and the PKI LDAP Schema I-D (produced by the PKIX WG)
do not rely on ;binary option, it should be noted that the PKIX
WG has apparently not yet reached consensus regarding how
certificates attributes are to be requested and transferred in
LDAP.  The PKIX WG is currently considering the
"userCertificate;binary" v. "userCertificate" question.

It should be noted that LDAPBIS's prior decisions to remove
PKI schema and ;binary feature from its I-Ds should not be
viewed as precluding either choice.  While the
"userCertificate;binary" would require a specification of
the ;binary option, a ;binary option specified as an
extension to the LDAP "core" technical may be sufficient to
meet PKIX needs.  And, if its demonstrated that it this is
insufficient, prior decisions can be reconsidered.

However, before any reconsideration, we first need PKIX WG to
reach consensus on the "userCertificate;binary" v.
"userCertificate" question and, if the choice is to
support "userCertificate;binary", explore specification of
;binary as an extension.

So, while this thread is interesting and quite welcomed to
continue, I would like to stress that the "userCertificate;binary"
v. "userCertificate" issue is still an open question.  As this
question is "owned" by PKIX, please make sure that all relevant
comments are posted to the PKIX WG.

Kurt, LDAPBIS co-chair

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 18 Nov 2002 13:26:53 +0100

OK, I've sent my "no-op ;binary" suggestions to [email-masked].

-- 
Hallvard