Subject: Re: ;binary migration solution

From: "Jim Sermersheim" <[email-masked]>
Date: Sat, 16 Nov 2002 22:39:04 -0700

Unless some problem can  be shown, this is what I would prefer.

Jim

>>> Hallvard B Furuseth <[email-masked]> 11/15/02 02:58AM >>>
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: Hallvard B Furuseth <[email-masked]>
Date: Sun, 17 Nov 2002 14:50:06 +0100

> or not the attribute was added with a ;binary option)?

Well, the second suggestion has one problem, so I don't know if that

> requests the attribute without ;binary, it receives it without ;binary.

If the client asks for userCertificate but wants userCertificate;binary,
it would get the wrong value even if the certificate was added with
;binary.

Are there clients like that?

-- 
Hallvard

---

From: [email-masked]
Date: Wed, 20 Nov 2002 12:01:14 -0000

Date sent:      	Sat, 16 Nov 2002 22:39:04 -0700
From:           	"Jim Sermersheim" <[email-masked]>
To:             	<[email-masked]>, <[email-masked]>
Subject:        	Re: ;binary migration solution
Priority:       	non-urgent

Jim

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.

David

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 20 Nov 2002 14:41:20 +0100

[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