https://bugs.openldap.org/show_bug.cgi?id=9540
Issue ID: 9540 Summary: userSMIMECertificate needs to be binary Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs@openldap.org Reporter: openldap.ms@savignano.net Target Milestone: ---
OpenLDAP uses inetOrgPerson.schema with the following note on userSMIMECertificate attribute:
# userSMIMECertificate # [...] Values for # this attribute are to be stored and requested in binary form, as # 'userSMIMECertificate;binary'. [...]
but a line is added saying specifically
## OpenLDAP note: ";binary" transfer should NOT be used as syntax is binary
This seems to make no sense. According to RFC 2798 which define inetOrgPerson and the useSMIMECertificate (first comment is quoted from there), this attribute must be stored and requested as userSMIMECertificate;binary. OpenLDAP does not do so. I don't understand the explanation "as syntax is binary".
This leads to problems with clients following RFC 2798 and requesting the attribute as userSMIMECertificate;binary because OpenLDAP does not send userSMIMECertificate instead, but sends nothing at all (as if attribute would not exist).
I think this is a bug. OpenLDAP does not follow RFC 2798 and this causes compatibility problems.
https://bugs.openldap.org/show_bug.cgi?id=9540
--- Comment #1 from Metin openldap.ms@savignano.net --- 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.
https://bugs.openldap.org/show_bug.cgi?id=9540
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org --- As noted, the RFC is informational, not a standard.
And it's clearly wrong.
https://bugs.openldap.org/show_bug.cgi?id=9540
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
https://bugs.openldap.org/show_bug.cgi?id=9540
--- Comment #3 from Metin openldap.ms@savignano.net --- Thanks for your reply.
However, I feel it does not answer the question how OpenLDAP can provide reasonable compatibility?
Forgive me, but IMHO, it's not a good answer to real-world problems to insist on "it's not our problem". Thanks for re-considering.
https://bugs.openldap.org/show_bug.cgi?id=9540
--- Comment #4 from Michael Ströder michael@stroeder.com --- On 5/3/21 5:00 PM, openldap-its@openldap.org wrote:
However, I feel it does not answer the question how OpenLDAP can provide reasonable compatibility?
Can you clearly define what "reasonable compatibility" really means in this case?
Forgive me, but IMHO, it's not a good answer to real-world problems to insist on "it's not our problem". Thanks for re-considering.
Could you please elaborate on which LDAP client is affected?
And are you and the developers of this LDAP client aware that originally this attribute was meant to carry a signed S/MIME message with empty body to also carry the S/MIME capabilities of a client?
The only client I know of which supported this was Netscape Communicator 4.x back in '98 last century. This was a user self-service action (because it involved signing with the user's private key which was protected with passphrase). After that I never saw a client making correct use of this attribute.
Ciao, Michael.
https://bugs.openldap.org/show_bug.cgi?id=9540
--- Comment #5 from Metin openldap.ms@savignano.net --- (In reply to Michael Ströder from comment #4)
Hi Michael,
Thanks for your reply.
And are you and the developers of this LDAP client aware that originally this attribute was meant to carry a signed S/MIME message with empty body to also carry the S/MIME capabilities of a client?
Yes, we are aware of that, and that's how we've implemented our software.
But I wasn't aware of this:
[...] After that I never saw a client making correct use of this attribute.
I was speaking of MS Outlook, but now I've performed a few more tests with Thunderbird and Apple Mail, and neither of them did accept the format. Not sure if they did not accept the LDAP attribute or didn't know how to make use of it, but I admit I'm baffled.
Can it be true that this attribute was never ever implemented properly in any of the (widely used) email clients? How disappointing!
Now I understand why my request was rejected. There is nothing that could be reasonably compatible.
Thanks Metin
https://bugs.openldap.org/show_bug.cgi?id=9540
--- Comment #6 from Michael Ströder michael@stroeder.com ---
(In reply to Michael Ströder from comment #4)
And are you and the developers of this LDAP client aware that originally this attribute was meant to carry a signed S/MIME message with empty body to also carry the S/MIME capabilities of a client?
Yes, we are aware of that, and that's how we've implemented our software.
So you're signing with the user's private key? How? Do you have key escrow?
But I wasn't aware of this:
[...] After that I never saw a client making correct use of this attribute.
I was speaking of MS Outlook, but now I've performed a few more tests with Thunderbird and Apple Mail, and neither of them did accept the format. Not sure if they did not accept the LDAP attribute or didn't know how to make use of it, but I admit I'm baffled.
The Mozilla folks hunked out almost all LDAP features from the ancient Mozilla suite many moons ago, mostly the ones regarding S/MIME certs. These features never came back.
Nowadays it's even harder to enroll for S/MIME certs without manual PKCS#12 import.
Can it be true that this attribute was never ever implemented properly in any of the (widely used) email clients?
Yes, exactly. And that's why this ticket is a bit about trying to ride a dead horse. Sorry.
Ciao, Michael.
https://bugs.openldap.org/show_bug.cgi?id=9540
--- Comment #7 from Metin openldap.ms@savignano.net --- Hi Michael,
Sorry for the delayed reply.
(In reply to Michael Ströder from comment #6)
And are you and the developers of this LDAP client aware that originally this attribute was meant to carry a signed S/MIME message with empty body to also carry the S/MIME capabilities of a client?
Yes, we are aware of that, and that's how we've implemented our software.
So you're signing with the user's private key? How? Do you have key escrow?
No, we're not creating this attribute, but we're just using it in the intended way to send encrypted email, and we also consider the client capabilities if they are set. However, that's not the case with most email clients.
I guess, capabilities don't make much sense nowadays when many of us use multiple mail clients for the same mailbox.
The attribute can be created by the users themselves very easily by sending a signed message.
Yes, exactly. And that's why this ticket is a bit about trying to ride a dead horse. Sorry.
Accepted.
Thanks for taking time to explain.
Cheers Metin
-
openldap-its＠openldap.org