Subject: RE: ;binary migration solution

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 15 Nov 2002 11:52:15 +1100

I find it difficult to see this as a feature. Also, David's proposal is
intended to be interim but this route would be forever.

Ron.

-----Original Message-----
From: Mark C Smith [mailto:[email-masked]]
Sent: Friday, 15 November 2002 09:18
To: David Chadwick
Cc: LDAP BIS
Subject: 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?

---

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 19 Nov 2002 12:22:37 +1100

Hallvard,

The message that you were replying to when I replied to yours was saying
exectly that - make ;binary a no-op. userCertificate;binary and
userCertificate are exactly the same.

As regards double wrapping, this should never occur in the case of values
represented in ASN.1. Plain strings, though, would be wrapped in an
octet-string wrapper. There was also some confusion about this as ALL values
are wrapped in an octet-string wrapper within the protocol.

Ron.

-----Original Message-----
From: Hallvard B Furuseth [mailto:[email-masked]]
Sent: Monday, 18 November 2002 22:41
To: Ramsay, Ron
Cc: Jim Sermersheim; [email-masked]
Subject: RE: ;binary migration solution

Ramsay, Ron writes:
> With userCertificate, it doesn't matter how you ask for it, there is only
> one encoding possible, the raw BER.

Yes, that's why I suggestet it should do nothing about encoding.

Though IIRC there were (are?) programs who thought ;binary meant the
value should be wrapped in an extra BER envelope, I don't remember which
type.

> The presence of ;binary on either
> request or response is purely cosmetic.

However, some clients expect attribute to be named "userCertificate" or
"userCertificate;binary" and does not recognize the other form.

BTW, yet another way would be to just define ;binary as a tagging option
which does nothing.  If the directory is used both by clients that want
"userCertificate;binary" and clients that want "userCertificate", the
maintainer will have to add both forms.

-- 
Hallvard

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 20 Nov 2002 12:38:18 -0700

The way the specification was written, the ;binary option is never stored with the value. it was only to be used to denote the transfer encoding format. By making the "native encoding" of userCertificate equivalent to the "binary" encoding, this makes "userCertificate" and "userCertificate;binary" equivalent. This is why I agreed with your proposal.

Jim

>>> Hallvard B Furuseth <[email-masked]> 11/20/02 08:41AM >>>
[email-masked] writes:
> I am not sure that this solves the migration problem since you are
> giving rules that have to be obeyed by existing systems, which they
> cant do if they are not upgraded. My "control" solution did not effect
> existing systems, only new systems. This was the point in having a
> migration solution.

As Kurt mentioned, you should send your suggestion to [email-masked].
(And then maybe I should send this letter there too, unless you
tell me where I'm wrong or address this posting in your pkix message.)

Anyway, I don't see what you mean.

With my original suggesetion, the migration solution on the client side
is simply to make no changes and keep asking for userCertificate;binary.
That will handle both old and new servers.

The final step of the migration on the client side, to remove the
migration solution (not use ";binary" or a "don't use binary" control),
must in either case wait until one trusts that all serveres the client
will use have been upgraded.

The same step on the server side must in both cases wait until one
trusts that no clients that use the server, use the migration solution.

Have I missed something?

Well, I may have missed to handle update operations, though.  When
"userCertificate;binary" is added (with the add/modify operation) today,
does the server remove ";binary" and store the name "userCertificate"?
If so, my version of ";binary" should do the same.

-- 
Hallvard