Subject: No-op LDAP ;binary option

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

Three related suggestions for the ;binary LDAP option, moved here from
LDAPBIS since it is the PKIX group who "owns" the ";binary" question:

Define the ;binary option to have no effect on encoding, and trust the
syntax of the attribute to take care of encoding.

Thus, you can put "userCertificate" in the Directory if that's what your
clients need, "userCertificate;binary" - with the same encoding - if
that's what they need, or both if you have both types of clients.

Or, one could define ;binary to do nothing except that if the client
requests ;binary on an attribute, it receives it with ;binary - whether
or not the has ;binary in the directory.

Thus you could have "userCertificate" in the directory and clients would
by default receive that, but clients that wanted ;binary would still be
handled - provided that they explicitly asked for it.  Clients that want
userCertificate;binary but ask for userCertificate or ask for all
attributes would not be handled.  In this case you could not solve that
by having both userCertificate and userCertificate;binary in the same
entry in the directory.

Also, one could decide that if an attribute is stored with ;binary in
the directory but the client requests the attribute without ;binary, it
receives it without ;binary.

This handles a situation where the admin has put ;binary in the
directory because most clients want that, but where some clients want
the attribute without ;binary (and ask for it explicitly).  It breaks
clients that ask for userCertificate but want userCertificate;binary,
which is legal.  In this case it doesn't help if the admin added
;binary.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 18 Nov 2002 11:24:49 -0500

>LDAPBIS since it is the PKIX group who "owns" the ";binary" question:

For clarity here, there is an outstanding question regarding
how X.509 certificate attributes are to be requested/transferred
in LDAP.  Namely, will "userCertificate;binary" or "userCertificate"
be the LDAP attribute description as the protocol token to refer
to an userCertificate attribute.  Regardless of which, the value
transferred is presumed to be a DER encoded X.509 certificate. 

This question is viewed by the LDAPBIS chairs as being "owned" by
PKIX WG.   Accordingly, we've asked PKIX chairs to determine whether
the PKI community prefers to continue using "userCertificate;binary"
or, as proposed in draft-ietf-pkix-ldap-pki-schema-00.txt, use
"userCertificate".

It should be noted that while LDAPBIS has decided to remove
;binary from the LDAP "core" technical specification, this decision
should not be viewed as precluding PKIX from either choice.
In particular, ;binary can be specified as an extension to LDAP
or, if necessary, the prior decision to remove ;binary from the
LDAP "core" technical specification can be reconsidered.

Kurt, LDAPBIS co-chair

---

From: [email-masked]
Date: Wed, 20 Nov 2002 13:55:20 -0000

From:           	Hallvard B Furuseth <[email-masked]>
To:             	[email-masked]
Subject:        	No-op LDAP ;binary option
Date sent:      	Mon, 18 Nov 2002 13:14:12 +0100

> by having both userCertificate and userCertificate;binary in the same

this is horrible. We dont really want to store two attribute do we? Remember 
that ;binary was a transfer encoding and not an attribute type. Therefore 
existing systems that support ;binary encodings should still store the attributes 
as userCertificates and not userCertificate;binary. There is no such thing as a 
userCertificate;binary attribute in the original LDAPv3 spec!.

> directory 

This is wrong thinking. The admin has stored a userCertificate in the directory 
and used ;binary as the transfer encoding to get it there. But it is a 
userCertificate that has been stored there. So LDAPv2 client should be able to 
pick it up as a userCertificate, without asking for userCertificate;binary.

David

>because most clients want that, but where some clients want

---

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

[email-masked] writes:

> this is horrible. We dont really want to store two attribute do we?
> (...) existing systems that support ;binary encodings should still
> store the attributes as userCertificates and not
> userCertificate;binary.

Oh.  I misunderstood the spec.  I wish someone had told me before I
posted on both lists:-) But this certainly makes things nicer.  Here is
a revised suggestion:

- The "binary" option does nothing to encoding.
  Attribute syntaxes take care of encoding.
- The option is removed from attribute descriptions in an LDAP
  operations, except in the list of requested attributes in search
  operations, and except in places where options may not occur.
- 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).

Did I get it right this time?

-- 
Hallvard