Ian,
Ian G wrote:
Right, but considering that this is *email* and CAs are simply some optional extra to do with commercial users (and we saw what they want) then when it comes to *email* there is no need to bash anyone's head over any issue.
There is nothing in X.509 or S/MIME specs that says CAs are "simply optional extra to do with commercial users" ! That's only your mischaracterization . In fact to be able to verify a cert, you need to supply a known list of trust anchors as input. A self-signed cert isn't an exception. To verify it, you need to have previously trusted it .
Thus, for individual users' self-signed certs to work, everybody would need to blindly trust everybody else's individual cert. I don't see how you expect that to actually be workable.
In email, you and I know each other and we don't need any CA to tell us that.
That's what you may think ! Emails travel through a myriad of servers, routers, in a non-realtime fashion, and are very susceptible to attacks such as interception. An MITM attack that may be relatively difficult to achieve with real-time SSL is much easier to do with e-mail.
Later on, as an option, we may very well want to go to the CA and ask for "a third opinion" just like one might go to the doctor and ask for a "second opinion" if one is diagnosed as due to kick the bucket tomorrow. But this should be strictly optional, the email application should be built on self- signed certs as a primary principle.
Using your analogy, I conclude that when you go see a doctor the first time, you don't want to know whether he is licensed.
Anyway, it's a terrible analogy. With e-mail, there is nothing that proves your prior relationship, as there is with a physical meeting with your doctor.
E-mail accounts get hacked into all the time. Unless you verify identity externally, an e-mail address by itself is not sufficient to establish trust. You could read your self-signed certs' fingerprints to each other over the phone before trusting them, and that would be secure . But a CA is a a much more practical, generic, and scalable, way to go.
I wouldn't object to self-signed certs if the UI to trust a self-signed cert you just received (either via SSL or S/MIME) required you to type in the fingerprints in the cert you expected, without the ability to see anything in the actual cert but its DNSname or email address. Trust would be added only if there was a match. I suspect most people would not be able to confirm the fingerprints, and thus would not blindly trust any self-signed certs they received . They would then figure out it's better to use CAs after all.
No, public key encryption does not require that you need to use the signed email feature to distro the keys. You can use ordinary email, you can use key servers (in fact that's what x.509 assumed, a worldwide 'telephone directory' for all the people onthe planet or somesuch), you could use biz cards with barcodes...
The signed email allows proof-of-posesssion of the key of the sender.
Just reading the public key in the cert doesn't. It's not strictly required, but the signed message actually adds security, especially if the message is signed with a key contained in a cert that somebody else (ie. a CA) vouched for, not a made-up self-signed cert .
What specifically I am referring to there is that the S/MIME application has decided to make its operation *dependent* on signed emails. That's not good, neither from an architectural pov nor a meaning pov (as described above).
It isn't dependent on it. Mozilla already supports LDAP lookup of certs by e-mail addresses for S/MIME. This works well in intranet corporate environments. It breaks down in the public internet, because there is no worldwide public directory of certs to e-mail addresses, unfortunately.
Fortunately, when you configure LDAP lookups in mozilla, S/MIME will look up your recipients' cert in LDAP, in addition to your local certificate database, not instea of it.
Right, so send an email with the key. Just don't force it to be a signed email, or don't hide the key exchange such that users are encouraged to "turn on siging" so as to get the key exchange.
You can send an unsigned e-mail with a copy of the cert as an attachment, but I don't think mozilla will process those messages. This bug has been on my plate for years and none of my management over the years at Netscape/AOL/Sun has ever found it important enough, so it's still in my queue at https://bugzilla.mozilla.org/show_bug.cgi?id=36246 . It doesn't look like any mozilla S/MIME user has ever cared, either ! But if you want to fix it, be my guest. I have 35 bugs assigned at this time, and the number never seems to go down - unfortunately, whenever I fix one bug, I invariably uncover 2 or 3 other previously unknown bugs ...
Coming back to the here and now ... I suppose the workaround is to turn off signing, and send an empty signed email to anyone you want to communicate with. OK, I can live with that!
Yes, that works fine. _______________________________________________ Mozilla-security mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-security
