[Apologies to Kevin and Bernard: the first email went to their individual email accounts but was supposed to go to the list.]
It is evident from the answers that I need to review the how to ask questions the smart way page [1], but I've solved the problem (although the solution is not elegant). A better explanation of the problem is inline, and the solution is at the end (for the TL;DR crowd). [1] http://www.catb.org/esr/faqs/smart-questions.html * Kevin J. McCarthy <ke...@8t8.us> [2015-04-03 23:37 -0400]:
I don't use S/MIME either, so I hope you'll pardon me if this isn't helpful.
All thoughts are helpful in at least one way. :) * Kevin J. McCarthy <ke...@8t8.us> [2015-04-03 23:37 -0400]:
To start, my impression was that (like GPG) encryption usually uses the recipients key, not your own key. You'll usually use your own key just for signing and decryption.
* Bernard Massot <bmas...@free.fr> [2015-04-04 13:19 -0400]:
What's that protocol? Until known I've only heard of sender's private key to sign and decrypt, and recipient's public key to encrypt. ... I do use S/MIME with Mutt, although only for signing. I may help, but before we have to make clear what this "three keys setup" is.
Indeed: You're both correct. My description was not clear enough, so let me start over because I may be misinterpreting what I'm seeing. First, the protocol is the same as you would imagine: sign or decrypt with your key, encrypt with the recipient's key. When I was referring to encrypting with my key, I was referring to always encrypting to my key when I encrypt a message to someone else (so I can review the messages if needed). In Thunderbird I see two certificates that (in the parlance of Thunderbird) "identify me". The first (c1) has the Certificate Key Usage set to the following. #v+ Critical Key Encipherment #v- The second (c2) has the Certificate Key Usage set to the following. #v+ Critical Signing Non-repudiation #v- This, along with further research (best summed up by this bit [1] in Wikipedia) led me to believe that the those are both private keys. Upon further reading (inspired by your responses) I discovered that it's not that there are two private and one public keys, but there are two key-pairs (apparently). When I export each Thunderbird "identity" using "Backup...", then I get a *.p12 file for each (c1.p12 and c2.p12). I can then examine them using keystore-explorer [2] (a handy tool that i discovered because of this conversation), and see the two separate key-pairs. [1]: http://en.wikipedia.org/wiki/S/MIME#S.2FMIME_certificates [2]: http://keystore-explorer.sourceforge.net So: it looks like I have two key-pairs (one for decryption, the other for signatures), and I have finally figured out how to configure mutt to use these for their intended purpose. In my attempts to properly set things up, I ran into a number of obstacles, the first of which was the lack of CAs for my employer on my system (which prevented the certificates/keys from importing at all!). Another (which I think led me down a wrong path last time) was a failure when I added the signing key to the smime certificate and key store: #v+ error 26 at 0 depth lookup: unsupported certificate purpose OK #v- Initially (a few months ago) when I received that error I thought it meant the key wasn't being imported properly. So every time I hit that error, I abandoned that path. However, looking into the error now, I see it is simply because there are some purposes in the key that are not recognized, but it still validates (otherwise it wouldn't be placed in the key store). With this latest foray into getting mutt to work, I've achieved what (before) didn't happen: I have both key-pairs imported into the smime store, and can sign, encrypt, and sign and encrypt emails and those all are validated and decrypted properly in both Thunderbird and mutt! The reason it wasn't working was two-fold: 1) The last time I did this I must not have imported the *.p12 files correctly, because I never ended up with the signature and encryption key-pairs properly stored in the key store. 2) The S/MIME implementation in mutt is set to automatically think the signing key will be the decryption key. * Kevin J. McCarthy <ke...@8t8.us> [2015-04-03 23:37 -0400]:
That said, I would suggest looking into customizing the $smime_encrypt_command, $smime_sign_command, and $smime_decrypt_command options inside your .muttrc.
As you indicated, the fix was relatively simply once I made my brain work, and only required the modification of two commands in the smime.rc file: smime_encrypt_command and smime_sign_command. This is not elegant, as it requires hard-coding the files into the commands (and thus makes the display of the signing or encrypting key id in mutt superfluous), but it works, and elegance can come later. Also note that I made the encryption key the default, as that is the one that is automatically accessed when mutt tries to decrypt a message, whereas the signing key is only used when a signature is created. Set smime_encrypt_command to the following, where [DECRYPT-CERT] is replaced with the path to the certificate portion of your decryption key-pair (~/.smime/certificates/something.0). #v+ openssl smime -encrypt -%a -outform DER -in %f %c [ENCRYPT-CERT] #v- Set smime_sign_command to the following, where [SIGN-CERT] is replaced with the path to the certificate portion of your signature key-pair, and [SIGN-KEY] is replaced with the path to the key portion of your signature key-pair. #v+ openssl smime -sign -signer [SIGN-CERT] -inkey [SIGN-KEY] -passin stdin -in %f -certfile %i -outform DER #v- So. A long and torturous email, but success at the end. Now to look in the mutt source code and see if adding an "smime_default_signature_key" would be difficult. Thanks for the nudges! -- dave [ please don't CC me ]
signature.asc
Description: PGP signature
