Hi David, 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.
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. > b. Scenario 2 would be that the issuer certificate does exist in the > smime certificate repository, and both copies are identical, at > which point the certificate is not added and an informational note > is printed (similar to current behavior). > > 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). Part c would involve having a way to query by issuer, which I could use some pointers for. > 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. Is there some way to tell the difference between them inside mutt when encrypting with S/MIME? 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? thanks, -Kevin
signature.asc
Description: PGP signature
