Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
Ian G wrote: Right. And now we reach a big philosophical issue for Mozilla, which has been mooted upon in these very pages of late. Who is Mozilla for? Who is Tbird courting? If it's the average user a.k.a. Joe Sixpack, then we have one way of looking at how to secure his traffic. If it's Terry Techie, then we might expect him to learn the steps, the model, the customs. But not Joe Josephine Mixed Dozen. Now, I'm assuming the 'average user', because that's what I was told, and it's unfair to anyone to flip back and forth in a conversation. But, I do recognise that ... this has created a very big tension, especially in places like S/MIME, where the setup assumes Terry Techie, and Terry is quite happy with the product as it is. I agree. I think the answer is: both. Most of our users are Joe, but most of our developers are Terry. So we get this odd mix. My proposed solution: modal behavior. Out of the box, it's geared to Joe. But Terry finds the button in the prefs to enable advanced mode. -- Nelson B ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
Strongly agree. This the model that Apple uses in their systems and this is the only way to serve multiple user types well. Personally I like a brief interview type approach at initial install. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
Ian G wrote: 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. A 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
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
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,
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
Julien Pierre wrote: 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. I'd just consider it a step better than unprotected email. It's what you get for free, you get what you paid for. I know that my kid sister ain't gonna be listening any more and the next door neighbours won't be scanning for gossip either. Later on when it becomes important, I guess I'll need to upgrade the cert. (Marketing wise, CAs love this, or should. It gives them clear clues as to where to sell.) 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. Ever seen any? Ever heard of any? I know of one MITM attack on an unencrypted person where one would think that crypto might have made a difference. That's one victim in about 15 years of the net... I'm sure there are more, but there aren't enough to make a meaningful statistical model. Which means it isn't much of a threat. I know they are possible, I know they aren't hard, but they don't happen. They are not really a threat to users. Unless they happen. 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. As it happens, the last doctor I went to was run out of his country for some drunken surgery accident. He's quite a character, instead of giving a prescription he took a handful of pills out of this huge jar and gave me those. Worked fine, he's an honest doctor, and his reputation around the community was quite reasonable. But, yes, analogies can suck quite quickly :) 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 think you are mistaking my intention. I do not intend this suggestion to indicate to users that they are really benefiting in *identity* terms, only in encryption terms... Frankly, the business of reading finger prints is like the business of SSH users checking keys (even though some people say check the server key I don't even know how to do that ... and I use SSH all the time and have for many many years). Same in the PGP world, most people just encrypt, encrypt, encrypt. 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. Yes, show the finger prints, and offer a choice to select a match or a petname. And show a red pen or key instead of a blue one or something when an email comes in. No big deal. 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 ... :-) I wouldn't know where to start. Getting into something like these systems would take a least a month of hacking, and I'm currently drowning in my own project
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
Duane wrote: Ian G wrote: Ah, ok, I recall this being mentioned a squillion times. Now it happens to me :-/ So yea, now you know why it's important for mozilla guys to come up with a database that can be shared between both apps... Or that people would like to keep using the Mozilla Suite because of this perhaps? OK, so I manually installed the root from CACert into TBird. And ... yoohoo, this mail should go out signed :-) yup... ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Ian G wrote: | 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. | You are more than welcome to create a self-signed cert. But surely you are aware of the ramifications of such an approach. That's why we've been bashing our collective heads for these past months on Root CA policies eh - a shared common root? |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! That's news to me! People sign using OpenPGP all the time! |So this would result in encryption being denied. |That's ludicruous! Is that in the standard? Well yeah, that's why it's called public-key encryption. You somehow have to have your correspondent's public-key before encrypting to him. Most usually this is done via sending a signed-message beforehand. You may opt to have him ftp/telnet/ssh/carrier-pigeon the key, but nonetheless you gotta have it. - -- Cheers! J. Wren Hunt Cambridge, MA. USA - In theory, there is no difference between theory and practice. But, in practice, there is. - Jan L.A. van de Snepscheut +--+ | v-card http://wrenhunt.homelinux.org/data/wren.vcf | | x.509http://wrenhunt.homelinux.org/data/thawte_wren_hunt.cer | | OpenPGP ADF5 1432 A59E 8F4D 4AE7 4DFE 03FA 91E1 4A24 D6F4 | +--+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFCRV4cA/qR4Uok1vQRA2DiAJsFFJfrNCVBZ6aqRLpknIcMD6KB4wCg5MTz wAUr+8FxeuT7cmXCLjE4cyU= =ho02 -END PGP SIGNATURE- ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
J. Wren Hunt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Ian G wrote: | 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. | You are more than welcome to create a self-signed cert. But surely you are aware of the ramifications of such an approach. That's why we've been bashing our collective heads for these past months on Root CA policies eh - a shared common root? 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. In email, you and I know each other and we don't need any CA to tell us that. 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. (Now, browsing is a completely different app so these comments don't necessarily apply.) |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! That's news to me! People sign using OpenPGP all the time! Yes, exactly. Let me clarify: In S/MIME, I recommend not signing because I don't as yet understand what it means (and according to Simson Garfinkel et al's paper posted yesterday, there's little hope that the users know what it means). So what does it mean? In OpenPGP, there is no defined meaning to signing in the code or spec, so it means ... whatever the signer wanted it to mean. Which is *safe*. Sign away, it's whatever you want it to mean. So, what does it mean in S/MIME? We know it's not 'undefined' because there are CA signed certs involved And the RFC2633 says S/MIME provides: authentication, message integrity and non-repudiation of origin (using digital signatures) Or somesuch. (I haven't read it, I just found it by accident.) Maybe there's a better one somewhere in that doc, but that doesn't satisfy and it's got a red flag in it - non-reputation. So the conclusion should be the same as what the lawyers say - don't sign anything you don't understand. |So this would result in encryption being denied. |That's ludicruous! Is that in the standard? Well yeah, that's why it's called public-key encryption. You somehow have to have your correspondent's public-key before encrypting to him. 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... 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). Most usually this is done via sending a signed-message beforehand. You may opt to have him ftp/telnet/ssh/carrier-pigeon the key, but nonetheless you gotta have 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. 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! But it does make S/MIME much more clunky and less likely to deploy. 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
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
J. Wren Hunt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 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. | | In email, you and I know each other and we | don't need any CA to tell us that. | Well, I know who you purport to be. And currently I have no reason to doubt that you are indeed the esteemed Ian G! ;-) But I receive emails on a daily basis from those purporting to be from the late Yassir Arafat's widow, and the personal barrister of the late Mbeke Sese-Sese Seiko, etc., Do I believe them? Not likely. If I'm doing correspondence from someone whom I already have a close relationship with, for example family members, then an anonymous cert works perfectly. Any attempt at subterfuge (e.g., forging, etc.,) would most likely be easily detected as you *know* their writing styles, etc., Not so from a person who's persona you may be familiar with but not known to you personally (as would might be the case with many participants on this list to one another). Right, exactly. But the scenario you describe is not real world. Are you likely to do business with someone who purports to be the late Yassir Arafat's widow and she has a cert that just so happens to claim that? How many times have you ... needed to know who someone was, and then relied upon their cert? Me, I'd just pick up the phone. Not because the cert might be wrong, but because it doesn't say anywhere near enough to be reliable for a judgement that might be worth paying for. We all know the standard story about how you can't trust people over the net. What I'm saying is that for email, certs don't change that. They just don't enter into real life calculations for the average user. Even if the certs were deployed in a massive basis, and even if users understood them, they would not rely on them. They'd pick up the phone. (For commerce, that might be different, although Simson's paper might suggest otherwise.) So using the S/MIME infrastructure is strongly pointed at getting some encryption out there. That could be done any way we like, but making it depend on signing or CAs will kill it (or has already killed it). | So what does it mean? | | In OpenPGP, there is no defined meaning to | signing in the code or spec, so it means | ... whatever the signer wanted it to mean. | It takes two to form a relationship. So it's the receiver as well as the sender. Let the receiver beware! A relationship may say something about a signature's meaning, but there is nothing in the tech or the dox that might back that up. That's why an OpenPGP signature is worth whatever the relationship says its worth. Perfect! | Which is *safe*. Sign away, it's whatever | you want it to mean. | If a person wants to be Batman and another Robin, as long as they are comfortable with these personas then this model works for them. Right, and if I sign as Iang, and I also go around saying my sig is my word is my bond, and let's do deals, then I've created an expectation that my signature has meaning. Again it takes two parties to agree to a contract. I'll never digitally sign anything that I wouldn't not hand-sign. But if you can recognize my physical handwriting then why not its digital counterpart? I can repudiate or not-repudate both my physical and digital signatures as needed. I fail to follow your logic here for non-signing. How do you know you can repudiate your S/MIME sig? The RFC says it is non-repudiable, and some laws say the same thing. The logic is quite simple. Unless we can define with reasonable certainty what the signature means, then don't do it. It might be used against you in the future. OpenPGP's sig is quite well defined as undefined. So it's up to you. S/MIME's sig however is not undefined, but has meaning. I just don't know what it is, so if I were to use it, I would be signing without knowing what I was doing. (And the same applies to everyone who doesn't know what it is. Which is most all of us.) | 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). | No, it's not dependent. Just heavily used by most MUAs. Sure. In terms of deployment, heavily used and relied up on for key exchange is close enough to what I mean. | Most usually this is done via sending a signed-message beforehand. You | may opt to have him ftp/telnet/ssh/carrier-pigeon the key, but | nonetheless you gotta have 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're welcome to pluck mine off my various web pages.
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
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. I see 2 primary benefits of including a CA in the chain, firstly email is spoofable, and unless you plan to use a white list to annoy the crap out of everyone before you'll accept mail then the CA in most cases includes a minimum level before issuing, at least I don't know of any testing certs issued without a mail probe. 2nd benefit is in the revokation, how many PGP keys are floating round in cyber space that can't be revoked? -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers In the long run the pessimist may be proved right, but the optimist has a better time on the trip. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
Ian G wrote: Ah, ok, I recall this being mentioned a squillion times. Now it happens to me :-/ So yea, now you know why it's important for mozilla guys to come up with a database that can be shared between both apps... OK, so I manually installed the root from CACert into TBird. And ... yoohoo, this mail should go out signed :-) yup... -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers In the long run the pessimist may be proved right, but the optimist has a better time on the trip. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Ian G wrote: | |snip I recently installed a good cert into my Thunderbird and I | still cannot send out signed or encrypted email using S/MIME (I forget | why). | Are you being facetious here? Wren -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFCRKT5A/qR4Uok1vQRA1XDAKDOPNE6hu++VCSJIVE5ai5YmRZQHQCgyZe2 7/tV5Ne8o4myoq0RDbs69kM= =FyUN -END PGP SIGNATURE- ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
J. Wren Hunt wrote: Ian G wrote: | |snip I recently installed a good cert into my Thunderbird and I | still cannot send out signed or encrypted email using S/MIME (I forget | why). | Are you being facetious here? Nope, I tried to get it going a couple of weeks ago, and the interface has too many barriers in it. Here's some quick gumbie notes dashed off, as I try again. 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). Now that I've selected the cert, it gives me two options on the Account Settings dialog: Never use encryption, and Required. Well, neither of those are going to work and when I saw that the first time I was mystified why such a choice existed. What's wrong with encrypt when possible; encrypt to whom possible? So it now occurs to me that this cannot be all there is to it, and clicking on this email's Security padlock reveals ... recipient certs, which is a big suprise! Nice. But, in Options/Security I found a menu that gave options to encrypt and to sign. They need to be on the chrome somewhere, imho. So I guess the thing is to set the default in Edit / Account Settings / [EMAIL PROTECTED] / Security / Encryption to say Never and then to override that by clicking the Options/Security/ Encrypt each time? In summary, 1. it should create and select a cert on install. 2. it should select or offer selection when a new signed cert on install. 3. it should encrypt when it can, and offer an option to encrypt partially when it can't encrypt to all. 4. there should be a big fat SENDSIGN button next to Send. 5. there should be a valid indicator next to each of the recipients, as well as an no cert for those who aren't known. All, IMHO, second attempt impressions. 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. 6. It would be nice if the From bar where to go blue like Firefox. The little pen (is it?) at the bottom right is too small to notice. 7. Is there any way to attach a statement to the signature indicating what it means? What does it mean? 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
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
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). But it's true the interface definitely doesn't make it obvious how to turn on signing and encryption . But, in Options/Security I found a menu that gave options to encrypt and to sign. They need to be on the chrome somewhere, imho. 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. So I guess the thing is to set the default in Edit / Account Settings / [EMAIL PROTECTED] / Security / Encryption to say Never and then to override that by clicking the Options/Security/ Encrypt each time? Yep. In summary, 1. it should create and select a cert on install. That would require a relationship with a CA and automated protocol. 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. 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. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
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 ;-) 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. But it's true the interface definitely doesn't make it obvious how to turn on signing and encryption . But, in Options/Security I found a menu that gave options to encrypt and to sign. They need to be on the chrome somewhere, imho. 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. A that's what that funny little thing on the button is. OK, that's better. So I guess the thing is to set the default in Edit / Account Settings / [EMAIL PROTECTED] / Security / Encryption to say Never and then to override that by clicking the Options/Security/ Encrypt each time? Yep. In summary, 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. There is no basis to _require_ a CA to handle email, that's something that should be optional and for companies, mostly. 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? 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
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
Ian G 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 ;-) Well, I just tried it from the proper email address, and it didn't work. This time I read the popup carefully, and it said check if the cert is valid and *TRUSTED* ... So, I have a CACert certificate. And I suppose what I am being told is that this is not trusted ... and therefore I am not permitted to sign? (And because I can't sign I can't encrypt :-) That would be a bug, if true. Even if one were not aghast at the temerity of restricting signatures to people with paid permission ... I would have thought it blindingly obvious that the *verification* is where the quality of the signature chain should be checked. (It doesn't say anywhere that the cert is not trusted by Thunderbird so it may be that there is another problem elsewhere. Are CACerts and Thunderbird compatible ? Hey Duane, any daylight down there?) Anyway, thanks for your help guys. Question - should all this be bug filed, or is it all covered in some standard somewhere, so no point? I'm really an OpenPGP guy, so it's no big issue to me personally, but if there is any intention to get this stuff deployed for average users then I can have a go at filing a bug. 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
Re: Thunderbird S/MIME guys - Digitally-Signed Mail in e-Commerce - FC05 survey
Ian G wrote: That would be a bug, if true. Even if one were not aghast at the temerity of restricting signatures to people with paid permission ... I would have thought it blindingly obvious that the *verification* is where the quality of the signature chain should be checked. The entire certificate chain is actually sent, so I'm most interested in what solution mozilla guys can come up with to link the trust db from firefox to thunderbird so people don't have to keep exporting/importing, bit like exporting from MS IE to MS Outlook, most annoying really... (It doesn't say anywhere that the cert is not trusted by Thunderbird so it may be that there is another problem elsewhere. Are CACerts and Thunderbird compatible ? Hey Duane, any daylight down there?) Actually I'm in the US atm... and technically it's 2pm in Australia :) -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers In the long run the pessimist may be proved right, but the optimist has a better time on the trip. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
