On 11/27/2018 03:33 PM, Gordon Messmer wrote:> On 11/25/18 5:35 AM, Alice Wonder wrote: >> The "free for personal" S/MIME from Comodo didn't work. Browser said >> it did but there was nothing to export for me to then import. I >> suspect it is because I used private browser window, > > > Probably, yes.? I've used that service in the past without issue. > > >> I really don't like the idea of a private key stored in browser >> anyway. And it never asked for a password to encrypt the private key > > > Setting a password will protect all of the certificates stored by > Firefox.? Select: Preferences -> Privacy and Security -> Security > Devices (under Certificates) -> Software Security Device -> Change password > > Chrome may have a similar option, but I don't see it and I don't see > documentation for it.\ > > >> nor let me specify key strength (only let me choose between medium and >> high - I assume high is 4096 but I don't know, it didn't say) > > > There's very little harm in getting a certificate and examining it to > find out.? You can destroy it later with no ill effect. > >I actually went for a more complex scenario, I've created my own CA complete with CRL. 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. And I have multiple e-mail accounts I want to do thus with. Could have done self-signed too but this at least allows me to revoke if a device like laptop or phone w/ private key is stolen. Does mean those who want to confirm my messages have to import my root key but that's for them to decide. 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.
> Am 28.11.2018 um 00:47 schrieb Alice Wonder <alice at domblogger.net>: > > On 11/27/2018 03:33 PM, Gordon Messmer wrote: >> On 11/25/18 5:35 AM, Alice Wonder wrote: >>> The "free for personal" S/MIME from Comodo didn't work. Browser said it did but there was nothing to export for me to then import. I suspect it is because I used private browser window, >> Probably, yes. I've used that service in the past without issue. >>> I really don't like the idea of a private key stored in browser anyway. And it never asked for a password to encrypt the private key >> Setting a password will protect all of the certificates stored by Firefox. Select: Preferences -> Privacy and Security -> Security Devices (under Certificates) -> Software Security Device -> Change password >> Chrome may have a similar option, but I don't see it and I don't see documentation for it.\ >>> nor let me specify key strength (only let me choose between medium and high - I assume high is 4096 but I don't know, it didn't say) >> There's very little harm in getting a certificate and examining it to find out. You can destroy it later with no ill effect. > > I actually went for a more complex scenario, I've created my own CA complete with CRL. > > 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. And I have multiple e-mail accounts I want to do thus with. > > Could have done self-signed too but this at least allows me to revoke if a device like laptop or phone w/ private key is stolen. > > Does mean those who want to confirm my messages have to import my root key but that's for them to decide. > > 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. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centosWell, your own CA?s certificates are basically self-signed. It?s of course a free country and you can do what you want - but in your case, you could just as well use GPG and be done with it. You could place your GPG public key where your root-certificate is placed and people could download and import that public key. The point of S/MIME is that there is a central authority to validate the owners of the certificates and no peer-to-peer fingerprint checking etc. a la GPG/PGP is needed. It does have better native support in MUAs, I?ll give you that.
On Wed, 28 Nov 2018 00:54:12 +0100 Rainer Duffner <rainer at ultra-secure.de> wrote:> It?s of course a free countryhaven't heard that for quite a while... d -- In modern fantasy (literary or governmental), killing people is the usual solution to the so-called war between good and evil. My books are not conceived in terms of such a war, and offer no simple answers to simplistic questions. ----- Ursula Le Guin
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.> 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).
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.