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

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 21 Feb 2002 12:00:18 +1100

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:[email-masked]]
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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 20 Feb 2002 18:03:13 -0800

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

I was referring to attributes of DN syntax, not to a DN
of an entry.  Maybe using attributes of directoryString syntax
in the example would make a less confusing.

;binary applies to all attributes.  A client can request CN;binary,
member;binary, userCertificate;binary, etc..  In all cases, if the
server supports ;binary for that attribute, the server returns
BER encoded values.

It's spelled out in RFC 2251, Section 4.1.5.1.

One of its primary uses is in security applications, see
RFC 2252 9.2 (but s/Binary syntax/binary transfer/ in last
sentence for it to make sense).

>non-string encoding of DN in the LDAP documents.

DNs transferred in fields of LDAPDN type in the protocol are
RFC 2253 strings.  Assertion and attribute values of distinguishName
syntax can be transferred using the native (octet) string
encoding, e.g. an RFC 2253 string, or using ;binary transfer,
e.g. BER.

>regardless of the request.

And the client MUST request them as ;binary.

RFC 2256:
   This attribute is to be stored and REQUESTED in the binary form, as
   'userCertificate;binary'.  (emphasis added)

RFC 2252:
   ... values in this syntax MUST only be transferred using the
   binary encoding, by requesting or returning the attributes
   with descriptions "userCertificate;binary" or
   "caCertificate;binary".

RFC 2256:
   clients MUST NOT expect servers to return an attribute in
   binary format if the client requested that attribute by name
   without the binary option.

A client which requests "userCertificate" (without ;binary)
does not conform to the specification.

>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.

It's specified quite clearly in RFC 2251, 4.1.5.1.

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

IMO, ;binary, as "intended" by 4.1.5.1, is a useful feature
of LDAPv3.