* Kevin J. McCarthy <ke...@8t8.us> [2015-05-17 19:39 -0400]:
Thank you for taking the time to write a detailed response to my request for help! Although I'm trying to fix up this script, I don't actually use S/MIME in mutt, so I appreciate the information.
You're welcome: I was hoping to get to fixing it myself, but the work schedule has not been kind.
David J. Weller-Fahy wrote:1. I think leaf certificates should be handled differently than issuer certificates. This also allows implementation of a simple solution first while a more complex solution is pondered... more about that later.Okay, so your suggestion would be to split out the leafs from the issuer/intermediary certs, and store them separately. This would be the same approach used by add_pem: when it adds the leaf cert, it would include the issuer hash for validation.
Yes.
c. Scenario 3 would be that the issuer certificate does exist in the smime certificate repository, and the copies are not identical, at which point the user is warned that something fishy may be happening, and no action is taken.Well, some improvement can certainly happen for this. Right now, it's easy enough to issue a warning if the cert already exists (I believe it does this already).
It does.
Part c would involve having a way to query by issuer, which I could use some pointers for.
I'm not sure what to do about that, but I was leaning toward a simple solution (at first) which would not include Scenario 3 (or c, I need to watch my alpha/numeric lettering/numbering mixtures ;)). Perhaps just adding a bug indicating this needs to be examined further later, but ignoring the possibility right now, might be a decent solution. I'll play with these (later in the week, first part will be too busy) to see if I can get two issuer certificates that are supposedly the "same" but not identical, but this may be something mutt shouldn't handle.
3. There are two issues with the leaf certificate(s) handling (there may be more than one).I didn't realize there might be more than one leaf in a single file, and wasn't aware there would be a problem separating out the sign-vs-encrypt certs later.
Yep, that's what started me down this road. When I import certificates from signed emails there is a root certificate, an intermediate issuer certificate, and two leaf certificates (one for encryption and one for signing). I don't know the use of including the signing certificate (perhaps it's my ignorance of S/MIME, but I don't think I'd even need it around), but I hesitate to not import it if its offered, under the assumption that they wouldn't offer it if I didn't need it.
Is there some way to tell the difference between them inside mutt when encrypting with S/MIME?
Yes. Mutt presents you with the proper encryption key if two certificates are present for the same ID (email address in this case). I just figured this out because your question made me curious. Some background on how the certificates are stored: The suffix of each file (the '.0' at the end of the certificate) is incremented for each consecutive certificate for the same ID. If you had encryption and signature certificates, and I imported your keys (using Ctrl-k and assuming I was using the kb.wisc.edu smime_keys patch), then I would have two keys (besides your issuer keys) in my store. Assuming the hash for your keys was 239847 then the first key extracted would be '239847.0', and the second could be '239847.1'.
Looking inside smime.c, I don't see any indication that mutt distinguishes between function when you are looking for keys to encrypt an email. How do you (or mutt) currently deal with this?
If I then try to encrypt a message to you the one that can be used for encryption is presented as the one to use. If that were the second certificate, then the prompt would be as follows. #v+Use ID 239847.1 for ke...@8t8.us ? ([no]/yes): #v-
So it already figures out which one is to be used for encipherment. Given that mutt already figures out which key to use it may not be necessary to make sure the keys are added in order of their use. That would be my preference, but it's certainly not necessary. Hope that helped, -- dave [ please don't CC me ]
signature.asc
Description: PGP signature
