https://bugs.openldap.org/show_bug.cgi?id=9540
--- Comment #1 from Metin <[email protected]> --- I've this old post of 2000 https://www.openldap.org/lists/openldap-software/200012/msg00240.html Despite what RFC2798 says (it's just an informational document), userSMIMECertificate should not be transferred in ;binary mode and should be revised (as discussed on the IETF LDAPext mailing list). The ;binary mode can only be used to in conjunction with ASN.1 syntaxes, which binary syntax is not. That is, ;binary transfer of a attribute of binary syntax makes no sense and would serve no purpose. OpenLDAP allows ;binary transfer only with select syntaxes which require such, such as certificate syntax used by userCertificate. In some previous versions of OpenLDAP, the code was hacked to make userCertficate;binary work. However, this broke all proper uses of the binary syntax and hence the hack was removed. You are welcomed to install the hack locally or come up with a better hack. Alternative, you might be able to hack the Netscape client to use "userSMimeCertificate" without ";binary"... At 03:00 PM 12/20/00 +0100, Claude Lecommandeur wrote: > Am I doing something wrong ? No. The client is implementing a informational specification with a known flaw. The specification and the client need to be updated. So, the conclusion is that RFC and all client implementation following that RFC are wrong and should be changed. That isn't helpful, is it? Obviously the RFC was not changed in the past 20 years. The question remains, what can OpenLDAP do to provide reasonable compatibility with the facts? I think OpenLDAP should at least return the userSMIMECertificate data when asked for userSMIMEcertificate;binary (just as it returns userCertificate;binary when asked for userCertificate). If understand it correctly, this was suggested in https://www.openldap.org/lists/openldap-devel/199904/msg00037.html back in 1999. -- You are receiving this mail because: You are on the CC list for the issue.
