Hi Julien,
Julien Pierre wrote:
Ian,
Ian G wrote:
For encryption, just now I tried again, and I may have figured out the problem: it requires me to select a certificate, which wasn't obvious the first time I went through the various dialogues; it should just automatically select the one cert that is there (actually it should automatically create, sign and select a cert on install time .. but that's another debate).
That's making a pretty big assumption - that you only have one cert in the database that matches your email address(es).
Hmm, ok, well I suppose that's true as an assumption, and looking at Account / Settings ... the cert that is now selected to sign for this email address is *not* for this email address. This may explain why it didn't in the end sign for this email ;-)
File a bug on the UI - it should be able to filter on e-mail address in the drop-down list, and either show only the matching certs, or warn you if you try to select one that doesn't match the account e-mail address.
So now I have to figure out how to find a cert for this email address. Now given that it took like 10 minutes of clicking around by an expert in the CA's business to do with the one cert I've got, I'm not hopeful!
Especially as there is no button to create a cert.
That's usually done by visiting a CA's web page and going through the enrollment process .
They are, at least in Mozilla mail. One of the buttons, between "spell" and "save, is called "security". It's got a drop-down menu to select encryption and/or signing.
AHHHH.... that's what that funny little thing on the button is. OK, that's better.
It confused me the first time too ...
1. it should create and select a cert on install.
That would require a relationship with a CA and automated protocol.
No, create the cert without a CA and self-sign it. I know you won't like that, but IMHO until that is done, S/MIME mail will never take off.
That's if you consider that self-signed certs have any value, and that there is any benefit to having people deploy S/MIME with self-signed certs, vs users not deploying S/MIME. IMO, there isn't, and the later is actually preferrable to the former .
I know you disagree on that point, but nevertheless, deploying S/MIME with self-signed certs will just give users a false sense of security. Most people have no out-of-bounds channel to help them make the decision of trusting a self-signed-cert or not. And once trusted, these self-signed certs cannot be revoked, because they are roots, as somebody else already pointed out.
If you want to use that kind of environment without any binding of key to identity, there are other protocols available, such as PGP. Keep self-signed certs out of S/MIME .
There is no basis to _require_ a CA to handle email, that's something that should be optional and for companies, mostly.
It should be required for any reasonable understanding of the word "security". If everybody used self-signed certs, then the "security" button should be replaced with "screwing myself with crypto I don't understand", instead .
Besides, the install time wouldn't be the right time to do it, or at least not the only time. E-mail account creation time would be.
Oh, yes, excellent point.
For signatures, that's less interesting to me, but I'll try to sign this email, and if that works, it will be because the Cert was not selected.
Signatures are the way encryption certificates are transmitted, so they are rather crucial. If you don't sign your messages, people won't be able to write you encrypted messages.
? Why is that? Why do I need to sign a mail to send a cert? Why can't the cert be sent anyway, anytime?
My personal policy (and recommendation) would be to never sign email, because it has no clear meaning. At least in OpenPGP it is undefined what the meaning is, by definition! But in S/MIME, I don't know what it is defined to mean.
So this would result in encryption being denied. That's ludicruous! Is that in the standard?
S/MIME requires the sending party to know his recipient's public key. That key is embedded in X.509 certificates.
Therefore, the very first time two people want to communicate with encryption using S/MIME, one party needs to send his certificate to the other. That's typically done by sending an unencrypted, signed message. It's not required to be done that way. It can be distributed by other means as well, such as LDAP directories.
The S/MIME signature provides proof the sender is in possession of the private key matching the public key in his certificate. The certificate establishes the key was issued to the owner of the e-mail address.
If a self-signed certificate was used, anybody could send a fake email, signed with a self-signed cert, and there would be absolutely no way for the recipient to know that it didn't come from the legitimate owner of the email address listed in the certificate.
The recipient might respond with an encrypted message, decipherable only by the attacker. If the attacker was somehow able to intercept the response, he might now be in possession of information that the recipient divulged only because he thought he was using a "secure" channel.
But is that security ? I think it's just messing with crypto .
If you think the above scenario is far-fetched, think about how much spam and fake e-mails you get in a day. If self-signed certs are acceptable, then the only thing stopping the attack above is trusting that the encrypted e-mail response never gets intercepted. That's a risk PKI is supposed to make irrelevant .
What you asking for in advocating for self-signed certs is basically reducing the value of S/MIME to zero.
_______________________________________________
Mozilla-security mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-security
