On Feb 20, 2009, at 6:11 PM, Stef wrote: Why? This syntax should be avoided. It was dropped with revised LDAP specifications (RFC 4510) for good reason. Any uses of it will suffer significant interoperability problems. If all you want is store certificate requests in the directory as octet strings, matched by octet string matching, then use OCTET STRING and octetStringMatch. If what you want is matching based upon the request abstract value, then you will need to define a new syntax whose LDAP string syntax is the BER/DER encoding of the request (don't use ;binary) and then implement an equality rule for that syntax. Equality mapping for the ASN.1 open data type? The underlying ASN.1 data type for the binary syntax is (depending on how you read the obsoleted specification) an ANY. It's not implemented for a reason. You are at least barking in the wrong direction.

Stef wrote: Do you have any use-case where you need equality matching on one of those? BTW: I don't know any client which writes userSMIMECertificate except Netscape Communicator 4.5+. (AFAIK it's supposed to be opaque-signed S/MIME message with zero-length body signed by the private key holder.) So IMO it's ok to leave this schema definition as is for backward compability. Ciao, Michael.