On 11/28/2018 07:58 PM, Gordon Messmer wrote: > On 11/27/18 3:47 PM, Alice Wonder wrote: >> I actually went for a more complex scenario, I've created my own CA >> complete with CRL. > > > OK. That means fewer certificates for your peers to install over time, > but is otherwise no better than self-signed. > > >> It's nice because with S/MIME you really want two certs - one for >> signing (where ecdsa can be used) and one for when you need to receive >> encrypted. > > > IIRC, an S/MIME client should be able to install your public cert and > encrypt messages sent to you with no user interaction. With > Thunderbird, if I reply to a signed message, I can encrypt the reply. > From a usability standpoint, I really want to have just one > certificate. The easier it is to send me encrypted messages, the more > likely it is that messages will be secure. A) For one certificate to do both it has to be an RSA cert but the primary use of S/MIME is signing where RSA is excessively bloated compared to ECDSA. B) Certs for encryption have to have a backup key somewhere so there isn't data loss if I lose the private key, and that key needs to be w/o a pass phrase in case something happens to me and someone else needs access to the encrypted messages. But having such a backup means it isn't safe to use for digital signing because the backup is a theft risk, so signing with that key to prove it is me isn't a great idea. > > >> Web browsers are applications that exist for the explicit purpose of >> downloading and executing untrusted code. It does not seem like that >> is a very wise environment to use for generating long term >> cryptography keys. It really doesn't. > > > On the other hand, if you don't trust your browser's cryptography > implementation, you definitely should not be using your browser for > secure communication (https). https is handled by a TLS library outside the browser, which is vastly different than in browser generation of private keys.