Subject: Re: ;binary migration solution

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 21 Nov 2002 11:38:04 +0100

Jim Sermersheim writes:
> 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.

Well, I no longer agree with it, after reading David's comments.  I had
not understood how ;binary works.

I think it's better if it works just like it does today, except that it
no longer has any effect on encoding.  If I understand correctly, that
means: (pkix readers, sorry for the repeat)

- The "binary" option does nothing to encoding.
  Attribute syntaxes take care of encoding.
- The option is removed from attribute descriptions in LDAP
  operations, except
  (a) in attribute values (like DNs),
  (b) in places where options may not occur.
      I must check if (a) implies (b) so (b) can be skipped.
  Thus, attribute descriptions are stored without ;binary in
  the directory.
- If a search requested an attribute with the "binary" option,
  it is added to that attribute in the search result (if that
  attribute is returned).

Migration plan (maybe this should be added as an implementation note):

(1) Servers upgrade to the new spec, while clients continue
    using ;binary.
(2) When (1) has progressed far enough, clients quit using ;binary.
(3) When (2) has progressed far enough, ;binary is removed from
    the next revision of the standard which defines it, if/when a
    next revision happens.

-- 
Hallvard

---

From: "Steven Legg" <[email-masked]>
Date: Tue, 26 Nov 2002 10:05:42 +1100

Folks,

>   it is added to that attribute in the search result (if that

It is all well and good to propose that ";binary" be in the returned
attribute description if and only if ";binary" is in the original request
but what if the original request was for all user attributes (i.e. "*") ?
This facility is being ignored in all this discussion about ";binary".

As things stand today, we have a significant body of LDAPv3 compliant
implementations that expect to get back "userCertificate;binary" from
a request for "*". In any phased migration away from the use of ";binary",
at some point compliant directory servers will have to change from returning
userCertificate;binary to just returning userCertificate and this will
break currently conformant clients.

David Chadwick is the only one who has proposed a safe way to
effect a migration (using controls). However, since such a migration
delivers no practical benefit to conformant PKI clients (just a different
way of asking for the same thing), I think the pain of migration is
not justified.

Regards,
Steven

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 30 Nov 2002 20:51:26 +0100

Steven Legg writes:
> a request for "*".

I can think of a few ways to handle that, all of them ugly:

- Go back to my first suggestion.
  If an attribute is added with ;binary, it is returned with ;binary.
  Possibly unless it is asked for without ;binary, which causes
  the server to strip away ;binary in the result.
  Thus, the administrator can add certificates with ;binary if he
  has such clients.

  If the same site also has clients that wants userCertificate without
  ;binary, they lose.

- Treat ;binary as a normal tagging option.  Add userCertificate;binary
  and get userCertificate;binary back.  If there are also clients that
  want it without ;binary, add plain userCertificate as well.

- Let the attribute syntax handle ;binary.  If an attribute has a
  "binary syntax", it is returned with ;binary.

  This breaks clients which do not want ;binary added.

How common are clients like you describe, compared to
(a) clients that do not want ;binary and ask for userCertificate,
(b) clients that do not want ;binary and ask for *?

> In any phased migration away from the use of ";binary",
> at some point compliant directory servers will have to change from
> returning userCertificate;binary to just returning userCertificate and
> this will break currently conformant clients.
>

Yes, it may be just as well to keep asking for ;binary.

BTW, as far as I can tell, my and David's proposal make migration
more or less equally hard:

Client side:
- update to try DontUseBinary (David's) or to ask for ;binary (mine).
Server side:
- update to let syntaxes ensure binary transfer.
- update to handle DontUseBinary or no-op ;binary
Client side, when serveres have been upgraded:
- remove DontUseBinary (David's) or remove ;binary (mine).
Server side, when clients have been upgraded:
- remove support for DontUseBinary and ;binary.

-- 
Hallvard