Summary: | more control for security multiparts (e.g. S/E/S or E/S/E). | ||
---|---|---|---|
Product: | [Applications] kmail | Reporter: | bruce.lilly |
Component: | encryption | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED WAITINGFORINFO | ||
Severity: | wishlist | CC: | luigi.toscano |
Priority: | NOR | ||
Version: | 1.8.1 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
bruce.lilly
2005-06-09 05:02:44 UTC
We're implementing standards, so ietf-openpgp and ietf-smime mailing lists seem more appropriate for this stuff to be dicussed and codified than the KMail bugtracker. On Thu June 9 2005 01:48, Marc Mutz wrote: [bugs.kde.org quoted mail] PGP/MIME (RFC 3156), a product of the openpgp WG, and S/MIME are based on a layering approach using the security multipart media types defined in RFC 1847. The example given in the wishlist item uses those types and is fully compatible with RFC 3156. The problem is that Kmail provides no way for a message author to specify specific construction of a secure message; the only mechanisms that are provided have known security holes and fail to provide what is implied (e.g. a message with attachments, and specifying that the entire message should be signed fails to sign the attachments). Note that the example provided was just that -- an example. Some authors may wish to treat some messages differently, e.g. by first signing, then encrypting the signed content, then signing again the encrypted data. Bruce, I've skimmed through the paper now. This is not a technical problem, but a social one. One part of the problem (Alice loves Charlie) can be addressed by making sure you properly address the recipient inside the signed part ("Hi Bob, I love you. Alice."), the other part (forwarding of sensitive information received encrypted and then claiming the sender hadn't encrypted in the first place) could be addressed by S/E/S, but that leaks AFAIK. That leaves E/S/E, which can be had by attaching already encrypted attachments. I agree that it _might_ be nice to more narrowly control how the various multiparts are nested by KMail, but cryptography is already hard enough to grasp for the Average User (as much as I hate bringing that into a discussion, but for cyptography, that's the sad reality ATM). Bringing in these options has always the danger of luring the user into some false sense of security. So has the current way of doing things, but unless S/E/S or E/S/E becomes common practise, it's hard to argue about the added user complexity. I'm reopening it under a new summary, let's see whether someone find it attractive enough to implement. Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding. Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2. |