Re: ;binary again

[Sassa <o.otenko@kent.ac.uk>]

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


Regards,

Sassa

> Kurt