Julien Pierre wrote:
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.
I tried that, thanks!
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 .
Well, there's a vote for denying people access to S/MIME unless they go through CAs. I personally don't see how that can fit with Mozilla's goals and ethos, especially as it is intended to deliver security to the average user. Who, we are all agreed, is not going to go through a CA just to send an encrypted email. It just ain't gonna happen, even CACert is too expensive for the average user.
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.
A false sense of security only arises if we techies tell them its secure, when it isn't. Simple solution to that is ... don't tell them it's totally secure. Just tell the truth - it's secure against eavesdroppers.
Most users are not as dumb as techies think.
If you just come out and say "this encryption system is not perfect, but it's free. It has some quirks to it, so don't trust your best secrets to it..." they'll understand.
It's a bit like WEP, conceptually, which can be cracked in seconds. You don't see too many people saying "turn off WEP, you'll be more secure because you won't have 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.
Most average users have out of band channels with most people they email. It is only us techies that spend most of our lives glues to our screens emailing people in other continents that don't have out of band channels.
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 .
My goal is security, not preservation or destruction of one or more products. I couldn't care less about S/MIME, PGP, browsing, or TCP/IP. I only care about whether the users have some security.
I see security in S/MIME, dormant. What would it take to enable that? Make it spread virally?
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 .
LOL... No, the problem with all the above is that you have not and you cannot define security.
In terribly brief terms, anything you come up with will probably be self-referential or subjective. You literally cannot deliver any security to the user until you have defined it, and as a point of fact, in the PKI world, security is undefined except as "what we do" or the like.
Which means it is not defined in terms suitable for anyone to say this is better than that.
...
S/MIME requires the sending party to know his recipient's public key. That key is embedded in X.509 certificates.
Sorry, yes, I did discover later on that this is simply an implementation choice. The S/MIME standard doesn't say how the certs should be delivered, so there should be no problem in variants.
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.
Yes, although if the petnames system were in place this would be a defence against that. Not that this would be a big deal, I don't see self signed certs as anymore than a kludge to enable S/MIME for later upgrading. I'd happily accept fake emails if I knew I could encrypt to the 10 or so people I share secrets with.
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.
Yup. An MITM.
But is that security ? I think it's just messing with crypto .
That's security. At least, let's define today's security as "defeats all passive eavesdropping attacks, with known and acknowledged weaknesses against active MITMs."
Now, why would that be valuable? Because that happens to be the threat to the average user. (Barring phishing that is :) For the most part, the most stuff that users need to worry about is eavesdroppers like their own family members, people on their subnet listing to their 802.11b or cable segment, or people in the ISP. These attackers don't do active attacks.
Covering this threat is a valuable thing. Leaving out the far more remote threat of an active MITM is a useful compromise. If it can be done for free, that's a great deal.
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 .
I'm sorry, but that's not logical. If people start using self-signed certs, and they discover that it doesn't stop spam and fake e-mails, they are not going to say "oh, you sold me a bill of goods, you lied!" They'll say "oh, and what do I need to stop spam and phishing?"
And then you can say - if you so desire - "self-signed certs are good enough for stopping eavesdroppers, but if you really want to *identify* people, then you need to get a CA signed cert. PKI could make a difference there."
What you asking for in advocating for self-signed certs is basically reducing the value of S/MIME to zero.
I'm sorry, I don't understood why using one sort of cert somehow blocks off any other sort of cert in an email program? I can see that it might present an exclusive-or choice in browsing ... but not surely in an email program?
Can't thunderbird handle multiple certs? Is there some critical bit in self-signed certs that breaks things?
If PGP email is "secure", and most PGP email is not signed or WoT-checked, then what makes S/MIME incapable of benefiting from the same effect?
Anyways, as Wren said, this is a polemic. The real security action is over in the phishing area, and I hope Frank can get his policy pushed through pdq!
iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ _______________________________________________ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
