Re: ;binary again

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 02:28 AM 4/22/2005, Sassa wrote:
>Kurt D. Zeilenga wrote:
>
>>At 09:08 AM 4/21/2005, Sassa wrote:
>>
>>>I have seen a number of questions regarding transfer of binary attributes with ';binary' option. We are using X.509 Attribute Certificates. Our schema specifies
>>>
>>>1.3.6.1.4.1.1466.115.121.1.5 - Binary syntax
>>attributeCertificate would be a more appropriate syntax
>>for a value containing an X.509 attribute certificate.
>
>When I try
>
>1.2.826.0.1.3344810.7.5
>
>as defined in "Internet X.509 Public Key Infrastructure LDAP Schema and Syntaxes for PMIs" <draft-ietf-pkix-ldap-pmi-schema-00.txt>, slapadd fails (no syntax found, apparently).
>
>What OID does OpenLDAP understand for attributeCertificateAttribute?

OpenLDAP Software does not yet support the attributeCertificate
syntax, and hence not the attributeCertificateAttribute attribute
type.  The specification is still "a work in progress".  Of course,
someone could submit a patch to add an early implementation of
attributeCertificate and associated matching rules to OpenLDAP
Software.

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

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

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

Anyways, one certainly could hack slapd(8) to understand
the underlying ASN.1 for each syntax so that it can
convert between the ;binary encoding and the LDAP native
encoding freely, but it seems rather pointless.  ;binary
is deprecated.  It simply should not be used beyond
the few attribute types whose existing specifications
require it to be used.

>>However, I suggest you migrate to a modern specification
>>of attributeCertificateAttribute which, IIRC, uses the
>>attributeCertificate (which doesn't require/expect
>>use of ;binary).
>
>:-) The specifications that we are using haven't changed, as to my mind, and they do not actually mandate that ";binary" _should_ be used - this is up to LDAP to understand/require the suffix or not. And, as I said, the standard syntax for the attribute certificates is not understood (by any OpenLDAP implementation we tried through several years).

There is not yet a standard LDAP syntax for attribute certificates.

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

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

Kurt