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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
