RE: ;binary and userCertificate (Was: Private email ...)

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Kurt,

Where is your idea of returning an X500 DN by asking for dn;binary spelled
out?

I would expect LDAP servers to regard the DN as a string and simply wrap it
with an octet string tag. In fact, I don't remember any description of a
non-string encoding of DN in the LDAP documents.

As regards your other arguments, I have trouble getting a handle on them.
The only attributes that MUST be requested with ;binary are the certificate
bunch. A client MUST always expect these to be returned with ;binary
regardless of the request. Requesting other attributes with ;binary just
seems wrong. (I reject your notion that servers will perform some
unspecified action to return a novel encoding of an attribute. Chris seems
to be saying that servers will only return the value that is stored and only
in the way it is stored, apart, I guess, from being able to wrap strings in
octet string wrappers.)

I do agree with Chris that ;binary was a BAD idea.

Ron.
-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Thursday, 21 February 2002 4:52
To: Christopher Oliva; Ramsay, Ron; David Chadwick; Mark C Smith;
Christopher Oliva; Sharon Boeyen
Cc: LDAP BIS
Subject: ;binary and userCertificate (Was: Private email ...)


;binary has uses beyond those with certificates.  For
example, to request transfer of a DN in BER form instead
of RFC 2253 form.  IMO, an attribute of syntax DN would
serve as a better example of ;binary's "intended" use
(as described in Section 4.1.5.1 of RFC 2251).

It doesn't make much sense to return values in BER form
when the client has not explicitly requested it.  While
RFC 2251 stated: 
   Clients MUST NOT expect servers to return an attribute
   in binary format if the client requested that attribute
   by name without the binary option. 

This did not prevent, generally, a server from running any
attribute in binary format even though requested without
;binary.  Likely it was assumed to be obvious that a server
shouldn't return CN;binary unless it was asked to.  The
revised specification explicitly states that servers must
not use binary transfer when the attribute was requested
without ;binary.

As all attributes explicitly make use of binary transfer
state that values MUST be requested and transferred with
the ;binary option, the revised specification is self
consistent.

In regards to X.509 schema, one should not fix that which
is not broken.  The document should:
	a) indicate edition of X.500 recommendations used
	   is different from those used in LDAPv3 and diccuss
	   impacts of this difference,
	b) add missing matching rules, and
	c) state that values and their encoding forms
	   be preserved.

I see no reason to define a LDAPv3 native (octet)string encoding
for these syntaxes as ;binary works just fine.  Yes, there
may be broken LDAPv3 implementations, they should be fixed.

The fact that LDAPv2 uses a different mechanism is
inconsequential to this discussion.