Re: Migrating from iPlanet, 'binary' issues

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

At 11:27 AM 2002-12-05, Lon Tierney wrote:
>>>Is there a list of the other syntaxes that do not allow, or require the
>>>";binary" transfer option?>
>> Yes, in schema_init.c, everything marked SLAP_SYNTAX_BINARY requires
>> ;binary to be present and every which isn't so marked requires ;binary
>> to be absent.
>If I understand you correctly, "allow"=="require" if the
>SLAP_SYNTAX_BINARY flag is set?

I avoid the term "allow" because it implies the option may or may
not be present.   In OpenLDAP, the option is required to be present
with some syntaxes and required to be absent with others.

>I tried the ";binary" transfer option with something that is not defined
>to with the SLAP_SYNTAX_BINARY flag ("mail" attribute), and it did fail.
>In the previous message you sent me you said "The technical specification,
>technically speaking, allows ;binary to be used with any syntax but only
>mandates it use with a few (namely, the X.509 certificate syntaxes)." Is
>this a bug, or just where OpenLDAP parts from the RFC (assuming your
>comment came from an RFC)?

Like most other LDAP implementations, OpenLDAP doesn't elect
to implement all elective features but only those which are
applicable for its intended use.  There are very few clients
which go around asking for mail;binary and even fewer clients
that can actually do something useful with BER encoded mail
attribute values.

>Shouldn't I be able to send a string that is BER encoded?

You can send mail;binary... but a server is free to treat
mail;binary as an unrecognized attribute description if it
doesn't support binary transfer of the mail attribute.  There
is certainly no requirement that implementations support any
translating between BER form and the string form.  Few support
any.

>Here is my difficulty - I have an attribute that is BER encoded. There
>will never be a syntax to actually verify if the BER blob is what I say it
>is (as I am never going to code it up). It is technically a CMS/PKCS#7
>EncryptedData object. Following iPlanet's lead, it would be a binary
>syntax, transfered with the ";binary" option. This is what we do today.
>Unless there is a syntax for CMS objects, I can do one of the following:
>1) change the transfer option to send it without ";binary" (this shouldn't
>cause an issue with iPlanet since they truly don't care), and keep the
>binary (BER) syntax in my schema
>2) Use a different syntax that is BER encoded and requires the ";binary"
>transfer option (I hate to say it, but the certificate syntax works - but
>presumably some day one could code up syntax checking to see that the
>value we are sending is indeed not a valid certificate)
>Any suggestions?

By personal opinion...

For old attributes:

The technical specification for the attribute type should detail
which LDAP syntax to use, and that syntax specification should
say whether ;binary is to be used.  For the binary syntax [RFC2252],
you'll run into attribute types which require the use of ;binary
as well as attribute types which require that ;binary not be used.
If you want to use one set or the other, then adjust schema_init.c
as needed.  If you want to use both, you are in a pickle.  Likely
the thing to do here is to define two binary syntaxes (on different
OIDs, one with the SLAP_SYNTAX_BINARY flag and one without) and
then attribute types to use appropriate syntaxes.  When you
tweak the attribute types, you should assign them a new OID
(as schema definitions should be replaced not modified).

For new attributes:

Associated with every LDAP syntax should be an ASN.1 data type
and one encoding form.   If you want that encoding form to be
BER, fine, just define the native LDAP string encoding to be
the string produced by BER encoding the values.  If you want
to use some other general or custom encoding rules, define the
native LDAP string encoding accordingly.  One can also define
matching rules which depend on the structure of values.

If you want the values to truly be treated as BLOBs,
then use octet string syntax.  True BLOBs have "no structure"
and, hence, cannot support matching rules requiring "structure".
That is, if you use octet string syntax you are stuck with
octet string matching rules.

Kurt