[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ;binary again

Kurt D. Zeilenga wrote:

for attributeCertificateAttribute. slapadd fails to import LDIFs from the older openldap where ";binary" is present for all attributeCertificateAttributes - it complains that ";binary" option is not supported for this type. This is odd, and in my view does not conform to RFC2252 (see excerpt below).

Is there a way to force openldap to accept ";binary" for specific attributes?

No. slapd(8) accepts/requires use of ;binary on a per syntax basis. The binary syntax defines an LDAP string encoding of BER, use of ;binary is at best redundant and at worse problematic. The underlying ASN.1 data type for the binary syntax can be viewed as a constrained OCTET STRING, and implementations with this view will encode an OCTET STRING for transfer when ;binary is selected (instead of just transferring the contents of the OCTET STRING).

I can't accept this explanation, because the RFC (which I quoted in the last email) gives an example where a userCertificate is returned with ";binary" suffix.

Any userCertificate example is not an example of how to
encode the binary syntax, userCertificate is not of the
binary syntax.  userCertificate is of the certificate
syntax.   That is, you seem to have confused the binary
transfer option with the binary syntax.

Of course, I always meant binary transfer option :-)

I won't paste the quote again. See RFC2252, section 4.3.1 Binary Transfer of Values.

RFC 2252, at this point, though not yet formally obsolete,
is effectively obsolete.  I suggest you read the revised
LDAP TS... which, of course, includes neither the binary
syntax nor the binary transfer option.

I didn't know that.

You can certainly modify slapd to require ;binary for all
values of the binary syntax, but in doing so, you may
break other applications which assume values of their
attributes of the binary syntax are to be transferred
without ;binary.   See 'certificate' syntax for an

I don't want slapd to _require_ ;binary. I want it to accept ;binary, if present. I can't see where in the LDAPv3 specs the use of ";binary" is forbidden for specific syntaxes.

Nor do the specifications specifically require implementations
to recognize ;binary for arbitrary syntaxes.  For instance, the
specifications do not require your client nor slapd
to recognize cn;binary or userPassword;binary.

RFC2252 does require: All servers MUST implement this form for both generating attribute values in search responses, and parsing attribute values in add, compare and modify requests, if the attribute type is recognized and the attribute syntax name is that of Binary.

:-) That's why I was surprised that even though in our schema X.509 ACs are marked as binary openldap refuses to accept ";binary".

Anyway, if RFC2252 is going to be obsolete soon, we'll have to change our code then.

Now, this is clearly very annoying that LDAP v2 allowed use of ";binary",

Attribute description options such as ;binary are new to LDAPv3
and clearly invalid in LDAPv2.

maybe I forgot :-) I clearly remember that suddenly we had to switch to using ";binary", now we have to switch back again.

but understood the values without the suffix. The early openldap LDAP v3 implementations _required_ the attributes that are transmitted in binary, to have the suffix. And now you are saying that we _can't_ use the suffix at all. Where's the truth? :-)

The truth is that the RFC 2252 specification of binary syntax
and the ;binary transfer option is flawed, and that the IETF
will, in due course, will published revised specifications.

OK, this explains.

No more questions then. Thank you very much for lengthy explanations.