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

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

Kurt,

Replies inline. See [RR]

Ron

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Thursday, 21 February 2002 13:03
To: Ramsay, Ron
Cc: LDAP BIS
Subject: RE: ;binary and userCertificate (Was: Private email ...)


At 05:00 PM 2002-02-20, Ramsay, Ron wrote:
>Where is your idea of returning an X500 DN by asking for dn;binary spelled
>out?

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.

[RR] I was also referring to attributes.

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

[RR] For most attributes this BER is simply an octet string wrapping.
Certificate stuff is the exception.

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

[RR] This section is more a hint than a spelling-out. Note that the only
attributes that this is expected to apply to are certificate releated (last
sentance of the section). It would not be possible, for example, for a
server to reconstitute the X500 definition of DirectoryString because the
actual CHOICE tag has been lost (was never supplied). Also, the section
assumes there is an ASN.1 definition. If you assume that X.520 is implied,
you can make up ASN.1 values, in principle, but as I've indicated with
DirectoryString, it is not always possible to go from the possible to the
actual. But if this were to be possible, LDAP should have specified these
ASN.1 syntaxes. I believe, though, as in the case of DistinguishedName, that
LDAP was actually trying to break away from X.500.

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

[RR] This is just certificate stuff again!

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

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.

[RR] You seem to be saying that DNs can't be returned in their X500 form?

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

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.

[RR] Once certificates are taken out of the base spec, conformance it moot!

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

[RR] That waffle is not clear. The only clear statement is that it is
expected to apply to certificates. No other syntaxes have been given an
ASN.1 form. If you look at the mailing list of the time (asid?) you will see
that the interpretation of this paragraph was to wrap the string
representation in an octet string. Once again, except for certificate
related stuff, the BER was taken to be 04 xx ......

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

[RR] I think this thread has revealed that others regard it as a BAD idea.