Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Duane wrote: Ian G wrote: Ah, to clarify, I was sort of assuming they wanted the cert for their website. If they wanted the cert for email/code signing, then that won't be so easy. Actually someone else pointed out an issue with the idea of screen scraping a website to prove domain control... There are usually much more people with content change rights on the homepage than have administrative privileges on the server. The ability for adding content to the page (that might be closely monitored by others) is in no way equivalent to the ability to get an SSL cert for it (that might get used on a fake host). It would be a really nice privilege escalation. Right. That's an insider attack, or as pointed out, a privilege escalation. But the same applies to domains, and indeed, any check that can be done can be subverted by an insider attack. The strategy is to find multiple checks that are cheap but have little correlation with each other. It doesn't matter so much if there is an easy attack on the one, as long as it is a nuisance to combine it with another. Also, bear in mind, the more the combined attack spreads more people, the more this indicates the site shouldn't be using email-only-authenticated certs. The intention is to secure a low value cert, not to make it invulnerable. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Duane wrote: Firstly we have to talk about where this piece of code has to be: - Many websites run a guestbook that allowes to insert html. - Some providers allow their users to run a private website at www.domain.com/user or www.domain.com/~user. - Some provider give users a subdomain like user.domain.com - Some ISP don't allow you to access domain.com but only www.domain.com Secondly we have to think about who might be allowed to change this index page: - Some WIKIs allow everyone to change their index page - Some pages have a newsticker on their index page that can be updated by normal users (e.g. www.fsi.uni-tuebingen.de) - Websites are often run by a multimedia/design/... department that has nothing to do with administration. ... and... Many websites run php/cgi/whatever scripts that are vulnerable to code-injection, and would allow to put the cacert code wherever the attacker likes to. phpBB comes to mind, and so many other applications. Good stuff. Remember, there are no absolutely secure systems. Do not let the perfect be the enemy of the good. If you want references, I can supply... iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ian G wrote: The intention is to secure a low value cert, not to make it invulnerable. I suggested this and no matter what I replied with you seemed to think it was impossible to do (as did Nelson for other reasons) -- 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-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Nelson B wrote: Now, if we could get a few standardized profiles of CAs, e.g. a standardized high assurance profile, and a standardized low assurance profile, then perhaps a cert could include an extension that says this CA conforms to standardized CA profile number . RFC3280 : 4.2.1.5. Certificate Policies The certificate policies extension contains a sequence of one or more policy information terms, each of which consists of an object identifier (OID) and optional qualifiers. [...] In an end entity certificate, these policy information terms indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used. In a CA certificate, these policy information terms limit the set of policies for certification paths which include this certificate. Just normalize an OID for the high assurance profile and the standardized low assurance profile, and include them in a multi-valued Certificate Policies field. Everything is there for it to work like that. If the certificate doesn't include the extension with the needed values, it is possible to use an external source to add that knowledge(*), it's just more complex to manage. * Just like NSS currently uses external methods to handle the SSL/client/code signing trusted info for CA certificates and doesn't extract them from the certificate content. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Nelson B wrote: I think we're saying the same thing. Lack of universally accepted policies (er, policy OIDs) is hold policy extensions back. Even if NSS implemented policy extensions today, lack of policy definition would make it pretty useless, IMO. Chicken and Egg. But really, it needs to be implemented first, and then it will be possible to do a small scale experiment to find what kind of OID to use and what to represent with those OID. One can use there arbitratry OID, and even map them them later to normalized value via policy mapping, but if not enough is implemented, it's not possible to experiment. A problem is that if it ever begins to develop, it will probably end up somewhat stepping on the extended key usage extension, I don't believe the two uses are fully orthogonal. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Nelson B wrote: It seems to me that this idea of standardized profiles is essentially what ETSI was trying to accomplish with their Qualified Statements, about which most participants in this group have had little good to say. I'm sorry, I must have missed that discussion. What were the nature of the objections to the ETSI work? Was this in reference to the standard certificate policies defined in ETSI TS 101 456 and 102 042? I personally don't have any objection to CAs adopting standardized certificate policies (including standard policy OIDs), in fact I think it would be a good thing. However in practice I think this is unlikely to happen for various reasons, mainly because a) I don't think the vendors, i.e., the CAs and the various bodies like ETSI, ANSI X9, EAP, etc.) are really motivated to cooperate on doing this, and b) I don't think the market (i.e., CA customers and relying parties) really cares about this. (Although one could argue that standardized cert policies would make comparing CA offerings easier, and hence be a boon for cert buyers, I don't think that would make an actual difference in practice because I don't think cert buyers make buying decisions based primarily on CA policies -- it's more can this CA sell me a cert that will cause my customers not to see warning dialogs?) I also think that the ETSI classification of policies is a good attempt. My only point is that you still need a standardized mapping of the policies to particular types of certificate use (e.g., code signing, S/MIME email, and SSL servers in our case). Also, a point of clarification: In the context of TS 101 456 and 102 042 the word qualified when used in connection with certificate policies has a specific meaning IIRC: it refers to cert policies that are legally aligned with EU member state digital signature laws. That's why TS 102 242 defines non-qualified (my term, not theirs) versions of the qualified policies defined in TS 101 456; the level of assurance is the same for the policies that have both qualified and non-qualified variants, but the legal implications are slightly different in terms of how the certs would be treated under EU and national laws and directives. I'm not aware of any other efforts to standardize profiles. Well, there's the EAP work I mentioned previously, but it is broader than just certs, and IIRC does not define standard policy OIDs. Frank -- Frank Hecker [EMAIL PROTECTED] ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Nelson B wrote: with known weaknesses. Namely, they fall apart under not-very-difficult attacks. Right. So take two not-very-difficult attacks or preferably three if you can think of them, and force the attacker to do all three. His risks go up 10 fold each time. This is what you'd call common or garden grade security. But those weaknesses are not entirely correlated. No? Not entirely, no. One's email, the other's a web site. If both of these were requested, then an attacker would have to change over the domain name record of the email addresses, as well as change over the DNS settings. Both MX records (which direct email routing) and A records which return IP addresses for host names are DNS records. It suffices to poison the resolver cache of a single victim's computer to accomplish the attack on both. Right, there are multiple ways of doing that. As the change for the DNS settings would involve directing all (or most) DNS traffic over a period that was hard to determine, this would have a much greater chance of being noticed. Only the issuer's traffic need be directed. That certainly makes it easier for the attacker to pick off both, but bear in mind he still needs to run a proxy or website or some such, so his costs increase even then. And, what I would suggest is that the caring CA be aware of this, and do a check from somewhere else. use SSH and jump over to another box. This can be done via either email or for browsing. Right. But the web content is on a site that is currently in use. And, the more it is in use, the more it is going to be noticed, so this scales nicely with the importance of the check. Noticed by whom? Anyone who's looking at his site. His customers, his users, his girlfriend. The point is that this isn't foolproof, but it raises the risks and costs for the attacker. You still haven't explained how web content is supposed to give the issuer any more assurance about the party to whom an SSL cert is about to be issued. It shows he has control of the web site. So now he has control over the website *and* the DNS records, he should presumably have identified himself better than if he had shown control over one factor. I gather that you propose that the issuer will look at the page that (supposedly) comes from the requestor's server, and take assurance therefrom. If that is your proposal, then only the resolver cache used by the issuer's machine need ever be compromised by the attacker. That's a good point; see above for a bypass to that. The reason the email trick works - I guess - is because that email path is never used. uh, no. It's because whatever email the issuer sends to the intended recipient is intercepted by the attacker. The attacker can click on any links, and use any passwords found in the mail that was intended for the proper recipient, since the email messages were not secured in any way. No, ok, let me spell it out. The reason the attack on the email goes by undetected is because the admin name in the DNS record is not used for any other purpose. So any other emails that would otherwise be stymied are not going to help trigger detection. Just so we're clear; what is being proposed is several small barriers and nuisances that make it tricky for a thief to easily make one hack and get away with it. It's an economic approach, it's how you deal with things when they are low value, and you don't want to spend any money. Which is fine, because we are dealing with the standard of using email to authenticate here, we are not trying to compete with hard paper Id forms. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian G wrote: | | The reason the email trick works - I | guess - is because that email path is | never used. | | | | uh, no. It's because whatever email the issuer sends to the | intended recipient is intercepted by the attacker. The attacker | can click on any links, and use any passwords found in the mail | that was intended for the proper recipient, since the email | messages were not secured in any way. | | | No, ok, let me spell it out. The reason the | attack on the email goes by undetected is | because the admin name in the DNS record | is not used for any other purpose. So any | other emails that would otherwise be stymied | are not going to help trigger detection. | | Just so we're clear; what is being proposed | is several small barriers and nuisances that | make it tricky for a thief to easily make one | hack and get away with it. It's an economic | approach, it's how you deal with things when | they are low value, and you don't want to | spend any money. | | Which is fine, because we are dealing with | the standard of using email to authenticate | here, we are not trying to compete with | hard paper Id forms. | Nelson's parent post which started this thread uses the words insecure email I took his use of the word 'insecure' as deliberate and interpreted it as saying that 'secure' mail would be just fine. We're dealing with certs, why not just encrypt? A legitimate owner would be in possession of the keys whereas MITM style attacks would not. Wren -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iD8DBQFCE50+A/qR4Uok1vQRAqYeAKCW+9q9eep4aZk24/KswAMpWVXJXACgugTT 8ucFBf325Ye8zgy28UUs5zA= =KVdj -END PGP SIGNATURE- ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
J. Wren Hunt wrote: Nelson's parent post which started this thread uses the words insecure email I took his use of the word 'insecure' as deliberate and interpreted it as saying that 'secure' mail would be just fine. We're dealing with certs, why not just encrypt? A legitimate owner would be in possession of the keys whereas MITM style attacks would not. It would be nice if we could use thunderbird to create the keys, create a self-signed cert, and start using it. That wouldn't address the identity problem, but we don't have an identity problem when we are emailing, only an encryption problem (and 99.9% of users are happy to take a risk for 99.9% of email anyway). Most of us send email to people we already know, unlike with web browsing to remote ecommerce sites. But, as anyone can create keys, an email that is uncertified wouldn't really add anything to determining if you have the right to a domain, would it? iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
J. Wren Hunt wrote: If the email in question is being used by the CA to verify ownership of the domain then yes, encryption would foil the attacker's ability to perform any related change predicated of course on an existing relationship between CA and its client. Or more simply, if you divert my unencrypted mail you may act on the information you receive and I will be none the wiser (at least in the short term). Divert my encrypted mail and neither of us can act; you can't because you can't decrypt and I because I wouldn't be aware of the now missing missive anyway. Yes, but that's not the attack. The original problem here - I think, correct please if wrong - was that I being the bad guy decide to get a cert for your domain. I do the natty DNS poisoning trick that Nelson spoke of. I create a key and I send it to the CA. Then the CA sends back an encrypted email to that key, I decrypt it, and follow the instructions... You the original domain owner never get involved... iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ian G wrote: I do the natty DNS poisoning trick that Nelson spoke of. I create a key and I send it to the CA. Then the CA sends back an encrypted email to that key, I decrypt it, and follow the instructions... If I'm not mistaken this is the original snake oil that was pushed, and the only long term problem, is with email addresses/code signing as you pointed out Ian because it's the path less trodden. People usually notice websites acting strangely (shortly there after complain about it) and not being what it appears to be, and while the dns may be poisoned for a small section of the internet this won't be the sum total of it and there is numerous simple ways of over coming it. Namely probing name servers in far flung locations, it might be easy to poison one caching name server or one persons PC, try doing it to 50 or 100 though. High profile sites pay lots of money for this exact service to ensure that major providers aren't involved (directly or indirectly via automated processes) in the distribution of poisoned DNS information, low profile sites being a small target usually have their DNS hi-jacked at the registrar level more often then not, which in this case they have bigger issues then someone getting false certs issued. The only issue with Ian's suggestion about probing a website/screen scraping then is for the domains people only use for email or what not and don't run websites, or run internal sites that are password protected from the outside world... Personally I have a number of domains I bought purely for email reasons, and while it's not impossible to get a temporary site up, will everyone else be in the same boat? What about the cheap email hosting deals but they don't come with a website? -- 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-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Duane wrote: The only issue with Ian's suggestion about probing a website/screen scraping then is for the domains people only use for email or what not and don't run websites, or run internal sites that are password protected from the outside world... Ah, to clarify, I was sort of assuming they wanted the cert for their website. If they wanted the cert for email/code signing, then that won't be so easy. I'm not sure how to cover that. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ian G wrote: Duane wrote: The only issue with Ian's suggestion about probing a website/screen scraping then is for the domains people only use for email or what not and don't run websites, or run internal sites that are password protected from the outside world... Ah, to clarify, I was sort of assuming they wanted the cert for their website. If they wanted the cert for email/code signing, then that won't be so easy. There was another point in there that I maybe didn't make clear either. My primary constant use I use certificates for, is to protect my smtp and imap sessions even though I don't use it for websites on the same domain... -- 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-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ian G wrote: Ah, to clarify, I was sort of assuming they wanted the cert for their website. If they wanted the cert for email/code signing, then that won't be so easy. Actually someone else pointed out an issue with the idea of screen scraping a website to prove domain control... There are usually much more people with content change rights on the homepage than have administrative privileges on the server. The ability for adding content to the page (that might be closely monitored by others) is in no way equivalent to the ability to get an SSL cert for it (that might get used on a fake host). It would be a really nice privilege escalation. -- 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-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ian G wrote: If HTTPS is the use for the cert, then as I suggested in some other random long rant today (!) we could always ask the domain owner to stick something in the HTTP page. Sort of like a little icon ad that people commonly do, you can see a couple of them in the below link. I think that makes a case that whoever stuck those in there has at least some control over the domain, for HTTP purposes. Sorry for being thick here, but I don't understand what you're suggesting. How does the content of an insecure web page offer any proof of ownership that is stronger than email? One falsified DNS record, or one bad line in your hosts file, is all it takes to spoof any/all insecure web content from any one site. Sorry if I'm missing something obvious. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Duane wrote: Nelson B wrote: I think the X.509 folks never dreamed that there would exist low-assurance CAs. They assumed all CAs would be high assurance. That's just naive... What other types of security, physical or other wise uses a 1 size fits all policy? The correct X.509 mechanism to handle different level of assurance for CA is by using certificate policies. But this would require that implementations correctly support multiple certificate policies, equivalence between policies, a normalized set of policies to represent usual kind of assurance, and the validation of a certification path against a policy. In fact, the hardest point is to find out how this can be handled in terms of user interface. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Jean-Marc Desperrier wrote: In fact, the hardest point is to find out how this can be handled in terms of user interface. I consider a lot of other things the UI has over come as being more difficult, either people don't understand the implications of binary security or they don't care, or a combination of both... PS see my other reply as to you other points (my apologies for referring to you as Julian, I should check next time :) -- 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-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Nelson Bolyard wrote: Ian G wrote: If HTTPS is the use for the cert, then as I suggested in some other random long rant today (!) we could always ask the domain owner to stick something in the HTTP page. Sort of like a little icon ad that people commonly do, you can see a couple of them in the below link. I think that makes a case that whoever stuck those in there has at least some control over the domain, for HTTP purposes. Sorry for being thick here, but I don't understand what you're suggesting. How does the content of an insecure web page offer any proof of ownership that is stronger than email? Both are insecure only in absolute sense. In reality, both are reasonably secure, with known weaknesses. But those weaknesses are not entirely correlated. If both of these were requested, then an attacker would have to change over the domain name record of the email addresses, as well as change over the DNS settings. As the change for the DNS settings would involve directing all (or most) DNS traffic over a period that was hard to determine, this would have a much greater chance of being noticed. One falsified DNS record, or one bad line in your hosts file, is all it takes to spoof any/all insecure web content from any one site. Right. But the web content is on a site that is currently in use. And, the more it is in use, the more it is going to be noticed, so this scales nicely with the importance of the check. The reason the email trick works - I guess - is because that email path is never used. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Duane wrote: Jean-Marc Desperrier wrote: In fact, the hardest point is to find out how this can be handled in terms of user interface. I consider a lot of other things the UI has over come as being more difficult, either people don't understand the implications of binary security or they don't care, or a combination of both... It's not quite that... It's based on the fact that the secure browsing system has been in place for a decade now and during that entire time, people have grown used to the fact that it is there and it works and it should be forgotten as much as possible. When it was put together, there was an enourmous wave of commercial enthusiasm for something that was loosely based on a threat that never actually happened. If you want to get into that I'd suggest reading some of Lynn Wheeler's entertaining stories about the good old days. (Well, I find them entertaining ...) Now, to all intents and purposes, this threat was whalloped. Completely destroyed, and this built up the notion that the system is perfect, complete and invulnerable. Now, there is so much 'belief' that the system is like that, that even with today's top flight security consultants, they have a very hard time dealing with challenges to it. It is simply outside their world view to think of secure browsing as subject to any threat. Meanwhile along comes phishing in 2003 or so and just waltzed past SSL as if it wasn't there. Shmoo showed what this was about. It drew a straight line from dodgy domain to dodgy cert to phish. It did it so clearly that it exposed the secure browsing system for what it is: a system that has never been battle tested, and is full of contradictory assumptions that leave open easy ways to attack. People are going to take some time to get to grips with that. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Nelson B wrote: AFAIK, there's no uniform standard for classes. Correct AFAIK, although there are some sort-of conventions (e.g., class 1 = minimal validation, e.g., via email, class 4 = use of hardware tokens). Although of course this sort-of standardization is exactly what has plagued PKI from the very beginning (e.g., the proliferation of similar but not identical certificate profiles). It might help a lot if there were. WebTrust doesn't require classes. They test only that a CA does what their CPS says, whatever that is. The ETSI standards (TS 101 456 and 102 042) do define a reasonably straightforward set of classes, although they don't the use the word classes per se. (They refer to certificate policies.) Also, the Electronic Authentication Partnership does define a set of standard classes in their trust framework working draft: http://www.eapartnership.org/docs/Trust_Framework_0105.pdf However... beyond the lack of standardization, what I find problematic about all these documents is that they focus on levels of assurance in isolation, independent of the contexts to which the assurance is actually relevant. It's just rehashing the old PKI practice of focusing on authentication of entity identity as the only issue, and not looking at the actual real-world applications. Frank -- Frank Hecker [EMAIL PROTECTED] ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ian G wrote: Both are insecure only in absolute sense. In reality, both are reasonably secure, There is typically a low probability of attack against either of them if they are low value targets. with known weaknesses. Namely, they fall apart under not-very-difficult attacks. But those weaknesses are not entirely correlated. No? If both of these were requested, then an attacker would have to change over the domain name record of the email addresses, as well as change over the DNS settings. Both MX records (which direct email routing) and A records which return IP addresses for host names are DNS records. It suffices to poison the resolver cache of a single victim's computer to accomplish the attack on both. As the change for the DNS settings would involve directing all (or most) DNS traffic over a period that was hard to determine, this would have a much greater chance of being noticed. Only the issuer's traffic need be directed. One falsified DNS record, or one bad line in your hosts file, is all it takes to spoof any/all insecure web content from any one site. Right. But the web content is on a site that is currently in use. And, the more it is in use, the more it is going to be noticed, so this scales nicely with the importance of the check. Noticed by whom? You still haven't explained how web content is supposed to give the issuer any more assurance about the party to whom an SSL cert is about to be issued. I gather that you propose that the issuer will look at the page that (supposedly) comes from the requestor's server, and take assurance therefrom. If that is your proposal, then only the resolver cache used by the issuer's machine need ever be compromised by the attacker. The reason the email trick works - I guess - is because that email path is never used. uh, no. It's because whatever email the issuer sends to the intended recipient is intercepted by the attacker. The attacker can click on any links, and use any passwords found in the mail that was intended for the proper recipient, since the email messages were not secured in any way. -- Nelson B ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ram0502 wrote: I'd like to see an indication of what information the CA is prepared to defend and to what extend they are making that assurance on identity (e.g. we assure you this is IBM, NY, US and provide warranty as follows) as well as some indication for signed software as to any policy they may have arround appropriate use such as requireing up front disclosure about what the software does. If I'm not mistaken, it takes the entire CPS to state all that info. The indication of what information is the URL of the CA's CPS, IINM. Some CPSes are hundreds of pages long. Now, if we could get a few standardized profiles of CAs, e.g. a standardized high assurance profile, and a standardized low assurance profile, then perhaps a cert could include an extension that says this CA conforms to standardized CA profile number . It seems to me that this idea of standardized profiles is essentially what ETSI was trying to accomplish with their Qualified Statements, about which most participants in this group have had little good to say. I'm not aware of any other efforts to standardize profiles. -- Nelson B ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ram0502 wrote: I wish there were some way, but I don't know of any standard way to represent the amount/strength of authenticity checking done by CAs prior to issuance. There would have to be a new extension, or alternatively it could be new info stored along with the cert in NSS's cert store. I like that idea - I've started a thread that leverages it. What thread is that? What is the subject of that thread? -- Nelson B ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Gervase Markham wrote: Nelson B wrote: mozilla treats SSL server certs like code signing certs for java script served over https, IINM, I don't think this is correct. JS served over HTTPS has exactly the same abilities and restrictions as JS served over HTTP. OK, I'm glad to hear that! Thanks for setting that issue straight. -- Nelson B ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Nelson B wrote: [...]. mozilla treats SSL server certs like code signing certs for java script served over https, IINM, [...] I really don't believe so. Well, it shouldn't be very difficult to test. If it works, I'll be amazed at how convenient it is, but it's just too convenient, they are many SSL Site on which I go that I don't trust to access all what signed js can access. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Jean-Marc Desperrier wrote: Nelson B wrote: [...]. mozilla treats SSL server certs like code signing certs for java script served over https, IINM, [...] I really don't believe so. Well, it shouldn't be very difficult to test. If it works, I'll be amazed at how convenient it is, but it's just too convenient, they are many SSL Site on which I go that I don't trust to access all what signed js can access. That is a policy of the application, not of NSS, BTW. I objected to it for the reason that the subjects of SSL certs are typically subjected to less authenticity checking than code signing certs, and this policy allowed the lesser assurance certs to be used as code signing certs. But the application folks seemed to want added convenience more than the added security, IMO. -- Nelson B ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Nelson B wrote: mozilla treats SSL server certs like code signing certs for java script served over https, IINM, I don't think this is correct. JS served over HTTPS has exactly the same abilities and restrictions as JS served over HTTP. Gerv ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Duane wrote: Nelson B wrote: Choosing to be a low-assurance CA is a legit choice, IMO, as long as the low assurance CA doesn't then issue certs used in applications that require high assurance. Is there something that can be done to add extra bits to the server certs, I wish there were some way, but I don't know of any standard way to represent the amount/strength of authenticity checking done by CAs prior to issuance. There would have to be a new extension, or alternatively it could be new info stored along with the cert in NSS's cert store. I think the X.509 folks never dreamed that there would exist low-assurance CAs. They assumed all CAs would be high assurance. They were thinking of an X.500 world model, in which directories and CAs in each country would be governmentally regulated, and hence held to high standards by their governments (as seems to be the case in the EU, whence the X.500 folks came). when I see Class 3 server certificates in the browser it's purely informational, AFAIK, there's no uniform standard for classes. It might help a lot if there were. WebTrust doesn't require classes. They test only that a CA does what their CPS says, whatever that is. why not mark those certificates high trust with bits in the nss libs and then have the chrome show this information, I think my predecessors (original designers of NSS) thought that all SSL and code-signing CAs would be high assurance, and therefore thought that the 3 trust bits (email, SSL, code signing) were enough to distinguish (root CA) certs as to level of assurance. -- Nelson B ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Duane wrote: Ram0502 wrote: I agree, I would like to see an indication of the representation being made. Even something simple like a red open lock for no encryption or class 0 (ie test cert with no verification), amber coloured lock for entry level encryption, yellow for medium grade and green for high trust and a tank for class 4/military grade certificates if people want to get carried away with it... :) I'd like to see an indication of what information the CA is prepared to defend and to what extend they are making that assurance on identity (e.g. we assure you this is IBM, NY, US and provide warranty as follows) as well as some indication for signed software as to any policy they may have arround appropriate use such as requireing up front disclosure about what the software does. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
RE: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ram0502 wrote: I'd like to see an indication of what information the CA is prepared to defend and to what extend they are making that assurance on identity (e.g. we assure you this is IBM, NY, US and provide warranty as follows) as well as some indication for signed software as to any policy they may have arround appropriate use such as requireing up front disclosure about what the software does. Of the CAs whose CP and CPS I've read, they all severely limit their liability and provide little-to-no warranty at all. There may be some CAs out there that do strongly warrant their identity proofing (note the use of the word strongly), but they have no incentive to do so. Digital Signature Trust Co. used to warrant it's SSL server certificates and also warranted its TrustID client certificates for a significant amount of money, but from what I've heard they no longer do so. My guess as to why would be because they couldn't sell enough certificates (at whatever price the market would bear) to pay for the insurance premiums that are necessitated by such a warranty. It seems like people won't pay for warrantees unless the pain of not having one becomes worth the cost a warranty incurs on the system. I have yet to see *any* CA require disclosure by a customer applying for a code signing cert about what the software does. If there was such a CA then it wouldn't make sense for the CA to issue them a cert that could be used over and over again to sign thousands of applications. It would make more sense for the CA to simply sign the *one* application they required disclosure for and never give a customer a private key/cert capable of signing code that wasn't part of the CA's code review process. -alex ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Alex Wight wrote: I have yet to see *any* CA require disclosure by a customer applying for a code signing cert about what the software does. If there was such a CA then it wouldn't make sense for the CA to issue them a cert that could be used over and over again to sign thousands of applications. It would make more sense for the CA to simply sign the *one* application they required disclosure for and never give a customer a private key/cert capable of signing code that wasn't part of the CA's code review process. VeriSign (and Thawte) have exactly that policy. It would certainly be rough for a software publisher with lots of legitimate signed content if they got theirt certificate revoked for a violation - but then they are not as likely to do it. Having said that I still totally agree with you - I think that is why some mobile phone platforms use an approach where they can revoke individual signed packages in addition to or instead of revoking the identity cert they were published by, I can dig up a link if you want. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Nelson B wrote: Duane wrote: Nelson B wrote: Choosing to be a low-assurance CA is a legit choice, IMO, as long as the low assurance CA doesn't then issue certs used in applications that require high assurance. Is there something that can be done to add extra bits to the server certs, I wish there were some way, but I don't know of any standard way to represent the amount/strength of authenticity checking done by CAs prior to issuance. There would have to be a new extension, or alternatively it could be new info stored along with the cert in NSS's cert store. I like that idea - I've started a thread that leverages it. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Nelson B wrote: I wish there were some way, but I don't know of any standard way to represent the amount/strength of authenticity checking done by CAs prior to issuance. There would have to be a new extension, or alternatively it could be new info stored along with the cert in NSS's cert store. That's what I was hinting at... How hard would it be to do this without breaking backward compatibility, yet in future the UI knowing about this extension would be able to give the user more information? I think the X.509 folks never dreamed that there would exist low-assurance CAs. They assumed all CAs would be high assurance. That's just naive... What other types of security, physical or other wise uses a 1 size fits all policy? AFAIK, there's no uniform standard for classes. It might help a lot if there were. WebTrust doesn't require classes. They test only that a CA does what their CPS says, whatever that is. Maybe this is something that needs to be part of what one of the other guys were suggesting as part of their to CAs that wish to be included, or remain in the browsers... I think my predecessors (original designers of NSS) thought that all SSL and code-signing CAs would be high assurance, and therefore thought that the 3 trust bits (email, SSL, code signing) were enough to distinguish (root CA) certs as to level of assurance. Can we honestly say that is still the case, if not can it be addressed some how in a sane manner to give the user more information on what they're about to do, I guess this is similar to the debate over monetary values etc... This situation reminds me of the situation with road works in Sydney, they tend to plan for the current needs instead of what will be needed in 5 or 10 years time, so it's a constant game of catch up rather then better planning to make everyone's lives a little easier. -- 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-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
C. D. Rok wrote: b) A certificate has a unique identifier (a name) and all that the certificate ensures is that the combination of certificate issuer identification and the name associated with the certificate is unique. Paradigm (b) is what we must accept and learn to work with. Names by themselves aren't in most cases unique, unless you're refering to some abstract suggestion of making them unique some how, such as a combination of name + email address, or name + email + govt ID #... -- 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-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Nelson B wrote: In a recent post, someone here attempted to defend the practice of using insecure email as the sole means of confirming the legitimacy of a request for an SSL server certificate. I'm here to challenge that. I think it's SO BAD a practice, in fact, that I think mozilla should specifically say, in the policy, that that's not good enough for a CA that is admitted to mozilla's trusted root list. I am not targetting any particular CA here. I think this is a matter of policy for all CAs. I think the cert-by-email practice could work with suitable safeguards. It all depends on what we're certifying. Are we saying that you are connected to example.com, or that you're connected to a server owned by the human being who bought example.com? The first prevents man-in-the-middle attacks, and the second prevents phishing over SSL (or at least makes it easy to find out who the guilty party is). The first probably can be done via email. The second would probably require an in-person visit with government-issued ID (possibly more than one form). Anything less than visual inspection of ID by a trusted party would make the system unsuitable for prosecuting somebody based on abuse of SSL identity - which is what you need to stop phishing. I'm not under the impression that the mainstream vendors do in-person ID checks. So, we don't have that level of protection currently. I think that domain control can be reliably verified using email. I agree that domains can be hijacked - but there are solutions to this: 1. You sign up via a website. The website sends you an email containing a verification link. All communications are signed, and include a copy of the certificate request. 2. They repeat this at a few intervals over a week or two. At random times. In order to hijack your domain, an attacker would have to be able to intercept your email over a several days. By including the request in the email you might be able to prevent more subtle MITM attacks (I'm not 100% sure this is even necessary - I have a few scenarios in mind but they're probably not possible in practice). While somebody might be able to hijack your domain for an hour to get a cert, I doubt they could maintain this for weeks at a time and avoid detection. I'm all for having controls on the use of email - but I'm not sure that the solution is to ditch it entirely. I guess it really depends on what you want SSL certs to prove. I'd argue that right now they don't meet the standard some people are proposing - so why worry about lowering the standard? The only way we're going to have really strong SSL certs would be if governments issued them and they were kept exclusively on smartcards so that the average member of the public wouldn't let them get out of control. That isn't going to happen soon (although one day it might - it would be a big hurdle against identity theft). You could have your webserver generate a CSR and then sign it yourself using your government-issued ID (that way you don't have to leave your ID card in your computer all the time). You could revoke your webserver at any time, and the government could revoke your ID at any time. Oh well, we can dream at least, can't we? ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Richard Freeman wrote: While somebody might be able to hijack your domain for an hour to get a cert, I doubt they could maintain this for weeks at a time and avoid detection. Actually this is another issue, if they can hijack your email for an hour they can hijack your domain for life as most registrars send passwords, changes to your domain name in plain text emails... -- 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-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Duane wrote: I'm kinda surprised you haven't made more noise about this when you made mention previously about some CAs offering snooping services to govt's and being a conflict of interest. :-) Well, it is because we are making some forward progress. The fact that the system has some gaping holes in it needs to be balanced alongside the fact that it *is* the system, and AFAICS, it is the only hope for dealing with phishing. What's taken me a long time to discover is that there are more people who actually do agree with the flaws than I can see. So, in a sense, let's forget the job of needing to hammer on the flaws, and start thinking of the fixes ... in such a way that they improve the product. I would be surprised if phishers couldn't walk through the major CA's practices right now like chocolate through a goose... There's a huge So on one hand you are suggesting we foist problems onto CAs and on the other you show how that won't stop problems. So how is it forcing problems onto CAs is going to fix anything? :) If I had a wife she would agree with you :) Here's the thing. If you've been following the phishing adventure for the last 2 years, as I have, after a while you get to understand the measure of it. And where it's heading We do have the dilemma that phishing is heading in a certain direction: to more acute and direct attacks on the browser's crypto system. Right now it bypasses it totally, so we don't notice. The Shmoo bug has shown all that in context. It's drawn a nice line from phishing to HTML to HTTPS to the user. So, if you accept that phishing is going to be forced in the direction of attacking the CAs to fraudulently acquire certs, what to do about it? Well, we have to start protecting the CA's space and patch. To do that, we have to create the branded space that the CA can protect; in order to give the CA what he needs to protect himself, we must let him define himself to the users. Ergo, as Bob pointed out, the original security model. Once the CA has a space to defend, he can figure out how to defend it. It might mean he has to change his business model, or to change his CPS/CP stuff. Or whatever. But at least he can do it. At the moment, a CA cannot defend himself because he isn't defined. There is no clear definition of what a CA does ... c.f., the domain v. identity discussion, cross-borders differences, and conflicts of interest. But once the branding is in place, the CA and the market and the users will create that definition. Which can then be defended. If none of that makes sense, think think of how innoculation works. My current view is that we have a period during which we can innoculate the CA system. Do not fight too hard against a few minor but honest problems ... because the result will strengthen the body for the future real battle. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Nelson B wrote: Just over a year ago, someone published an article in a quarterly journal exposing just how easy it is to hijack the email for a domain. Read a draft of it at http://files.juraj.bednar.sk/CA An interesting read. He brings up an awful lot of problems. Using a combination of techniques is probably as good as it gets. But even then, this is not going to stop a fraudulent issue. What's worse, it may discriminate in ways that we would rather avoid, given MF's mission to deliver to the world. Digression: I lived for 4 years in a country without streetnames. There were no addresses, because there was no postal delivery. If you wanted to get mail you had to go order a post office box or share one. The electricity bill was not in my name, and in fact I couldn't get a single piece of paper that proved I lived in my house. Nor did the company. So much so that when we as a business moved half a dozen countries down the road (well, island chain) some of our team asked for the privilege of paying the new electricity bill so they could get some proof of existence. This documents situation exists in a large proportion of the world. Wherever we are, we should consider the fact that elsewhere, it's just 'different.' How are you going to sell an SSL cert to someone who can't prove who they are? Or, are we saying SSL is only available for those who follow our western notions of identity proof? (This problem becomes really dramatic when trying to open bank accounts or digital money accounts.) It has been demonstrated that an attack on an email domain is orders of magnitude easier than attacks on SSL. So, if an attacker wanted to attack a high value target, he would surely attack the email channels before attempting to attack the crypto. That's Adi Shamir's 3rd law of security: Cryptography is typically bypassed, not penetrated http://www.financialcryptography.com/mt/archives/000147.html And if browser users (relying parties) cannot tell the difference between certs from CAs that base their authentication on no more than insecure email, woe be to them! Hallelujah to that! iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ian G wrote: This documents situation exists in a large proportion of the world. Wherever we are, we should consider the fact that elsewhere, it's just 'different.' How are you going to sell an SSL cert to someone who can't prove who they are? Or, are we saying SSL is only available for those who follow our western notions of identity proof? I'm starting to get the feeling that some people are implying this, and things have gone back to being a flat earth that the sun resolves around... We both keep stating (as far as I can remember, which is about 3 seconds ago) that there is no 1 size fits all, and binary security sucks and has no hope of representing this... I don't think sticking a logo on the chrome will fix this issue either... Nelson pointed out how bad email verification is, but what if that's all you can prove? -- 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-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Duane wrote: Nelson pointed out how bad email verification is, but what if that's all you can prove? If email is the only use for the cert, one could make a case that is good enough. If HTTPS is the use for the cert, then as I suggested in some other random long rant today (!) we could always ask the domain owner to stick something in the HTTP page. Sort of like a little icon ad that people commonly do, you can see a couple of them in the below link. I think that makes a case that whoever stuck those in there has at least some control over the domain, for HTTP purposes. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
C. D. Rok wrote: Nelson B wrote: In a recent post, someone here attempted to defend the practice of using insecure email as the sole means of confirming the legitimacy of a request for an SSL server certificate. I'm here to challenge that. I think it's SO BAD a practice, in fact, that I think mozilla should specifically say, in the policy, that that's not good enough for a CA that is admitted to mozilla's trusted root list. I am not targetting any particular CA here. I think this is a matter of policy for all CAs. There are two paradigms: a) An identity exists as a meta-category, and someone or something has to ensure that the certificate is issued with a name that without any possibility of doubt or error maps to that meta-identity. b) A certificate has a unique identifier (a name) and all that the certificate ensures is that the combination of certificate issuer identification and the name associated with the certificate is unique. Paradigm (a) is naive and will never work in practice. Paradigm (b) is what we must accept and learn to work with. CD Rok I don't think that the two you list are the only two options. To me they read as the two sides of the binary assertions we can depend on perfection from this part of the system. If I used the two suggested models as my only options in the pedestrian world I would never use a credit card in a store as I could not be assured a means of insurance or protection from fraud; instead the credit card system relies on the interaction of sub-perfect. When you soften (a) to require a high probability of accuracy rather than perfection you end up with a component you can build on. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ian G wrote: Duane wrote: Nelson pointed out how bad email verification is, but what if that's all you can prove? If email is the only use for the cert, one could make a case that is good enough. I agree if your only concern is the email address of the sender or recipient (e.g. maintain an ongoing discussion albeit anonymously) or the establishment of a re-usable 'trust session' with someone you will authenticate through other out of scope mechanisms. If HTTPS is the use for the cert, then as I suggested in some other random long rant today (!) we could always ask the domain owner to stick something in the HTTP page. That's an interesting suggestion, it provides the same kind of authentication for HTTPS as the above does for secure email. If the session is initiated by the CA this proves the ability to control the host at the specified location. I wouldn't give them my CC# but it does create a relationship. I wouldn't provide any sensitive information to them as they could be hard to track down if were facing fraud as presumably I wouldn't know their identity. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ram0502 wrote: There are two paradigms: a) An identity exists as a meta-category, and someone or something ... I don't think that the two you list are the only two options. To me they read as the two sides of the binary assertions we can depend on perfection from this part of the system. ... When you soften (a) to require a high probability of accuracy rather than perfection you end up with a component you can build on. High probability is good enough for manual transactions - such as the credit cards in a store... But when a small level of uncertainty opens a possibility for *huge* exploits, the confidence level better as high as possible. Presenting the site's key fingerprint to the user as a matter of course seems more and more like something that can not be avoided. CDR ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ram0502 wrote: That's an interesting suggestion, it provides the same kind of authentication for HTTPS as the above does for secure email. If the session is initiated by the CA this proves the ability to control the host at the specified location. I wouldn't give them my CC# but it does create a relationship. I wouldn't provide any sensitive information to them as they could be hard to track down if were facing fraud as presumably I wouldn't know their identity. But what if the certificate is only used to protect passwords for webmail and doesn't need the ability to be found for fraud? Binary security can't deal with both situations simutaniously and adequately, it needs to indicate visually the level of security... -- 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-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
C. D. Rok wrote: Ram0502 wrote: There are two paradigms: a) An identity exists as a meta-category, and someone or something ... I don't think that the two you list are the only two options. To me they read as the two sides of the binary assertions we can depend on perfection from this part of the system. ... When you soften (a) to require a high probability of accuracy rather than perfection you end up with a component you can build on. High probability is good enough for manual transactions - such as the credit cards in a store... But when a small level of uncertainty opens a possibility for *huge* exploits, the confidence level better as high as possible. That's exactly it, the greater the potential exposure the greater the need for security. If I'm reading some random blog musing my needs are different than when I am managing my bank account, for the former I don't necessarily have any real worries whereas for the latter I do. If I am enabled to choose between building trust with what may be my bank's website from scratch or start already knowing the identity of the authorized site operator I wouldn't need pause to consider which I prefer. Would anyone? So given a CA who associates their livelyhood with their effectiveness as an identity authenticator I would definitely feel better about trusting them. Knowing that the CA has operating insurance or significant assets helps too (that's kind of like how banks decide who they trust when lending money). So directly to your point - the higher the confidence level the better when dealing with significant exposures and therefor the more rigourous the CA's policies in authentication the better off the relying party is. Presenting the site's key fingerprint to the user as a matter of course seems more and more like something that can not be avoided. That's a basic assumption in PKI - you need to authenticate sites in a way that's reproduceable. The thing that happened was that folks decided they would try to bring more robustness by adding the identification of legal identity to system. I don't believe that putting a string of numbers in front of a user is part of a well thought out approach. As a practical aside consider that a website may choose to update their keys for hygenic reasons and may operate in multiple locations. Each instance would have it's own unique keys and certificates and those would change after certifiate or key lifecycle operations (like key update or certificate renewal). This means that if I am a customer of 50 sites in a typical year and they do annual key updates - I'm tracking a lot of data which perhaps you could optimize the software. I suggest that outsourcing that tracking and making your imposition on the user one that is automatic and natural for the user - like recognizing names of companies - may be a better approach as the user much of the complexity is removed from the user and placed on folks who compete in the market. Trust and security are native concepts to people while cryptography is not so if I were developing software that used cryptography to help improve user security I would use natural constructs to present security decisions and hide to the greatest extent possible the underlying science. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ram0502 wrote: key update or certificate renewal). This means that if I am a customer Renewal doesn't usually effect the private key... Although multiple servers with different private keys would be an issue... The thing is while you're hiding the finger prints someone else is intercepting your traffic with a different key and unless you dig into the SSL dialogs you virtually can never tell if anyone is proxying your traffic or not... -- 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-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Duane wrote: Ram0502 wrote: That's an interesting suggestion, it provides the same kind of authentication for HTTPS as the above does for secure email. If the session is initiated by the CA this proves the ability to control the host at the specified location. I wouldn't give them my CC# but it does create a relationship. I wouldn't provide any sensitive information to them as they could be hard to track down if were facing fraud as presumably I wouldn't know their identity. But what if the certificate is only used to protect passwords for webmail and doesn't need the ability to be found for fraud? If I don't have any security requirements in my interactions with a site because I have no risk in them than it seems I may not find it very important to know who is on the other end of the session. Although as part of managing access to my webmail account I may prefer to have my password passed privately to the site, and for that to be useful I need to know I'm at the right site though in this case I just need consistency not a proper legal identity. Given a site that is careful not to change DNS names, and careful to share their keys across all machines that service it at all the locations they may have (Yahoo must have multiple points of presence with racks of machines at each), and the presence of some particular UI elements in web clients I don't need a professional identity checker. These are non-trivial requirements on the site operator but it would save them some money. I wouldn't be surprised if there is room for innovation here but I wouldn't forgoe all my other security concerns in favor of pursuing this functionality. Binary security can't deal with both situations simutaniously and adequately, it needs to indicate visually the level of security... I couldn't agree more that visual feedback to the user is a good UI mechanism. I'll start a thread with some ideas that have been bubbling around my head - visual feedback plays prominently. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ram0502 wrote: ...Trust and security are native concepts to people while cryptography is not so if I were developing software that used cryptography to help improve user security I would use natural constructs to present security decisions and hide to the greatest extent possible the underlying science. That layer used to hide the science is a Petri dish on which the expolits breed. CD Rok ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Duane wrote: Ram0502 wrote: key update or certificate renewal). This means that if I am a customer Renewal doesn't usually effect the private key I agree that it doesn't have to be this way but I bet few people change their keys very often, I suspect certificate renewal is about the only time it happens. I know at least one public CA that requires key changes at the first renewal past a certain key age. ... Although multiple servers with different private keys would be an issue... The thing is while you're hiding the finger prints someone else is intercepting your traffic with a different key and unless you dig into the SSL dialogs you virtually can never tell if anyone is proxying your traffic or not... I think you're saying that because the user isn't comparing key (or cert.) finger prints that they don't know who they are actually connected to. My expectation when I'm at home is that my browser will show me the certificate details of the site *my* SSL session is terminating at - which may be a proxy server. I'm pretty sure that's the behavior of Moz., FF, and IE - am I wrong? ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Duane wrote: Nelson pointed out how bad email verification is, but what if that's all you can prove? IMO, there are cert applications for which low assurance is adequate, and there are those for which greater assurances are needed. By way of example, signed code poses higher risk than signed email text, and so the certs needed for code signing should have high assurance, higher than may be required for email certs. SSL server certs are somewhere in the middle. mozilla treats SSL server certs like code signing certs for java script served over https, IINM, so SSL server certs really should be issued on the basis of the same strong authentication as is more commonly used for code signing cert. If a CA decides that they are unwilling or unable to do anything stronger than weak assurances, then IMO they should limit themselves to issuing certs that require only low assurances. Choosing to be a low-assurance CA is a legit choice, IMO, as long as the low assurance CA doesn't then issue certs used in applications that require high assurance. -- Nelson B ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
C. D. Rok wrote: Ram0502 wrote: ...Trust and security are native concepts to people while cryptography is not so if I were developing software that used cryptography to help improve user security I would use natural constructs to present security decisions and hide to the greatest extent possible the underlying science. That layer used to hide the science is a Petri dish on which the expolits breed. I agree. Thought it's not always the weak point. The RSA implementation in NSS has never IIRC been found to be a failure point in the wild. I'm not saying their perfect just that it's not worth attacking as it's not a practical weakpoint. I think overall there are UI lackings that have greater impact on web client security than the quality of the RSA or SSL implementations in the NSS (or CAPI) stack do. I'm not always convinced when dealing with car repair that I got an accurate assesment or a fair price, I depend on reputations as reported by people I know and journalists and my own experiences and instincts ; I think this is the nature of the compromise we make when we decide to pay others to do things for us. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Nelson B wrote: Choosing to be a low-assurance CA is a legit choice, IMO, as long as the low assurance CA doesn't then issue certs used in applications that require high assurance. Is there something that can be done to add extra bits to the server certs, atm when I see Class 3 server certificates in the browser it's purely informational, why not mark those certificates high trust with bits in the nss libs and then have the chrome show this information, maybe instead of a padlock open/closed, have a set of different icons that show class 3 issued certs visually as being different then Class 2 or Class 1, at present CAcert only issues from the 1 root cert, but we do issue different classes of certificates, at present the length of time is the give away... 180 days = low trust, 720 days = high trust... It's really a no brainier to take that 1 step further and issue them under different root certs etc... Again, binary security can't deal with this other then with informational fields and they are more or less useless unless people actually pay attention to them, which I doubt most people will... So make it blatantly obvious for them, this is good for web mail, this is good for credit cards, this is somewhere in the middle of them both... -- 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-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Duane wrote: Nelson B wrote: Choosing to be a low-assurance CA is a legit choice, IMO, as long as the low assurance CA doesn't then issue certs used in applications that require high assurance. Is there something that can be done to add extra bits to the server certs, atm when I see Class 3 server certificates in the browser it's purely informational, why not mark those certificates high trust with bits in the nss libs and then have the chrome show this information, maybe instead of a padlock open/closed, have a set of different icons that show class I agree, I would like to see an indication of the representation being made. It's really a no brainier to take that 1 step further and issue them under different root certs etc... That seems to be a defacto standard - public roots tend to be specified with a policy (aka class). ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Ram0502 wrote: I agree, I would like to see an indication of the representation being made. Even something simple like a red open lock for no encryption or class 0 (ie test cert with no verification), amber coloured lock for entry level encryption, yellow for medium grade and green for high trust and a tank for class 4/military grade certificates if people want to get carried away with it... :) As far as I am aware, most CAs only issue class 1 to 3 certificates only... That seems to be a defacto standard - public roots tend to be specified with a policy (aka class). I meant for CAcert specifically to issue certs differently in future :) Currently these is only 3 classes we issue from, email verified only which to me doesn't seem good enough for credit card transactions, but is fine for other things like web mail, smtp, pop3, imap etc, that is simply for protecting passwords from people sniffing packets, which is where CAcert kicked off and that was to protect wifi connections from snooping, but not necessarily for protecting financial information. The next class up is ID verified, by at least 2 others which we can request copies of paper work from at any time. Dates of birth, names, and govt issued photo IDs are checked in person etc... Final class is those that want code signing, not only do they need at least 2 others to verify their ID, but they need to have a copy of their govt issued ID on file with CAcert... -- 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-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
