Proposed patch for libksba: make SMIMECapabilities parameter encoding conform to RFC
stvdo at gmx.net
stvdo at gmx.net
Thu Feb 21 08:45:44 CET 2008
there are a lot of complaints around concerning interoperability of S/MIME encrypted Mails between Thunderbird (using its own S/MIME Library) and KMail (using gpgsm), see, e.g.
The root of the problem seems to be that gpgsm/libksba does not encode algorithm parameters in conformance to the RFC http://www.apps.ietf.org/rfc/rfc3851.html#sec-2.5.2:
"[...] The registered SMIMECapabilities list specifies the parameters for OIDs that need them, most notably key lengths in the case of variable-length symmetric ciphers. In the event that there are no differentiating parameters for a particular OID, the parameters MUST be omitted, and MUST NOT be encoded as NULL."
Using libksba, absent algorithm parameters always result in a TYPE_NULL identifier of length zero which is a MUST NOT according to the RFC.
When exchanging signed/encrypted Mails between KMail and Thunderbird, Thunderbird reads the SMIMECapabilities section, but refuses to accept any algorithms for which the parameter encoding is not strictly conform to the RFC. Thunderbird in that case falls back to RC2/40 encryption (weak!) and in turn KMail cannot decrypt any S/MIME encrypted Mail sent by Thunderbird, because gpg does not include RC2/40 due to its weakness and patent problems.
At http://www.intevation.de/roundup/aegypten/issue754 I have filed a possible patch for libksba which corrects the encoding of absent parameters in SMIMECapabilities. However, I don't know whether the bug tracker is actively monitored and by whom. So I'd like to announce the patch on this mailing list, too, and ask for a carefull review.
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1123 bytes
Desc: not available
More information about the Gnupg-devel