wurstsemmel wrote:
The behavior of Tb arises from its handling of the S/MIME capabilities. KMail requests an algorithm (I think AES), which Tb does not support. In this case Tb seems to fall back to RC2.
please write a bug about this. https://bugzilla.mozilla.orgProduct would be under 'Other' and should be NSS. (We'll sort out NSS versus PSM).
There are several separate issues here: 1) NSS is not matching on AES. - This is the biggest issue.2) For some reason NSS is not negotiating 3DES (is KMail sending 3DES in the profile. If not, that's a KMail bug). 3) We probably should have a single button to disable weak crypto (which would disable RC2-40), or better yet disable it by default.
Now technically KMail MUST implement RC2-40 (is the implementers confusing RC2 with RC5?) according to the S/MIME spec (all implementations must support RC2-40. All strong implementations must support 3DES). In practice the number of weak implementations out there has declined, so we may want to rethink our defaults in NSS to be 3DES unless we have some hint the recipient is a weak client.
Tb uses 3DES (which it normally does - communicating with other Tb), if you import the certificate manually. As soon as you reply to a KMail eMail by using the "Reply" - button it uses RC2 again.Sounds like KMail isn't including 3DES in it's profile. If you get a certificate without a profile, NSS will assume the profile includes 3DES and RC2-40 if the public key size is 1024 or greater and just RC2-40 if the public key size is less than 1024.
Are there about:config entries for at least one of the following proposed solutions:a) Disable RC2 in Tb. b) Set the default fallback to 3DES. c) Switch on AES. d) disable interpreting of "smimecapabilities" The original thread is at http://forums.mozillazine.org/viewtopic.php?p=2858116#2858116Interesting readings: http://kb.mozillazine.org/Message_security and http://www.mozilla.org/projects/security/pki/nss/nss-3.11/nss-3.11-algorithms.htmlIn http://www.gossamer-threads.com/lists/gnupg/devel/40286 and http://www.gossamer-threads.com/lists/gnupg/devel/40396 "wk at gnupg" stated, that it is not a problem of gpgsm.**_He thinks, that this is a bug in Tb, which should be fixed._**The keys mentioned by "patrick at mozilla-enigmail" are set to false (by default).
I think there is enough issues on both sides.1. Disabling weak crypto by default is a decision we should make independent of KMail interoperability. 2. If KMail is sending AES in the profile, NSS should be using it. (potential AES bug). 3. It looks like KMail is not sending all of it's profile information, particularly 3DES (KMail bug). 4. The S/MIME spec requires accepting RC2-40 by all S/MIME implementations. KMail clearly falls down there.
KMail will face the same interoperability problems with OE, which runs home to RC2-40 much more often than NSS...
Anyway thanks for the report! There are issues that we need to deal with here. (BTW, if you put TB in FIPS mode, does the problem go away?)
bob
Thank you very much for your help, wurstsemmel _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
