Re: NSS/PSM improvements - short term action plan
On 04/09/2011 10:32 PM, From Adam Barth: Yes. Certificate (or CA) pinning in HSTS is an agreement between a web site and a browser. Excellent! Even though I assume that this still prevents only a particular failure and probably should never be a substitute or shifting of responsibilities by the CAs. But as long that this is voluntarily and optionally for those seeking/needing/wanting an added break, I think that's nice to have. Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. http://www.startcom.org XMPP: start...@startcom.org xmpp:start...@startcom.org Blog: Join the Revolution! http://blog.startcom.org Twitter:Follow Me http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Debian Weak Key Problem
Boris Zbarsky: Could maybe try to brute-force the old key until they come up with a forged certificate that an SSL library accepts? No, not really. It requires the possession of the certificate with the weak key signed by a CA. The whole point is that all the weak keys come from a limited keyspace, right? That's correct. This allows to find the ~100,000 possible keys per key size the right one. Who said anything about Mozilla knowing? The idea here would be to have the browser detect it and refuse to go to the site or something; no need to communicate anything to Mozilla. Oh, that would technically not be possible I guess. Searching for such keys dynamically could take hours per key, hence previously created keys are used. They would need to be hosted somewhere and compared to. That's why Mozilla would know about which public key was used (the least). The premise (and a not unreasonable one) is that such a list can be generated if needed. I expect that Mozilla will not come up with the resources for it. Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Debian Weak Key Problem
Gervase Markham: Eddy Nigg (StartCom Ltd.) wrote: Oh, that would technically not be possible I guess. Searching for such keys dynamically could take hours per key, hence previously created keys are used. They would need to be hosted somewhere and compared to. That's why Mozilla would know about which public key was used (the least). As https://bugzilla.mozilla.org/show_bug.cgi?id=435082 explains, we would have a locally-stored blacklist. Locally stored where exactly? Do you have an idea how big such a list which would cover just the most commonly used key sizes would be? Doesn't sound feasible to me, hence I thought you were talking about some kind of lookup service. What makes you expect that? Such a list of weak keys already exists, anyway. http://metasploit.com/users/hdm/tools/debian-openssl/ Yes I know obviously. That's exactly why I think it's not in the cards. Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Debian Weak Key Problem
Gervase Markham: Eddy Nigg (StartCom Ltd.) wrote: Locally stored where exactly? Do you have an idea how big such a list which would cover just the most commonly used key sizes would be? Doesn't sound feasible to me, hence I thought you were talking about some kind of lookup service. Read, the bug, Eddy! :-) There are size estimates in it. If you think they are wrong, post better figures, with your working. I've read the bug previously, which news should I find there? Some suggestions were somewhat optimistic I think, but don't have the time to prove it otherwise. But if we are at it this bug already than I'd recommend re-reading the comments from Nelson. Additionally, getting the list from Netcraft sounds to me most appealing if you want to do anything useful within reasonable time. The question is, if they'd give it to you... Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Debian Weak Key Problem
Hi Gerv, [Off-topic] For one I must notice the incredible inconvenience in working with Bugzilla and this mailing list. It happens many times that the same issue is discussed and tracked at different bugs in parallel. I'm a CC bug 434128 and just got aware of bug 435082. Can you tell me the best way how to KNOW about such bugs which are related and might interest me? I can't spend my time searching all day long and on a daily basis for new bugs. I guess there is a formula or something...? [On-topic] Here is how I evaluate the situation. Debian users are generally more aware and more informed about problems such as these in relation to other server products (which includes obviously all brands). This situation doesn't apply always on shared hosting. StartCom offers two ways of creating server certificates, one way is to create ones own private key and submit a CSR, at the other way the Certificates Wizard creates it on behalf of the client. The majority of CSR submissions are for IIS servers with a small minority being for Apache users. The rest creates the keys at StartCom. Those keys aren't subject of this or similar bugs. Out of the Apache users which create their own CSR (and hence private key), Debian users are again a minority, at the most 10%. Judging from the revocation requests we received, at least one third of those requested revocations. There is about one third which didn't succeeded in installing the certificate or for other reasons haven't made use of the certificate (for example realizing the need for a dedicated IP address etc). Therefore we have about another one third which might be still using a weak key. This boils down for very few still affected sites, probably less then 1.66 %. Since all certificates issued at StartCom are valid for one year only, the risk assessment didn't warrant for a full scan of all public keys considering the effort which must put into such an effort. I expect the situation to be similar at most CAs. See also inline comments. Gervase Markham: Firefox 2 does not have OCSP turned on by default. Both browsers support CRLs, but do not have the capability to download CRLs from URLs listed in certificates. This is a known shortcoming of FF2 and inherits higher risks then weak keys. That's because if a certificate is revoked because of a weak key it was most likely requested by the subscriber himself and he wouldn't continue use of the weak key anyway. Hence this would make only sense if CAs would revoke such certificate unilaterally. However, because CAs are not actively contacting their customers, many weak keys will still be being used, and we'd have no way to tell if there was an MITM going on in that case. That's correct. Lists of all the weak keys exist - we could create a database of the first 8 bytes or so of the hash of each and get NSS to check it when it sees a key. This would involve a code change to NSS and a security update. We'd probably want to download the list of weak keys rather than ship it with the update. NSS would then return an error to the application if a weak key was found, and the connection would abort.[3] - Modify NSS/Firefox to detect weak sites I would cite privacy concerns with such a scenario. If we can get a fairly complete list of vulnerable sites How do you intend to find them? We could use our contacts with CAs to try and convince them to change their position on customer contact. - Publish a CA hall of shame And what if a CA refuses to comment or provide this information? - Turn on OCSP in the next Firefox 2 security release This might help in the short term, with the same limitations as listed under Do Nothing for the Firefox 3 update. But Firefox 2's OCSP support is not as complete; it doesn't do caching, and it hard-fails. So we might melt the OCSP servers, and that would severely degrade the user experience because no-one could make SSL connections. Yes, that's not a good option really. - Ship a Firefox 2 update with some built-in CRLs Again, see above that this makes only sense if an affected site owner would refuse to replace the certificate because of somebody detected a weak key. I haven't encountered such a situation yet and doesn't make much sense. Suggestions? Even if it doesn't sound so good, do nothing is the right thing to do I think. Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Debian Weak Key Problem
Boris Zbarsky: But the MITM attacker could use it to impersonate the site, which is the whole point. Yes, in case the attacker managed to get a copy of the previously used and signed key. Not, in case the subscriber managed to change his cert before. - Modify NSS/Firefox to detect weak sites I would cite privacy concerns with such a scenario. Like what? I wouldn't like Mozilla to know which sites I'm visiting (including non-publicand, eheeem all the others ;-) ) How do you intend to find them? web-crawlers are not exactly rocket science. Nope, but needs quite some resources in order to receive some valuable results within reasonable time. So the real question is: given an SSL handshake, how does one tell whether the site is vulnerable? I believe there are ways to detect this, based on other mails I've seen going through. Yes, certainly, but even this might require quite some CPU cycles. And what if a CA refuses to comment or provide this information? Provide what information? Whatever they decided to do in respect of this threat. If there is a list of vulnerable sites, there is a corresponding list of CAs, since the site certificate says who the CA is. Correct, but it's a big if for now. Again, see above that this makes only sense if an affected site owner would refuse to replace the certificate because of somebody detected a weak key. Again, I don't think that's correct. Well, actually the Debian folks are rather security conscious...in relation to that they are also the ones preferring Icewiesel and Cacert because it ain't free enough, with purified openssl for the topping ;-) That's the perspective of the CAs (including yourself), sure. We know that already. I had no clue what other CAs decided in that respect and I offered our estimates and decisions on this subject. That's not something coordinated. I'm open to suggestions as always. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: [Fwd: Secure Server e-Cert Developer e-Cert. Comerica TM Connect Web Bank]
I just wonder why the h*** Google anti-phishing tool still allows me to go to http://comerica.connect.tmconnectweb.login.cgi.msg5984.time32491989.webbizcompany.c1b9r62whf314lx53xq.secureserv.onlineupdatemirror66272.comerica.certificateupdate.cxv32.com/logon.htm Should they have blocked the cxv32.com domain already all over the place? Tested with FF3 and FF2... -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: [Fwd: Secure Server e-Cert Developer e-Cert. Comerica TM Connect Web Bank]
Eddy Nigg (StartCom Ltd.): I just wonder why the h*** Google anti-phishing tool still allows me to go to http://comerica.connect.tmconnectweb.login.cgi.msg5984.time32491989.webbizcompany.c1b9r62whf314lx53xq.secureserv.onlineupdatemirror66272.comerica.certificateupdate.cxv32.com/logon.htm Should they have blocked the cxv32.com domain already all over the place? Tested with FF3 and FF2... Oh, and just by the way...now that we are at it...How easy it would have been for cxv32.com to get a wild card certificate from some of the CAs in NSS, making the phishing attack even more convincing. The theory that we have anti-phishing tools simply doesn't hold the water, an argument which was used multiple times against any strengthening of the Mozilla policy. A sub domain name like the one from above most likely would never have been issued, not even by the CAs which issue domain validated wild cards, at least this sub domain name would have raised enough attention if the CA has also some personnel there... -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: How to get a free certificate
Jose Luis: As mentioned in http://www.mozilla.org/projects/security/components/signed-scripts.html Javascript must be signed with certificates when trying to enable priviledges. How do I get a free certificate for this. Hi Jose, As far as I know there are none. It might be that GoDaddy still gives out code signing certs for open source projects for free (so I haven't seen for along time about it, they might have discontinued it). Besides that, it's highly unpractical to sign javascripts and html pages (as all of them must be signed and placed into the jar) for most sites, since todays requirements and sites are mostly not static, but dynamically assembled on the server side. In my opinion, the security concept of the Mozilla browser(s) is not really usable... :-( -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extract of CA certificates
Hi Gerv, Gervase Markham wrote: Eddy Nigg (StartCom Ltd.) wrote: Or I could simply push the Backup button of the certificate viewer? Except that in this very specific case, the copyright of the different CA certificates are perhaps that of the CAs themselves. However distribution of the CA root is many times part of the CP/CPS of the various CAs and most of the time encouraged (The relying party should be able to verify the signer and CRLs etc)? I'm afraid I don't understand this question, if it is a question. It's not a question, it's a statement ;-) The obligations of the relying parties are often defined in the CP/CPS, which requires the RP to perform various actions, like checking the validity of the certificates, its status (CRL) etc. The RP must have the CA root to perform these actions...therefore I assume that publishing and usage of CA roots are not only a privilege but a requirement. Actually, apparently I was wrong about that. certdata.txt is compiled. I know, but an extraction of the certificates from that file and loading the result of this extractions at run time makes a difference I think. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extract of CA certificates
Hi Gerv, Gervase Markham wrote: The copyright status of the data does not change as a result of you obtaining it from us as opposed to obtaining it directly from the CA. Or I could simply push the Backup button of the certificate viewer? Except that in this very specific case, the copyright of the different CA certificates are perhaps that of the CAs themselves. However distribution of the CA root is many times part of the CP/CPS of the various CAs and most of the time encouraged (The relying party should be able to verify the signer and CRLs etc)? If you or your lawyer are concerned that the data may be tainted by being passed through Mozilla CVS, then you should re-visit each CA and download their root certificate from them directly. No, this isn't my concern. What's the problem with being bound to the tri-licence anyway? Choose the MPL, and then the licensing conditions don't affect any of the rest of your code. certdata.txt is a self-contained file. Right, the problem is, that some projects use different licenses then one of the three, making it under certain circumstances incompatible. However since the content or extraction of the certdata.txt file can be loaded at run-time as opposed at compile time, this problem could be solved that way easily. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extract of CA certificates
Frank Hecker wrote: Indeed, although there are in fact CAs that attempt to get you to sign up to some sort of agreement before downloading their certs. (I can't remember at the moment exactly what they apparently were trying to accomplish by doing this.) Perhaps it was this one? http://www.verisign.com/repository/roots/pca_certificate.html -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extract of CA certificates
I very much appreciate your thoughts and advices! As I'm trying to help another open source project, which uses a different license than the ones Mozilla offers, I'm not going to pursue this matter much further, except giving them the same advices you gave me. Thanks a lot to you all! Frank Hecker wrote: Eddy Nigg (StartCom Ltd.) wrote: So is the assumption correct, that if I or anybody else extracts the CA certificates from certdata.txt and uses the result of it, isn't bound to any licensing constraints, similar as the content of a web page which the browser displays isn't part of the software itself? Eddy, if you want a definitive answer on this you really need to consult a lawyer. All that Gerv, Nelson, I, or anyone else can give you is our personal opinion, which to be honest with you is worth exactly zero should you ever get into a legal dispute. If you're interested in pursuing this further, I'd be glad to correspond with you via email to give you and your lawyer my personal opinions on the situation. Frank -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Reassessment of sub-ordinated CA certificates
During the last few month many issues concerning sub-ordinated CA certificates of CAs, considered for inclusion and CAs already included in NSS, have come up at this forum. Today exists a situation where the Mozilla CA policy doesn't provide enough guiding and definition, because the policy was defined originally with assumptions not holding the water for todays realities (freely quoting Frank here). I have the feeling that everything related to sub-ordinated CA certificates has reached dangerous levels and makes it almost impossible to clearly know if the Mozilla CA policy is still protecting the user of the various Mozilla products. There are and were various situations and setups of different CAs from: - governmental institutions issuing sub CA certificates to authorized CAs, - sub CAs shipped via Internet download by the issuing CA, - CAs which are chained to such an extend, that it's hard to believe that the CA which has its root in Mozilla, has any control over the issuing entity, - sub CAs without any clear policies in place, - Auditing of said CAs simply non-existent and more... Additionally, in a short time, various CAs will be considered for upgrading to EV status, including at least one CA with more than _124_ sub ordinated CA certificates, of which all of them are supposed to receive this status. This is such a wide spread phenomena which has outgrown our current policy to such an extend, that _I'm requesting hereby and now to have thorough review of this situation and reassessment_ of the Mozilla CA policy concerning everything related to sub-ordinated CAs. Please note that I'm not making any suggestions and arguments right now about what a sound policy should be, rather I believe that it requires an extensive assessment of the current situation and related discussion in order to define the best definitions. But there is going to be an unbelievable, explosive situation also in relation to EV upgrades which perhaps nobody of us has foreseen, a situation which goes completely against the spirit and objectives of EV itself - the major reason why Mozilla has supported this effort in first place! In connection of this request, I'd also like to have cross-signing between CA roots defined in the Mozilla CA policy, since cross-signing might touch a similar field, which could at some point land us in a similar situation of loosing control. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extract of CA certificates
Thanks for your answer! Gervase Markham wrote: Eddy Nigg (StartCom Ltd.) wrote: Since sometimes there are some licensing concerns with the certdata.txt file, I wanted to know exactly what one is allowed to do. If for example by merely extracting the CA certificates with a tool like http://curl.haxx.se/lxr/source/lib/mk-ca-bundle.pl still requires the resulting CA bundle to be bound to the tri-license of Mozilla? Or can I simply extract all CA certificates from the browser by exporting them? I think the correct position is that the certdata.txt file is data used by Mozilla, rather than part of the browser itself. It's a grey area. So is the assumption correct, that if I or anybody else extracts the CA certificates from certdata.txt and uses the result of it, isn't bound to any licensing constraints, similar as the content of a web page which the browser displays isn't part of the software itself? The copyright in the certificates technically rests with the CAs, but it would be a very strange CA which forbade you from shipping their certificate in your product. I'm not sure what the legal position would be there. At this stage I mostly care about the Mozilla licenses and need a clear answer, if a third party can make use of an extract of the certdata.txt. Personally I would believe this to be the case, but I want to have that confirmed in some way in order to let other products make use of it without being bound to the tri-license of Mozilla. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Extract of CA certificates
Many times applications ship a CA certificates bundle with the product. Many times they are derived or extracted from the certdata.txt [1] file or simply exported from the browser. Since sometimes there are some licensing concerns with the certdata.txt file, I wanted to know exactly what one is allowed to do. If for example by merely extracting the CA certificates with a tool like http://curl.haxx.se/lxr/source/lib/mk-ca-bundle.pl still requires the resulting CA bundle to be bound to the tri-license of Mozilla? Or can I simply extract all CA certificates from the browser by exporting them? Obviously the CA certificates themselves aren't property of Mozilla, but of the CAs, I wonder if the certdata.txt and/or and extraction from it changes anything. Does Mozilla in one of the cases still retain the copyrights? Can a waver be granted for this specific file? I simply don't know the answer, but try to help another project solve an issue with this, which affects many other applications. Thanks! [1] http://lxr.mozilla.org/seamonkey/source/security/nss/lib/ckfw/builtins/certdata.txt -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Mozilla isn't trusting its own certificates
Boris Zbarsky wrote: Tony Mechelynck wrote: If I try to add it, I can't, because SeaMonkey asks me for my LDAP username and password, and AFAIK I don't have any. Right. Only MoCo employees and contractors do. Note: If this remora-reskin URL is really some restricted site accessible only to a select few people Looks like it is, yes. It's not a security restriction, though, just an internal server kind of restriction. And yes, posting internal server stuff in bugs is bad. Strongly reminds me of the Netscape days. :( Nevertheless you (Mozilla) might consider securing such stuff with certs from http://www.startssl.com/ , even so wild cards aren't free usually, we could arrange that. CN = Mozilla Root CA OU = Mozilla Corporation Root Certificate Services Reminds me of some other CA using the Root word in their certificates ;-) -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
CA policy and EV
This post is about bug reports 383183 and 398944 and the relation of EV certificate support in the UI (and to a lesser extend in the NSS library) and the Mozilla CA policy (http://www.mozilla.org/projects/security/certs/policy/). Currently the Mozilla CA policy doesn't define EV's minimum requirements, acceptable criterion or trust bits. In fact the policy currently supports only three types of certificates: * SSL-enabled servers, * digitally-signed and/or encrypted email, /or/ * digitally-signed executable code objects; The policy doesn't define _any_ distinction between certificates as such beyond the types mentioned above. Neither does the policy define the criteria if, when and how a certificate should be treated differently (as suggested for EV certificates) in the UI. Neither does the policy define minimum requirements for EV (section 7). Neither does the policy define the criteria for CA operations for EV (section 8). Section 14 of the policy doesn't support EV. Currently ANY/NO certification authority with a root certificate in the NSS CA in the Authorities DB might be eligible to issue EV certificates - or not - according to this policy. EV support should not be enabled anywhere in Mozilla products until a binding policy governing EV certificate support is defined and/or the Mozilla CA policy is modified in that respect. In relation to bug 398944 the policy requires CAs to submit a request themselves (section 5 and following) and decisions are taken through a public process (section 2). More than that I was told that the CAB forum refused or is unable to provide a list of so called EV issuing CAs. I suggest to close bug 398944 because the bug is simply not relevant nor doable from a practical point of view in addition of not being compliant with the Mozilla CA policy. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Updating Mozilla CA certificate policy to address EV certificates
Frank, thanks for addressing this issue! Frank Hecker wrote: As noted in the bug, I think an EV-enabled root CA cert is simply a special case of root CA certs in general, so we don't need a whole new separate policy. At the same time I don't want to revise every section of the existing policy, and if possible I'd like to avoid changes that necessitate renumbering and reorganizing the current sections of the policy. I'm therefore leaning toward having an EV addendum to the policy, and putting all the EV-related stuff there. Then we could simply modify section 6 (We require ...) to add an additional paragraph pointing to the addendum. This would result in a version 1.1 of the overall Mozilla CA cert policy. I also think an extension might be the better thing to do. There might be more changes in the future (initiated perhaps by the CAB forum) which would require more edits, additions and changes. This would leave the current CA policy mostly as is now and in the future. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Firefox 2.0.x: tracking unsuspecting users using TLS client certificates
Arshad Noor wrote: My understanding of the TLS protocol is that the browser only sends the certificates signed by CAs that the server trusts; are you saying that the protocol allows for asking ANY certificate from the browser cert-store, regardless of who signed it? Yes, one can configure a web server to accept ANY certificate for client auth. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Firefox 2.0.x: tracking unsuspecting users using TLS client certificates
Arshad Noor wrote: They would know the CA that issued the particular client certificate and include it in it's Request/Not require client auth message. Actually funny that I never thought myself about such an option. But a competing CA could harvest the email addresses, which are usually present in client certs, of the competition and spam them for their services...good thought ;-) -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: nsinstall: Command not found
Thanks for the tip! I didn't knew that... Nelson B wrote: Eddy Nigg (StartCom Ltd.) wrote: Does anyone know what the issue might be when trying to build from trunk? After checkout and building browser or mail static I'm getting: gmake[6]: ../../../config/./nsinstall: Command not found See http://lxr.mozilla.org/seamonkey/find?string=nsinstall.c There seem to be 5 versions of this program in the source repository. I don't know which one of them you need. (I use the one in coreconf for NSS) -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV and mixed content
Gervase Markham wrote: I was giving the example of e.g. Google AdWords, where content on your site is served from a 3rd-party site. So not all of the site can be served by the same certificate. Parts will be your certificate, and parts will be Google's. OK...understand...Your example above raises another few questions: 1.) Are Google AdWords secured by SSL to start with? 2.) Should secured pages include such content as third party adverts, third party analytics and other stuff which might track movement and content to a third party? Personally I think this would be a basic breach of the initial purpose of privacy and encrypting content. I'd rather not supply my personal details to (secured) site which has all kinds of third party scripts included... To all of my knowledge Google Analytics and AdWords aren't secured by SSL and inclusion of it would downgrade regular SSL connections (broken lock) anyway. So perhaps the initial question of this thread is really important and I suggest to require same certificate (or at least same level) per site. It makes sense in my opinion... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV and mixed content
Justin Dolske wrote: That doesn't seem all too different from a vanilla-SSL site having an XSS hole. Mhhh...if the site contains unencrypted content, then the browser notices it. If the parts are served by a different site (and certificate) there is no notice. However the issue here is about EV or non-EV (if there will be any distinction), which would make a difference. The same might be true if we'd make a distinctions between other different levels of verification methods. I'm not sure how that could be explained to a user in a meaningful way, either. I'd also be wary about building the impression that content served under an EV cert is somehow more trustworthy, Hehe...we try to avoid the trustworthy word in connection with EV (and certs) ;-) Also, a more practical concern would be that if existing an existing SSL site is already linking to SSL content under a different certificate, then upgrading to an EV cert would break that. That might just be education issue for purchasers of EV certs, though. From the site operator perspective I don't see any reason why a site shouldn't be served by the same certificate (or same level). If certificates are going to be mixed, then I think it should be downgraded to regular SSL, very similar to having the broken lock in the address bar. Like this site owners take care of correct installations. Similar, if you have a valid certificate and mix content from a site with a self signed certificate, the browser complains. Guess something like that should happen here as well (i.e. downgrade). -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV and mixed content
Gervase Markham wrote: Right. But allowing this makes it possible for the identity presented to not be the identity of the owner of the content. Correct! That might actually lead to the idea that we should require that all the content comes from the same company (O field). But that would be fairly extreme. Oh no! There can be multiple certs issued by the same/different CAs and different levels with exactly the same organization name. That's not a good idea in my opinion, even if the different certificates indeed would belong to the same owner - we'd like to know if something on the same site is served by a different level then claimed originally. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV and mixed content
Lets suppose a web hosting company acquires an EV cert and provides for its clients some nifty re-write rule to let appear the site as EV verified, but the actual content is served in a iframe - from the clients regular SSL secured site. Which answer would you propose to your question below? Obviously this is only important if a distinctions is made between EV and others... ;-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 Gervase Markham wrote: As I'm not sure of the way the proposed implementation for EV indication works, I don't quite know who to address this question to. I'm hoping the right person is reading :-) At the moment, if a web page has some http and some https elements, Firefox (rightly) complains. You only get a lock, and a lack of warnings, if all of the page elements were served over https. Will whatever NSS or PSM flag is set to say this page has an EV certificate only be set if _all_ page elements are served from a server with such a certificate? Apparently, at the moment, IE displays the green bar if the top-level page is EV, and the rest is normal SSL. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV Draft Review Discussion
Gervase Markham wrote: It's a fair question. I agree that communication about the plans could be improved. I'll think about how best to do that. After some hard thinking by myself I'd suggest the mailing list and bugzilla as commonly used and established communication paths... :-D -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: CAB Forum meeting report
Gervase Markham wrote: Eddy Nigg (StartCom Ltd.) wrote: Is there a way to have them commit to that in some way or form? And what if they'll just say: Well, we looked at it and it's not possible after you already voted in favor? I think it's rather unlikely that they would say that, given that we (i.e. Frank) have done our own analysis of equivalence and they are pretty similar. This work will take some time, and we don't think it's correct to hold up the approval of version 1.0 over this issue. I understand that it will take some time and effort, and I didn't expect it to be part of the Guidelines right now. Some sort of formal or informal commitment, to which Mozilla could refer in future might be fine. I think, that the statement from the previous mail - *to separate the WebTrust EV audit criteria out, so that other auditors could audit against them* - would pretty much reflect and be in line with the nature of Mozilla as an organization and the Mozilla CA policy, which was specifically created by Frank and the community to allow that type of openness. Gerv, maybe you want to update the page at http://wiki.mozilla.org/User:Johnath/EVDraft13ReviewComments in that respect? Because it says currently: /The representatives from WebTrust and the audit firms also said that they were going to do an equivalence analysis between WebTrust and ETSI to see whether one could do an WebTrust EV Audit on top of an ETSI audit./ This is certainly not the same, if you compare both statements. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV Draft Review Discussion
Gervase Markham wrote: Like everything, it's a trade-off - keeping revoked certificates in CRLs has a cost (download time and bandwidth) Sorry, I forgot to mention that a revoked certificate is worth about 30 bytes in a CRL. Just to get about the proportions -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV Draft Review Discussion
Gervase Markham wrote: If revoked certificates have to be listed even when expired, that means that expired certificates have to be revoked if the private key is compromised. Yes, I would suppose that. Or a private key has to be destroyed correctly in first place. So, the certificate holder has to continue to keep the key secure even after expiry. Absolutely! First of all a private key can be reused many times over for new certificate requests. Actually you can use the same private key for hundreds of certificates (not common practice but still possible). If a private key is compromised after a certain certificate expired, than this key could be still misused...Or lets try it the other way around: Please publish the private key of the web site mozilla.com or microsoft.com after the certificate expires next time...will you please? Revocation of a certificate is not something which should be taken lightly - it certainly isn't equivalent to expiration. No-one is saying it is. But it is also pretty unlikely that a certificate would be revoked close to its expiration date. And what if it does happen? If a certificate is issued incorrectly, for example, these sort of things tend to be discovered rather quickly (like when the phisher sets up his site). And what if not? They will get smarter too perhaps, so phishers aren't interested in this..but some real crime would... Can you give a plausible and specific scenario where keeping certs in CRLs significantly past their expiration date would prevent some evil activity? Sure! 1.) Supposed the certificate was issued to a party not eligible for this type of certificates (i.e. a reason for revocation whatever the cause), the owner of the certificate can continue to use the certificate in question (after it expired). All a visitor will see is, that the certificate expired. Do you know how many computer savvy users continue to trust that certificate, not talking about the standard user who doesn't have a clue? The computer and Internet savvy will say: Oh well...the certificate just expired a few month ago...that's fine, I can still trust itafter all it was issued by XYZ and even an EV certificate... 2.) Supposed the private key was stolen from the owner (maybe by some disgruntled admin of the company or some criminal working at a hosting company perhaps)...Supposed this was recognized correctly, dutifully reported and the certificates was revoked. But as soon as it expires, it can be used againall what would happen is a warning message that it expired...which isn't really the same! The fact that connections to expired certificates are allowed by most if not all browser vendors contributes to this problem, if this certificate is removed from the CRL...than it's just an expired certificate which was once valid, compared to a certificate which is actually revoked. You're never satisfied, are you, Eddy? sigh What happened at the meeting was a big step forward towards allowing non-Webtrust auditors to do EV readiness audits. Well, I was also reading your CAB Forum meeting report and it's indeed a step into the right direction...But still, I think the principal question about the character of this organization just remains. Currently only webtrust accredited auditors can perform the EV audit if I understood correctly...(Correct me if I'm wrong). I can understand, that webtrust and its accredited auditors want to protect their investment, but our agenda is a different one and obviously I don't have to be satisfied with it. But what really surprises me is, that why such principal and important decisions about the type and nature of the proposed forum weren't made at its founding? Why weren't openness (in respect to participation, audits, etc) one of the key conditions for Mozilla? Crawling now back and trying to open it up is obviously much harder and I congratulate you for every success you achieve. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV Draft Review Discussion
Please allow me to comment on a few responses... Gervase Markham wrote: Following discussion on the CABForum email list, a new draft, a two-day face-to-face meeting in San Francisco. Taken from http://wiki.mozilla.org/User:Johnath/EVDraft13ReviewComments It would be *nice*?? if revocations were never dropped /After discussion on the CA/Browser Forum mailing list, it was agreed that no change was necessary here. This requirement would place unwarranted burdens on CAs and certificate holders. The RFC states that revoked certs must appear at least on the first regularly-scheduled CRL update after the expiry date./ This is one of most lame things I ever heard (sorry for the language)...but let me explain this: / This requirement would place *unwarranted burdens* on CAs and certificate holders./ About which burden are they talking about? *Burden?* Supposed that EV certificates are issued only after a rigorous verification procedure, such certificates shouldn't be *never, ever* issued in first place, if there might be the slightest chance for a fraud or reason for future revocation. Full Stop! Can anybody explain to me, why an EV certificate should be a candidate for revocation ever? And if this would ever happen, this would be a very grave situation and such a certificate should never be dropped from the CRL/OCSP. And if they expect this to be an *unwarranted burden*, than perhaps I should ask about the dimensions of the expected revocations...which doesn't sound good at all! The only valid reason for revocation might be, that the user has lost or corrupted the private key or the private key is suspected to be compromised. In this case, the situation is similar grave and the CA must protect its client properly by revoking the certificate and *keep it revoked*. Also here I suggest, that the CA takes measures and provides proper support and training to the client in order to prevent this from happening in the first place. Additionally there is no burden whatsoever on the certificate holder as suggested in the response for having a revoked certificate listed in the CRL forever...or please enlighten me about which burden they are talking about. /The RFC states that revoked certs must appear.../ The RFC states...??? Really? I don't believe it! Well...the various RFCs state or don't state many thingsIf they want to go with the RFCs, so why bother creating guidelines which are supposed to improve things? The RFC don't require many things, still the proposed guidelines do exactly that...Common! This can't be serious _ Conclusion:_ Revocation of a certificate is not something which should be taken lightly - it certainly isn't equivalent to expiration. If this isn't going to be improved, then I suggest to make urgent changes to the code, in order to not allow connection to web sites with expired certificates anymore. Very unfriendly for the certificate holder and visitors so...Except that, obviously CRL checking should be ON by default anyway! Concerning audits: /...//that they were going to do an equivalence analysis between WebTrust and ETSI to see whether one could do an WebTrust EV Audit *on top* of an ETSI audit//.../ WOW! What an improvement! This almost knocked me out of my chair... Why the insistence of the Webtrust monopole? How about *opening up the guidelines and requirements for auditors without strings attached*, in order to enable potential auditors worldwide to perform third party audits? Why should this organization and its auditors hold CAs hostage and enjoy a monopole status? What about Europe, Asia, Africa, South America, Australia? Is only North-Americas Webtrust and its auditors capable and enlightened enough to do that properly? Or is it perhaps poorly about financial interests? _Conclusion:_ Mozilla should request the publishing of the guidelines for auditors and define requirements for auditors *without* any lock-in or requirements of membership to any organization. Potential auditors should be able to perform third party audits of CAs to the letter worldwide. Otherwise I suggest, that Mozilla as an open, global and community orientated organization refrains from voting in favor of the EV guidelines! -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
Mele wrote: The microsoft.ipsos.com is on rackspace.com which is another Microsoft partner. Firefox should not bork at this Microsoft partner site. The certs are at the site and IE has no problem getting them. Well...First, this kind of domain name is unfortunate and one can't blame the user for not getting used to all kinds of microsoft.something.com URLs... Second, Firefox barks at any web site, which doesn't have the certificate installed correctly. This has nothing to do with Microsoft partners per se... It is one of the weak spots in Fx and I'm tired of the problems. It's currently not a weak spot of Firefox...but I asked Nelson for the RFC which suggests that one /can/ fetch intermediate CA certificates the way IE does. If there is such a standard which suggests it as an option, than I think Mozilla should implement it You just blamed the server at the Ipsos site. Correct, the installation is not complete at that site! Maybe the blame is on a misconfigured server Yes, it is! It is not configured and installed correctly! This *is* the problem... If you install a web page wrongfully on your web server and the page doesn't render, who do you have to blame? The browser? Of course not...so in this case, this is a problem of the server admin as well... but finger pointing doesn't get the problem solved. You did not offer one constructive idea of how to fix this sort of problem that Fx has, but IE doesn't, other than complain to the webmaster or better just go use IE. I'd rather suggest *not* to visit that site and *not* participate in any survey until the problem is fixed! Obviously this site doesn't really give you a good feeling...judging from the URL, certificate installation etcI wouldn't provide any data...But perhaps this is what it's all about? Maybe they don't want non-microsoft - non-IE users to participate? ;-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
Nelson Bolyard wrote: We're working on it. Now up to 60,000 lines of new code for it, and still growing. This feature is actually necessary in bridge CA (a.k.a. Cross certified CA infrastructures, which are now beginning to emerge, mostly in Asia. Cool! So I guess this issue gets addressed now anyway... Earlier, Eddy wrote: At our CA, we have a robot checking for missing ICA certificatesand send an appropriate message to the subscriber... And by the subscriber, Eddy means the web site administrator who acquired the cert for his server. Eddy, that's brilliant. It's a service that adds tremendous value for your subscribers and all their users/customers. I wish more CAs did that. Thank you for the flowers :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
Melelina wrote: Also, why am I unable to edit the cert issued to http://www.microsoft.ipsos.com/ which I took from IE and put in the Fx Cert Manager? I want to trust this cert but when I use edit and click the trust button upon closing the Certificate Manager my edit is reversed and the do not trust button is chosen. How good that this certificate isn't trusted...which CA issues such a certificatewww.microsoft.ipsos.com? I guess that the signer is a fake Verisign certificate -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
Gervase Markham wrote: IE will also have a similar problem, but only if it has never encountered a correctly-configured web server (i.e. it caches intermediate certs). So IE in new installs of Windows will also have the problem. This is not correct! IE fetches the intermediate CA if it finds a CA issuer extension within the subscriber certificate, which isn't really by any RFC, but nevertheless very useful! Many server installations are missing the intermediate CA files and IE gets around this problem in this way...Something to consider for Mozilla Firefox? At our CA, we have a robot checking for missing ICA certificatesand send an appropriate message to the subscriber... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
I can create a cert which claims to be a VeriSign Class 3 Secure Server CA and sign my webserver's cert with it. If you then visit my website, you'll get exactly the same error as you see at the ipsos.com site. Which however means, that your certificate installation isn't complete and should add the intermediate CA certificate to your server...Which server software are you using? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
I'm replying now to my own mail, as I misunderstood the statement from you...Of course this is not the correct answer to what you said Eddy Nigg (StartCom Ltd.) wrote: I can create a cert which claims to be a VeriSign Class 3 Secure Server CA and sign my webserver's cert with it. If you then visit my website, you'll get exactly the same error as you see at the ipsos.com site. Which however means, that your certificate installation isn't complete and should add the intermediate CA certificate to your server...Which server software are you using? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
Hi Nelson, Nelson Bolyard wrote: Yes, there is a standard for certs that allows (but does not require) relying parties to go search on the internet for missing intermediate CA certs. Do you have the quote from the corresponding RFC for this? But that standard does NOT relieve SSL servers of the obligation to send their entire server cert chains Correct. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
they are also marked with Persona not validated or similar and are signed from a Class 1 issuer. I agree it is not good to lump everything into one category, Good! but I say that it's unavoidable without documented and third-party-audited standards so we can meaningfully discriminate. Having the Mozilla project find resources to do our own audit is just out of the question. Right! But Mozilla can provide the foundation and framework for having certificates marked correctly. The Mozilla CA policy can be the definition (Call is standard if you want). The CAs get audited as before and the subscribers and relying parties (i.e. the public) are the people making the judgment (with the help of a good UI). When thousands of people are able to know about a certificate a lot more than today - with a clear definition in place - no CA will dare to cheat. Should it happen nevertheless, Mozilla must have a clear definition what it is going to do in such a case. This should be an effective and binding policy. BTW, perhaps you might ask the CAB forum, why they didn't think about such a plan like our proposal. Why should 99% of the SSL certificates remain unclassified and broken in the browsers? Shouldn't have this specific forum come up with a solution for all certificates? -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
and framework for having certificates marked correctly. The Mozilla CA policy can be the definition (Call is standard if you want). The CAs get audited as before and the subscribers and relying parties (i.e. the public) are the people making the judgment (with the help of a good UI). When thousands of people are able to know about a certificate a lot more than today - with a clear definition in place - no CA will dare to cheat. I just don't see that world ever happening. Most of the planet has far better things to do than learn about certificates and CAs. Supposed the UI is able to make this visually easy to see and/or the required information is easily accessible, than this might just work. Except that, also not every user is your mom ;-) Because they agreed with me that there was no possibility of imposing standardisation on the existing product set. Really? :D Firefox has a market share of something like 15% worldwide. Not a majority, but not to be sneezed at either. So I have some good news for you...In Europe, specially Germany the market share is sometimes more than IE. I always like that one too: http://www.boingboing.net/stats/#browsers (This site isn't a geek site or so...in the US I think...Firefox had less than 10% about 2 years ago...enjoy :-)) -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
Ben Bucksch wrote: (You *may* be thinking of DV (Domain Validation) and Class 1 SSL certs. These are indeed insecure and make SSL a joke. They were a really bad idea and that is one of the reasons behind EV.) Ben, the reason behind EV (or any higher verification in that respect) is about the *identity validation*, which is non-existent in domain validated certificates. However please backup your claim, that domain validated certificates in relation to DNS spoofing are insecure. Or even better, I invite you or anybody else with knowledge on the subject to create a certificate for microsoft.com at our CA (https://cert.startcom.org/?app=101type=1 Direct link to Class 1 certs at StartCom). If you succeed, I believe you, else the claim is not valid. The problem is *not* the domain validation really, but the fact that the identity behind the domain is not validated - two completely different things really! Assuming no DV/Class1 crap, SSL indeed solves the insecure DNS problem, as Heikki stated. Therefore even if Verisign is issuing an EV cert for themselves, you can not be assured that the cert hasn't been stolen and the DNS altered I guess they use them for testing and promotional reasons, same as StartCom uses Class 3 and Class 1 for its own web sites. -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Practical steps question for multi-level proposal
Gervase Markham wrote: Eddy Nigg (StartCom Ltd.) wrote: This is why I asked how to continue from here. But there is a general proposal on the table, which can be taken as the basis to form a new policy etc. So which steps would you propose? Shaping and refining the proposal could be one of these... If you wish to refine your proposal, I'm not going to stop you :-) And it would certainly make it easier to do a proper evaluation of it. I think I still need some more input here about what exactly should be improved. Certainly better definition of the various levels is needed...Shall we propose also an example for an extended Mozilla CA policy? This would be certainly interesting and a basis for some very serious thoughts and discussions..?! -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
Gervase Markham wrote: Oh, and I'm sure we're taking patches for DNSSec support in Firefox. Aren't we? This however would be a very good idea! -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Registerfly
Gervase Markham wrote: You mean, you are not happy anymore about Geotrust/Comodo business? Regfly has no connection to Mozilla whatsoever... Indeed not. Well, what I meant is, that Regfly has not direct responsibility to Mozilla. They are not a CA root, therefore the parent CA is responsible for it I guess it depends how their business operates. If they just get details from applicants and pass them on to Geotrust and Comodo for verification, then we don't have a problem. However, if Registerfly are responsible for verifying part or all of the data, there is an increased risk that erroneous certificates could be issued. Right! I asked previously, if you suspect if certificates were issued fraudulent or if verifications were not performed...If they were operating as an intermediate CA (compared to simple reseller), than there indeed might be an increased risk, however the parent CA still has the overall responsibility and you perhaps should discuss this issue with them. A good check would be, if CRLs are still updated and revocations still performed...I think the later might be a problem, if they ceased to function correctly (as they did with the domains). -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
Gervase Markham wrote: Eddy Nigg (StartCom Ltd.) wrote: That's right! But the audit confirms exactly that (in your example, no verification). The CA will have to mark its certificates compared to its policy which was audited accordingly. Why will they have to? Because they would like to have their certificates detected accordingly. If there is no OID, then the browser doesn't no what to do and probably mark it as the lowest level by default (Just a suggestion - it could also state, that it doesn't know the assigned level, be careful!). Who is the policeman? Gerv, please answer me this questions here, I'll wait for your answer: Ar you a policeman today? Will you be a policeman with EV? And, inevitably, there is a certain amount of judgment involved in deciding whether a particular set of practices meet a particular Mozilla level. I simply don't think, that this will be an issue at all. The levels will be defined clear and understandable. A CA will be able to judge, if he does A, B, C for level X, if not he goes down one level and checks if he does A and B etcCAs are not idiotsthey can handle that... Who arbitrates when there's a dispute? Who arbitrates when there's a dispute today? And I've pointed out several times that this URL is factually inaccurate, and bad reporting. Not in respect to the expected percentage of EV certificates. Verisign never disputed this, but other parts of this interview Actually, I'm afraid I might have to quibble even over your attempt to find common ground. :-( Well, I think there is quite some common ground here. I don't need to find it, it is heremaybe because it is the right thing to do? EV is indeed an attempt to strengthen identity verification. Which is a nice thing, really! A very noble goal, however thorough identity validation exist already. It's just more of the same in a new color...(Green was suggested ;-)) His suggestion is that CAs self-classify their existing offerings into one of 4 categories. Therefore the reason I object is that it seems to me that, in the face of the new consumer-level identity spoofing threats which were not present for the first ten years of the life of SSL, _none_ of the current practices are sufficient. Huuu? new consumer-level identity spoofing threats??? LOL Gerv thinks, that EV is a new inventionPlease read a few CA policies and practices and you'll find EV all over...Class 3 validation and higher exists and current practices exist! All it needs is, that browsers know to differentiate between the various verification procedures...this is what is insufficient! Both of these are the names of banks. The organisation which obtained these potentially confusing certificates (to prove a point) didn't even have to lie to get them. I'm sure those willing to stretch the truth a bit more could achieve better results. The certificates in questions are most likely domain validated. They won't go away! That's one of the reasons for our proposal, e.g. the relying party has to know about this. Of course he should also know about other verifications (i.e. higher levels as well). You can't force them to buy green certificates and they'll continue using the low level certificates (As a matter of fact, we had to issue many domain validated certificates to financial institutions - so we have special requirements for them, they are still Class 1 labeled). The relying party has to know about it...and by repeating myself, it's our duty to make the relying party aware of the type of verification. This is what our proposal will fix! Just for your interest, I proposed a UI to take advantage of that fact a while back; I called it New Site or First Visit: http://www.gerv.net/security/phishing-browser-defences.html#new-site Which is what Ben Buksch calls SSHing the browser. So this should be implemented, it's not connected to this proposal (Ben specifically asked not to tackle this right now) absent the desire of the Mozilla Foundation to play CA Cop and spend ages evaluating the different procedures of all the CAs, all we can do is lump all existing organisationally-validated certificates into the same identity not sufficiently verified category. Bullshit...you are repeating this, even so you have received answers on this...To lump all existing into one category is what browsers have wrongfully done since they exist!!! We are going to change this! That's exactly the wrong... -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Mozilla Products Included Certificates
Gervase Markham wrote: If I am correct, then it seems that the following Firefox minor release transitions added new certs: Firefox 1.0.1 - 1.0.2 Firefox 1.5.0.9 - 1.5.0.10 Firefox 2.0.0.0 - 2.0.0.1 Gerv, I think that no new CA certificates are added within the the same release. Therefore only between major releases they are added. If you look at https://bugzilla.mozilla.org/show_bug.cgi?id=351756 you can see, that this was added before the FF2 release, meaning no changes between 2.0.0.0 and 2.0.0.1. So I think, that they were added to the 1.5.0.10 update. Nice having such a table... -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
assessments about reputation and trustworthiness! Period! They provide verification of certain facts (Domain, Email, Identity, Address, etc). Obviously very important indications, but one of the mistakes made so many times over the time is, that claims were made about trustworthiness (including today, including EV) ...and then it didn't live up to the expectations... With this is mind, a proposal that imagines 4 (or 3, or 5) levels of cert must tackle the UI question head on because, in an environment where a richer level of detail is communicated to the user, those 4 categories have to be really relevant and distinct to provide a meaningful contribution. As beltzner mentioned in his post, we can more easily talk to a user about the difference between Encrypted and Encrypted + Identity Verified than we can about the difference between Identity Verified and Identity better verified. Imagine that we found a way to clearly present to the user: + Your connection is encrypted + The site's identity has been verified + You've been here many times before + This site is trusted by (your friends | bbbonline | other vendor rating sites) + This site appears on no blacklists Doesn't Opera have something similar to this (called Security Information window)? However I think, that the SSL stuff and the other indicators should be separated in some way, specially since the later apply to plain http as well (and are perhaps much more important in that respect, because of the missing indications of identity verification). Identity is a piece of online safety, but it isn't all of it, so my goal in these discussions and others like them, is to arrive at an answer for what the identity piece looks like, without losing sight of the fact that it is only one piece of context. Amen! I don't think we as an organization are tied to EV and EV alone. Rightagain EV is part of SSL (and not the other way around). This type of verification isn't new at all...and tomorrow there will be PVC and CFF too... Our goal is to create a safer environment for our users and when we can't protect them actively (e.g. aggresive anti-phishing warnings) we want to at least enable them to make good decisions. The acid test for me, for any proposed standard like this, is whether it will help users do that more successfully. I couldn't say it better... (So most likely Gerv and me will disagree on what exactly will help the user) ;-) Now some practical questions: Which process do you propose now? What should be done after what? Are you going to make suggestions and put forward ideas concerning the UI. Or do you expect [some of] us to come forward with them? Can this list continue to work on the proposal (and perhaps eventual extension of the Mozilla CA policy)? Should the UI wait for the framework? Do the proposals (ours, EV) depend on the UI proposal? Or should they be implemented without relation? -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
[EMAIL PROTECTED] wrote: They are a Geotrust reseller, but also have issued hundreds of ssl from their own FlySSL CA: http://www.registerfly.com/ssl/ It's irrelevant! There is no FlySSL in the Mozilla certificate store. -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
Gervase Markham wrote: On what basis would you mark a level 2 certificate as safe? How can a user make such a decision safely? Gerv, I think you are concentrating too much on what Level 2 means, instead of trying to see the whole picture first and which problem the proposal tries to solve. But here a few thoughts about Level 2, since you are insisting on it. First a few facts: - This type of certification is the most common after domain validated. Anything higher than domain validated should be encouraged if 1.) It is used *beyond* low-risk private and public sites, such as web mail, forums and blogs. 2.) It is understood the correct way and doesn't claim to be more than it is. - EV will not be the replacement of anything higher than domain validated. According to estimates from various sources (including Verisign), EV will be used for between 1000 and 4000 sites, or about *one percent or less *of all issued certificates today. This I call too much trouble, which leaves SSL in browsers still utterly broken. We are talking here about the other 99%!! Now, it really depends what you can do with this second Level. And it is a decision which depends on the user mostly. However the user must receive the correct indications and/or information to make a decision, which he today most likely can't. Supposed one receives this information about Level 2, than: If you give your credit card to a taxi driver to pay your fare, than I suggest that Level 2 is sufficient. If you give your credit card to some Restaurant on a business trip, than it's sufficient. Purchases through the Internet have their own rules and are treated differently than a purchase made in person and with a signed statement. This is a very important fact! But I would not make a transfer of 10,000 US$ by Western Union to somebody, *only* on the basis of Level 2 client certificate presented to me. I would make additional research prior to that. I would not give away unnecessary private information based on Level 2. However I wouldn't do that with any higher level either. Certification is about Identity validation and one shouldn't forget that. No level, including EV, does promise you safeguard of your private information or prevent misuse of your credit card details. And in that respect I need to receive proper information about verifications performed. I also need to understand, that SSL is *only* about identity validation. The proposal tries to provide a structure and framework of levels in order to have better definition about these verifications - first and foremost at the browser policy level! The rest about this comes in the next mail -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
Gervase Markham wrote: Except that it would be an enormous amount of effort. There are 44 CAs currently in Firefox, and 20 more in the queue. So? Each may have between one and ten different products. That's why we propose the Mozilla CA policy defines this structure and provide a framework of different levels. All these products would need to be allocated levels, Mozilla doesn't need to do that. The CA will assign its various procedures to the appropriate level. and the CAs would need to change their issuing systems No! But if a CA wishes to make adjustments to better match this levels, than it is free to do so. It's not a condition so. to add the new OIDs. Yes, this is the only requirement really. Technically this is not really a problem. If there is no such OID it will be treated according to the lowest level (or no level?). And, as I believe I'm going to get to further down the thread, there is no auditing to make sure the CA was honest in terms of doing the correct amount of verification anyway. Sorry? Gerv, please open a bug at bugzilla with the request to remove all CA certificate from the NSS certificate store on the grounds, that there is no auditing to make sure the CA was honest in terms of doing the correct amount of verification. Eddy's proposal is anything but not too much trouble. I don't understand where the trouble is really? Perhaps you explain? But EV is backed up by audit. Eddy's proposal is not. Utter nonsense! All CAs get audited according to their policies and practices. The proposal is about defining SSL certificates in browsers at last. A step long overdue. Auditing is covered by completely different parts of the Mozilla CA policy. If you feel that it has to be improved, perhaps make your suggestions. But the proposal has very little to do with it! I think the webtrusty audit includes adhering to their own standards. And the standards for each level for each CA are public. Except that analysing and classifying all those products from all those CAs, and keeping up with changes, is a Herculean job. It is not something Mozilla has to do. The CA does. The CA retains responsibility and liability concerning correct assignment of its issuance processes, the very same way CAs has to keep up with its promises anyway concerning its verification and issuance procedures. Or are you going to take over from now on the responsibility and liability? -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
Hi Mister Charter77, It would be nice, if you would post as a person and not as an email address... [EMAIL PROTECTED] wrote: The project you propose is monumental in terms of 1) categorizing the hundreds of certificate classes offered by the dozens of CAs, and Again no! It was explained various times by now, that the Mozilla CA policy will provide the framework of four levels (according to the proposal) and the CAs will match their verification procedures to the appropriate level. It doesn't matter how many classes and levels a CA provides, it will have to define which of them matches which level. Nothing more to do here! 2) auditing compliance with the new tiers. Again no! There is nothing new here in that respect. The Mozilla CA policy will not define/change CA policies and practices. No new audits are needed. Nothing will change in this respect. As you indicated, there are many different levels of verifications performed at CAs, just the browsers don't know what to do with it, because of the lack of proper definition. This is what it's all about. It could also take up to three years to bring the new classification system online, assuming CAs would only issue certificates with the new OIDs upon renewals. CAs issuing certificates with longer validity than one year are anyway acting irresponsible! Or can anyone guaranty that during the course of one or more years, the subscriber: - Didn't changed its name? - Changed its address? - Did renew its domain name? ** Ouch, to put it mildly. Ouch for the CA issuing certificates for three yearseat your hat! ** Just imagine, you have a certificate valid for three years and owned a fairly popular domain name. You simply don't renew the domain name and another party picks the name. Now you have a completely valid certificate for a domain name which doesn't belong to you anymore. How's that?! -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
obviously, but I think it has to be done in some way. -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
Hi Mister Charter77, [EMAIL PROTECTED] wrote: Currently the UI is the same for all SSL, no matter the quality. You are proposing to use the UI to differentiate between grades of SSL ... Fist of all the proposal tries to structure and define SSL certificates in the Mozilla CA policy first and foremost, about something which is common practice. It nowhere says how, if and when the UI should differentiate. then you better be sure the cert quality matches up to the UI representation. If Moz is saying this cert is X then Moz needs to be sure it really is X. I think, this is certainly worth to think about! First of all, I suggest that Mozilla shouldn't say anything as its own opinion - this from a legal point of view. However I do suggest, that the browser _presents the information of the CA as that of the issuer of the certificate_. There is a difference between the two! Certainly Mozilla shouldn't suggest that a certificate is this or that safe, but provide an indication about the claims of the CA. This will be certainly an interesting challenge anyway - which is also true for the EV proposal. You can't leave the grading or the compliance up to the CAs. I think it should. Because Mozilla doesn't have any control over it in any case! Not today, not with EV and not with this proposal! Compliance is not something Mozilla controls! Never! (Except in case Mozilla starts and operates its own CA) By letting the CA assign the level and comply to the proposed Mozilla policy extension, the CA retains full responsibility and is liable for its promises. Assigning a certificate to a certain level is a promise to the relying parties, the very same way, it has defined the policy and practices of the CA which is the legal framework between all parties involved. It remains the same promise, just with the addition, that it assigned an OID and appropriate level to its certificates according. The promise, responsibility and liability is that of the CA always! Therefore I'm asking, why should Mozilla take over the promise, responsibility and liability of the CA, by making sure anything of it? Let the CA decide its promise to Mozilla, the subscriber and relying party and let the CA retain all responsibilities. Mozilla only provides an interface for the promises. Hope this makes sense! -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
Hi Ben, Ben Bucksch wrote: Actually, not even that is necessary. Classes each have their own root cert, so we can simply match root certs to level in our software, using a list that is just as hardcoded as our root certs, and matches the assigned levels. So your idea might be a good one, I'm afraid there are some problems with this. Let me explain: In this case, an extra effort would have to be invested into doing this. This is something Gerv correctly prefers to avoid. Of course it could be possible, provided there is enough manpower for it. But there is another problem... As you might know, the Mozilla CA policy encourages to use separate root certificates *or* separate intermediate certificates under a single root for the issuance of certificates (see http://www.mozilla.org/projects/security/certs/policy/ section 13). Personally I think, all CAs should use intermediate CA certificates for the signing and leave the root certificate completely protected and off-line! But this also means, that the intermediate CA certificates are not stored in the NSS certificate store and are changed/renewed rather frequently compared to the CA root (In our case for example the intermediate certificates have a life-time of 5 years and are changed every four years (leaving the last year for validity of the already issued certificates and for revocation). Therefore it would be difficult to hard code anything here. Now, the phrase Class 3 or similar is not a defined standard and every CA handles that differently - if at all. It would be very difficult to fetch such a phrase on the fly and make the right assignment. This is the reason why we came up with the OID stuff, since currently there is no unified standard or policy anywhere (the core of the problem we are trying to solve here?). The proposed OID could be added by the CA almost over night and code implemented at the NSS library for its detection as well in a short time. More than that, there might be some CAs, which labeled their CA as Class 3, but issue domain validated or trial certificates from this root. To make matters worse, some CAs issue all certificates from the same root, for all kinds of verification levels. (Something which should be discouraged strongly. The proposal will help with this.) And at last, I indicated in a previous mail, that it would be most likely healthier for Mozilla to let the CA make this assignments. In this way, the responsibility remains with the CA and Mozilla doesn't make this decision, instead of or for the CA. Legal advice could be certainly helpful in order to support my logic here In fact, if I wanted to do that in Beonex, I could implement Eddy's proposal plus UI all in JavaScript. I simply match the root cert name or ID with a hardcoded list, and if it's VeriSign's Class 3 or StartCom's Class 3, I show the realname and address in the UI, because I know they check these properly, and otherwise I won't do anything special. Just as example. If the OID detections for the UI would be possible in Javascript I don't know. -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
Hi Gerv, Gervase Markham wrote: Just to be clear: this is, at heart, a UI proposal, isn't it? You want the UI to differentiate between these four levels, rather than just the one level (as now) or two levels (as IE 7 does with EV)? Before you can do anything with the UI, there needs to be an underlying framework and policy defining it. In this proposal it's actually more than that, it's a re-definition (or definition which exists mostly in practice at CAs, but not at the software) of how SSL certificates should be treated from now on. Once this is part of the Mozilla CA policy (and hopefully other vendors might follow the lead) an eventual UI proposal could be worked out. The UI can take many colors and shapes, but without the underlying framework no UI can do much...Please note, this is not about code, but about policy shaping... The Mozilla Corporation has just hired Jonathan Nightingale from IBM to work specifically on security UI for Firefox 3. I'm sure he will take your proposal on board. Perhaps, but we need to work out the definition for it first. I'm sure Jonathan will agree with mein short, we have some work to do prior to that ;-) I'm sorry, but I can't work it out - what does the abbreviation resp. stand for? It stands for respective. You explain the levels well in terms of the validation performed. However, as this is at heart a UI proposal, how do you suggest (in terms of concepts, rather than in terms of pixels) these levels should be presented to the user? No idea yet...and as it was suggested previously, that there are some smart people on board for this, however once we get to it, I'll make my recommendations...trust me on that one ;-) For example, my mother is considering using her credit card at a shop, and the UI indicates (in some way) that it is level 2 secured. Should she shop there? I've visited a site that I think is my bank, and it has a level 4 certificate. Should I be concerned, given that level 4 is normally for individuals? How concerned? As I indicated in the proposal, this is something we will have to work on and define exactly what we want. In my opinion Class 4 should be for individuals and client certificates only. However you might want to work out a similar definition for server certificates as well? Why four levels, rather than six? Or two? Or ten? Good question! The current proposal has been more or less common practice at many CAs (including Verisign and StartCom) and I view it as an almost de facto standard. By choosing a definition which is common and easy to adjust if needed by the CA, we can guaranty a speedy adoption at CAs. However a CA can at any time match its issuing processes with that of the proposed Mozilla CA policy extension and assign the relevant level to its certificates. Except that, I think that two levels is not enough, specially as the second level is expected to be for a small minority of subscribers, as in the case of EV, this is currently for registered organizations, server certificates only. The identity is validated by various means, such as verification of the identity via scanned, photocopied or photographed photo ID documents (passport, identity card, driving license) and company registry, which is then further verified by a lookup at a third party source, such as phone directories and phone call or sending of a registered mail to the address found in the documents provided by the subscriber. This kind of verification is not done in person. Ownership of the domain name, resp. email account is performed according to Level 1. The certificate must state the subscriber name/organization name, locality, state (where applicable) and country. So for individuals, the certificate contains address information which is unverified? Who said that it's unverified? Perhaps read it again? Or I might have been not clear enough here? How does your proposal ensure that the CAs stick to what they have promised - i.e. that the OID they put in the certificates corresponds to the level of validation done? Do we just have to trust them? Actually yes. In my proposal this is exactly the case, the same as today Mozilla trusts the CAs, that they adhere to the Mozilla Ca policy, which defines in that respect also a minimum level of verifications for example (confirmed by a third part audit). You might argue that this is not enough and come up with a alternative proposal concerning that. However we were thinking about it too and came to the conclusion that this might be the right thing to do. Cheers! -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
Eddy Nigg (StartCom Ltd.) wrote: I'm sorry, but I can't work it out - what does the abbreviation resp. stand for? It stands for respective. Ouuups, it stand for Respectively of course... -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Proposal for Mozilla CA policy extension
card, driving license) and company registry, which is then further verified by a lookup at a third party source, such as phone directories and phone call or sending of a registered mail to the address found in the documents provided by the subscriber. This kind of verification is not done in person. Ownership of the domain name, resp. email account is performed according to Level 1. The certificate must state the subscriber name/organization name, locality, state (where applicable) and country. Level 3: Additional verifications are performed at this level in relation to Level 2, specially verification of the provided (authentic) documents by the subscriber, establishment of the organization (minimum years of existents), physical address of the organization and proof of ownership of the domain name, resp. email address. The subscriber is verified in person by an agent of the CA or other third party. The proposed EV certificates would most likely fall under this level. The certificate must state the subscriber name/organization name, locality, state (where applicable) and country. Level 4: Verification of the subscriber is performed in person including all original documents. The certificate includes government issued passport or identity card number in the OU field, in addition to subscriber name, address, locality, state (where applicable) and country. This level is less suited for organizations, but mostly for individuals. *Implementation:* The Mozilla CA policy will be extended to include the above described definitions. Levels can be assigned by the CA within the subscriber certificate with a specially defined OID by using for example the Mozilla OID space. In this proposal we suggest to leave the definition of levels to the CA, as in any case the CA defines its verification procedures in its own policies. Implementation could be fast in this case and CAs could be advised to assign the corresponding OID to their certificates. For example the OID for a certain level could be: 1.3.6.1.4.1.13769.pki.mozilla_policy_version.level The Mozilla software can search for this OID in the certificate and accordingly provide different information to the user and handle UI behavior. A different way of implementation could be the inclusion of such an OID at the intermediate CA certificate level, which would perhaps result in easier tracking between the CA policy and assigned level. It might be easier to verify the claims made by the CA concerning the level it assigns to the various intermediate certificates. This would be more difficult in case the OID would be only included in the subscriber certificate. However implementation might be slower in this case as intermediate CA certificates are usually valid for up to ten years. *Summary:* This proposal provides a solution for the long overdue binary flat system of the padlock in browsers for SSL certificates, without special and unnecessary requirements on the parties involved. - Its adoption can be promoted and implemented very fast by both the browsers and the various CAs. - It supports any current CA policy of all CAs in the NSS cert store. - Any future standard - including EV - can be simply included within the proposed structure of levels without the need to make any special adjustments to the software. - The liability of Mozilla will be similar to the current system, because the responsibility of assigning and implementation of the different level lies with the CA. However the relying party might - pending implementations of the UI - will receive better information in order to make a fair judgment, without the browser vendor making a decision on behalf of or instead of the relying party. - Additionally all definitions in this proposal are subject to the Mozilla CA policy and under full control of Mozilla. No special bindings to interest groups (such as EV) exists and the Mozilla CA policy is open to the public for review and is free to be implemented by any CA wishing to conform to this policy. Please note, that this proposal doesn't provide any suggestions concerning the UI, but only provides an underlying framework for CAs and the browser/mail client as a first strategic step. Any UI implementation can be build according to this framework however and we suggest its implementation afterwards. The proposal is also available as a PDF document at http://apache-2.startcom.org/moz-pki-proposal.pdf -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Study questions EV certs effectiveness?
Boris Zbarsky wrote: No. The URL is in the address bar. That's not the same thing: http://[EMAIL PROTECTED]/login/foo?value=reallylongthingbecauseICan vs EVIL.COM Not that that would necessarily help with www.citibank.com.evil.com, mind you. ;) OK, got you -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Flowchart covering SSL checks, error states, dialogs
Gervase Markham wrote: Really? Perhaps you could suggest it, if it's so easy. No problem! We'd be glad to provide a workable and effective solution, should any web site operator contact us and request it. However I doubt that we are that much smarter than the developers of their sites People thought that having the site display an image the user had to recognise was one way - but a recent study shows that this doesn't work either. No, this is absolutely not what I meant, wrong way... I'm sure site operators are trying to find ways to improve security as well, but they are having great difficulty, just as we are. I don't believe that...But as I indicated previously, the solution is not in *your* hands, but in *theirs*. You build a browser, not web sites and the security and authorization procedures of them. The browser already provides all necessary primitives as you called it...There is nothing else to do for you, except what you already provide, period! -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV guidelines
Gervase Markham wrote: I don't really agree with you, I'm afraid. :-) We should not display this information for non-EV certificates You continue with the mistake to withheld *INFORMATION*. This exactly why users today have no clue about SSL enabled sites whatsoever! The lack of accessible information produced a lack of knowledge! This is one of the most important problems today in relation to digital certification and the browser! I think it's a good idea not because IE does it (Opera does it as well) Just for your knowledge, but Opera provides this information at *all* levels for *all* certificates the same (as a browser is supposed to do)! They might paint the address bar green or whatever for EV at some point, but they do their job excellent! When using the Opera browser on a secured site, the address bar areas gets filled with the organization name, there is a tool tip and a one click action opening a window with the most important information. Within this window there are even more options...just look at it! I do have something like this in mind when talking about improving the UI in relation to digital certification, just a little bit better...but since I promised to shut up and wait for the UI team to put a proposal forward...I shut up now ;-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Study questions EV certs effectiveness?
Hi Ben, Ben Bucksch wrote: ...So it's not the CA not offering thorough validations, but the subscriber not willing to pay for it! True. Good comment. Thank you ;-) More than that, current anti-pishing functions now found in most browsers and mail clients are much better in preventing pishing attacks! I think, that on this forum most agree with the fact, that EV is not going to be effective nor the front line of defense against pishing I disagree. I think that anti-phishing blacklists are a band-aid. Yes, I believe that too! But currently they are still better in preventing mistakes made by users ,which pishing is all about...It's not, that the site in question doesn't have a valid certificate, it's the user following to the wrong site...The same user will not care too much about the color of the address bar either...Therefore the current band-aids are not the best one could hope for, but pretty effective right now... I think the most effective anti-phishing measures are: * Bookmarks Education, education, education ;-) * Clearly showing domain (and *only* domain) and maybe real world owner (from cert) Already suggested this and moreGeneral in agreement with you, so I'm not sure if the domain name itself is the most important thing, because the domain is in the address bar already and if that's not the correct domain, than the browser already barks... -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Flowchart covering SSL checks, error states, dialogs
Hi Dan, Dan Veditz wrote: It's certainly not going to be a green bar, but if we can come up with something decent isn't it worth being able to tell the difference between we know these identities were validated to a certain standard vs. these identities may or may not have been validated to that standard? My question to your suggestion is, if we can't come up with something, that would tell the user _any_ difference between _any_ certificate. Which means, to display the user the most important information in a convenient way, which could be perhaps the subject line and issuer. Also it should contain additional information, such as perhaps the key size and encryption algorithm used for the connection, if the page contains unsecured content, if the CRL was checked and if the issuer is known (e.g. trusted). EV validation could be one of those details as well... Another question remains, what happens if tomorrow a different forum invents a different standard? Are you going to support it? If not, why not? And at last, to what extent the Mozilla Foundation should endorse and follow the recommendations of what is basically an industry trade group for commercial CAs? Since the CA/Browser forum is a closed forum, which doesn't even allow membership to non-commercial or lesser established CAs, makes it highly suspicious of its real goals! Openness is key for the success of it and certainly something Mozilla should strife for! Thank you for your time! -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV guidelines
Hi Gerv, You are continually damaging your credibility in this discussion Thank you for taking care of my creditability! I can state with certainty that Verisign did not write most of the EV guidelines. Right, to all _my knowledge_ it was mostly drawn up by Kelvin Yiu of Microsoft. However nobody can explain the relationship between Kelvin and other CAs including Verisign or any business relationship or interest between Microsoft and Verisign which might exist. In itself maybe not a problem, weren't we talking about the two biggest interest groups in the EV forum! And I remain highly suspicious on the intend of the whole thing after all...Why wasn't it drawn up by somebody *known* not to have any financial and other hidden interests? That just isn't true. Section 8 a) of the EV Certificate Guidelines gives the maximum validity period as 27 months. It recommends 12, but that is only a recommendation. Yes, somebody pointed this out already...But this shows perhaps again, that recommendations are pretty useless and perhaps only the must and required language should be used and everything else omitted. This makes it perhaps easier to read, but now we might comb through the guidelines and find all the recommendations and see with what we are really left! Except that they haven't been approved yet. The audit criteria are up on the cabforum.org website; all you need is a suitable auditor willing to audit you. Given that several CAs are offering EV certs now, they must have had the audits done. Therefore your assertion is clearly wrong. Don't you think, that the statements above contradict each other? You are saying that the EV guidelines are not approved yet by the forum and are still a draft, but audits are undertaken and certificates issued already!? Now the creditability of whom is here at stake? I assumed, that if certificates are issued already, the guidelines must have been approved and audits already performed. This however doesn't seem to be the case...and what happens if the guidelines still change? Re-audit? Revoke and re-issue all certificates? In short, perhaps this is not the proper way of implementation... Eddy, if we are destined to forever disagree on this, so be it. But I can tell you for absolute certain that we are _not_ going to put Firefox users in a position of having to know and evaluate the relative trustworthiness of (or practices of) 50 different CAs, and the relative strengths of different encryption algorithms and key sizes, in order to work out whether a particular site is (relatively) safe to do business with. This is not what I suggested! Again, what I suggested is to provide basic information about the certificate to the user in a most convenient way (such as mouseover and/or one-click action) should the user be interested in it. Additionally by making the padlock area more prominent , by displaying the organization name, locality and country and some highlight color perhaps, it would draw the attention of the user to it. In this way the browser might help the user provide the important information better Throw all the information at the user and let them make up their own mind is not going to be our UI strategy. Actually, it has been your strategy since the existence of Mozilla, minus the throwing of information at the user. Currently the casual user has not much else to do than making up their mind - without much information. My intention is, to improve that a bit...But you suggest still, that the user can't make a decisions whatsoever and can't read basic details of a SSL/TLS secured web site. You also insist in keeping it this way, by providing a distinctive color for EV and nothing else! No improvement of other shortcomings! It also seems to me, that whatever argument critical, negative or not in favor of EV made by a participant on this list, is simply rejected by you! So we might never agree with each other in that respect, but please let me explain to others what I think would be the best for the Mozilla browser. I believe that others are actually listening -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Study questions EV certs effectiveness?
Hi Dan, Dan Veditz wrote: Yes, they could but the presentation in the browser is exactly the same whether they do or don't. Why would they bother doing it the hard way? More and more CA's are apparently asking themselves that question. Well no! CA's did in the past and today offer thorough identity verification (personal and organizations alike), but it's the _subscriber_ who is making the decision here. This is also true for EV certification and nothing will change in that respect! A rare minority would buy EV, without the green incentive...So it's not the CA not offering thorough validations, but the subscriber not willing to pay for it! And obviously EV will not prevent pishing of the big web sites, for various reasons. First because pishing sites mostly don't use SSL to start with, second the green address bar has also its drawbacks...which will resolve in the same way as the padlock! We aren't living in a perfect world and user education is a major problem! More than that, current anti-pishing functions now found in most browsers and mail clients are much better in preventing pishing attacks! I think, that on this forum most agree with the fact, that EV is not going to be effective nor the front line of defense against pishing Additional thoughts are, that nobody should blindly follow through on a purchase or sharing of sensitive data without coming to a conscious decision - even if EV validated or similar. Because validation of the identity doesn't guaranty to anybody, that this entity will deliver the goods and not misuse your information! Suing somebody in court isn't fun either and doesn't guaranty, that this entity can pay for the damage... I don't really care about helping CA's sell more expensive certs, but I do want them to do more validation with an explicit standard we can hold them to. That in itself would be a good thing, however the whole thing is once again dictated by Verisign and Microsoft. There wasn't an open process as far as I'm concerned, and it's really about getting the CA business back on track! If we can offer a usable and effective UI differentiator for EV certs maybe we and the CA's can both get what we want (big if). Threatening to turn off EV-ness of a CA's root cert for non-compliance with the standard is a more credible threat than yanking the root from the browser and frustrating millions of users. Yes maybe...so no CA does ever guaranty support of their CA certificate in browsers to the subscriber...So perhaps any such CA will have problems selling more of the same, the ones which get burned the most are the subscribers under such a scenario! And I'm not talking about eBaythey can afford it... But how fast can a browser vendor remove support of EV of a certain CA? Instantly? If not, millions of relying parties might be at risk? But now thinking about eBay again: What happens to such a site, if they educate their users to look for the green address bar and then of a sudden it turns white or yellow...Can you imagine the possible damage due to lost purchases and the confusion? I don't believe that any browser vendor has the guts to remove EV support from one of the big five CA's from their browsers, not talking about removing their CA root! And because neither Mozilla nor any other browser vendor would do this - it remains a hollow phrase without meaning and teeth... -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV guidelines
Florian Weimer wrote: They don't, as far as I can tell. Evidence provided by a Qualified Indepedent Information Source (QIIS) is usually sufficent. Verisign seems to have copied this part of the guidelines verbatim. Guess whatthey wrote most of the guidelines by themselves! Now the interesting question is how much wiggle room there is in the definition of a QIIS. Looks like a lot to me, and I wouldn't be surprised if anyone had problems to say with certainty if certain WHOIS operators can serve as a QIIS. Certain is goodhasn't Verisign its own domain registry department? Conflict of interest? Is the current certificate on https://www.verisign.com/ an EV certificate? It lacks a physical address, which is required by (my reading of) the guidelines. Good catch! More than that, it was signed and issued long before the EV guidelines were approved (How could they know what the guidelines will be?). And even more disturbing is the fact, that the certificate is valid for a period of _two_ years, whereas the guidelines speak strictly about _ONE_ year only And now to all the EV supporters: Isn't EV already flawed by the biggest certification authority? -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Applicability of SSL / use-cases
Ben Bucksch wrote: If the above is accepted, it would need subtle UI changes, maybe small changes to NSS, maybe changes to the SSL PKI model (removal of expiry, keep only revocation). Well, I guess this discussion is somewhat pointless and your views about SSL are certainly unique. Also one browser vendor can't force such a change onto the PKI model, I guess. However there is one thing I'd like to answer: Currently Mozilla software doesn't enforce CRL or OCSP checking and by default both are _OFF_! You can't turn expiry on or off and therefore a issued certificate, once it expires, issues a warning. Obviously there is a good reason why certificates expire (except the ones valid for ten years as some get sold today), because validation performed of a domain may very likely be not valid within a short time...domain names change ownership and people change names and addresses. Therefore a CA would have to revoke almost all certificates within a short period of time (lets say one year), if the party isn't interested in renewing it. This would make CRL's balloon to huge sizes, which in turn would slow down traffic enormously! Imagine when connecting to an SSL enabled web site your browser has to download a CRL of a few megabytes and even beyond. -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV guidelines
Hi Gerv, Gervase Markham wrote: Just to be clear: They are not _intended_ to cost $1000/year upwards; But which I predicted a while ago...As suggested previously, this is mostly a marketing ploy, since the EV procedures can be performed with or without a CA/Browser forum. I guess, the prices will rather go up, if Mozilla goes along with the green carrot... I don't think any information source would confirm that your address belonged to eBay. The procedures suggested by the EV guidelines are, if implemented and performed correctly, pretty safe...Obviously verification of the address and phone number by third party sources is only one of the steps suggested. As for example with StartCom Class 2 certificates (so called reasonable verification), it doesn't matter which phone number the subscriber provides (that's just a convenience), but for verification purpose only third party sources are considered and checked, together with other material about the entity...I don't think, that this is an issue and there is no loophole... This whole thing has lots of loopholes. Given the experience and market pressures, we have to assume that the CAs use the absolute minimum and cheapest standards that still pass the guidelines, and they'll automate as much as possible. That's of course another story... So if, for example, someone gets an EV cert and uses it for phishing, we can analyse how they did it and tighten up the guidelines to close the loophole. With the previous, different-with-every-CA, ad-hoc procedures, that sort of thing wouldn't have been possible. If this forum wouldn't have been a monopolistic organization, this would have been even positive...But then again, I would like to see these various CA's promote the EV standard without the green address barGuess what: They'd disappear faster than you can see... it says $2000 per Subscriber or Relying Party per EV Certificate. This means that if ten people are ripped off, they can claim $2000 each. Well, there must be a distinction between subscriber and RP. It can't be bothPer subscriber it's 2K, per RP it can be hundreds of 2K! So as it currently states, the CA can choose whatever interpretation it prefers...Make your own conclusion... One draft of a precursor document to the EV guidelines included a requirement for a site visit, and that you had to meet up with the applicant and take a photo of them with their government issued ID, and record the number thereon. I still think this was a great idea, but unfortunately I was not in a majority. Huuu? Got this dropped? It used to be in the guidelines!? Well, if this is the case, then it's not even worth considering the EV certs anything else than Class 2. The site visit was also the major expense for the CA I predictedIf this is not a requirement anymore, then I can't help and ask, why should EV certs be better then lets say any other reasonable verified certificate? Really? There's no way any CA could make money doing this at $100 a cert. In the US, there are networks of companies which will do site visits and this sort of verification for you, but in other countries, there aren't. Such a visit would cost several hundred dollars to have performed. Oh...here is the site visit again...There is something I'm missing here... -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV guidelines
Ben Bucksch wrote: How about reading the guidelines? I did read it! Thorough and multiple times...trust me on that one... They are public now. You work at a CA, don't you think it would be helpful? You even protest that you cannot participate in CABForum, but didn't read what it's about? Since the guideline is not an entertaining news item of 10 lines, I can't read it every here and now...So I reacted on information posted by others and on the information which was none to me up to that moment. FYI, the guidelines often have many *alternatives* for each verification step. Yes! And perhaps here are the hidden aspects you and others see a problem with it. Obviously, if a CA intends to implement and perform according to the spirit and guidance of the EV guidelines, then the verifications to be performed are effective! However as somebody (you?) pointed out, it might be likely to automate and circumvent certain aspects, specially the more expensive ones...Or as you call it: Alternatives...Perhaps one just has to learn the alternatives better ;-) But what I wanted to show was, that at one point there is a site visit (and photo opportunity of the subscriber and company estate) and then of sudden there is none...Confusing, isn't it? -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Study questions EV certs effectiveness?
Hi Mike, beltzner wrote: Being able to talk about validated identity is indeed quite interesting, but advertising get the green bar[1], go green[2] or telling users that they are safe when they see a green URL bar all cause concern in my mind. I'm glad to hear that! In a previous thread I made the suggestion and a proposal, instead of colored address bars, to provide to the user with much needed information in an easier way than today, mainly: - Mouse over the padlock should display basic information found in the subject line. - Click on the padlock should open the Certificate Viewer. Today the situation is, that in order to get a clue about important details of the issued certificate one has to: Right Click on the page - View Page Info - Select Security Tab - Click Viewin order to receive this information. This is not efficient and most casual users can't / don't know how to get there and what to expect! As mentioned in the earlier thread I suggest to improve the UI in such a way to give the user an easy way to make a judgment about the site. Obviously most CA's bother to include valuable information in the subject line concerning the level and type of the verification of the identity. BTW, when clicking on Thunderbird on the lock/signature I receive the Certificate Viewerwhy in Firefox this isn't the same behavior, is mysterious ;-) And at last, it is obvious that the EV forum is a business plan and I certainly hope, that Mozilla doesn't lend a hand to it, specially since - despite the claim made at the CA-Browser Forum - this is a closed forum and organization! Until and once this has been corrected by this forum - of which Mozilla is part of after all!!! - I suggest not to provide the incentive of a green or whatever address bar! As for the future, I'm not sure that dev.security is the right place for discussions of the UI. It's the right place for discussions of the EV specification, for discussion of our plans to be able to detect, parse and make EV metadata available, but the front end design of how we surface that information is, IMO, a topic for dev.apps.firefox or dev.apps.whateverAppBuiltOnMozillaThatsUsingEV :) Could you pop in a line at dev-security, once a discussion has started in one of the relevant mailing lists, so we could join that effort as well? Thanks! [1]: VeriSign uses this slogan [2]: GlobalSign (http://www.globalsign.com/images/extended-validation-ssl.gif) -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Study questions EV certs effectiveness?
Hi Boris, Boris Zbarsky wrote: Mousing over the padlock currently shows a tooltip that says Authenticated by where is the O field of the certificate issuer. I agree that we could show better stuff here. The question is what to show. Right! I think the Authenticated by is not the most important perhaps (And I'm saying it and run a CA ;-)). I like the approach Opera took for example, with showing to whom the certificate is issued in the address bar and a click on it brings a window with all important details about the holder and the issuer of the certificate. Certainly worth looking into a similar option for FF. In Seamonkey, clicking on the padlock opens the security tab in page info. In Firefox, double-clicking on the padlock does the same. Yes, actually you are right! Perhaps I'm just used to previous FF versions? Don't know... Actually, in Firefox, Double-click on the lock, click View. But yes, clearly not so discoverable (e.g. you didn't find it). Also yes...I guess, that opening the Certificate Viewer instead would be a minor investment with the greatest effect. If the UI people can agree on this we could open a bug perhaps... They wouldn't know to click on the lock icon either, frankly... Maybe :-) So a prominent section in the address bar dedicated to the lock and additional information if the page is secured, would attract more attention than currently. I think the combination of both steps would bring an improvement to FF. -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Study questions EV certs effectiveness?
Gervase Markham wrote: But (and I feel like a broken record) Me too ;-) we should only display this information if there's some chance it'll be correct. No, a decent browser should provide the information of the certificate in an easy way! Withholding valuable information isn't perhaps the job of a browser? And we're back into the how good are current organisational vetting procedures? question which EV is supposed to deal with. But also back and again...EV is a business plan! It has nothing to do with the supposed verification procedures, because the procedures existed in similar forms already...any CA is free to pick these procedures as their own and start issuing certificates accordingly today! But it's truly the problem about how to market and sell them! It was obvious a while ago and it's more obvious nowThis is the issue hereIt's the incentive the browser vendors have to give to the customers of the issuing CA's. Concerning the user, I think when we asked a few month ago about studies concerning the effectiveness of the green address bar, none could be provided. Now there are some negative reports... But I'm sure you'll receive swiftly a few studies paid by some CA showing how EV helps the user...ala Get the Windows Facts... In the meantime, let the various CA's do a really great job and make some real good verifications based on the EV guidelines - without the greenly incentive! -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: bugzilla.mozilla.org security group reorganisation proposal
Gervase Markham wrote: Can anyone else see disadvantages to having six security groups? That would basically be one per product for the non-end-user products: Having to subscribe to at least some 3 or 4 security groups is a pain...and higher the chance to miss on important topics...Are that many really needed? All of the topics mentioned below are important enough, but having to subscribe to all of them seems to be a punishment for me ;-) Aren't we all subscribed to too many list already? I'm trying to get the number down, not up... bugzilla-security: Bugzilla, Testopia websites-security: Websites webtools-security: Webtools addons-security: addons.mozilla.org updates-security: AUS security: Everything else -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Study questions EV certs effectiveness?
Which leads me back to one of my original proposals to actually improve the whole UI related to certification and provide an easy, but effective way to display the most important information, specially the subject line, by mouse over or one click on the pad lock! This would provide better support of ALL types of certificates, since also low assurance certificates will not disappear. But other well validated certificates are going to exist and EV certificates are only one of them. Important information is usually included within the subject line and it should be easy for user to reach this information! -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 Michael Lefevre wrote: On 2007-01-29, Gervase Markham [EMAIL PROTECTED] wrote: dolphinling wrote: The study, based on user testing, found that EV certificates don't improve users' ability to detect attacks, that the interface can be spoofed, and that training users actually decreases their ability to detect attacks. What that actually means is that the study found that the Internet Explorer EV UI (the green bar) doesn't improve users' ability to detect attacks. Indeed. But from what I've seen discussed so far though, the proposed Firefox EV UI would be similar. The picture-in-picture spoofs were highly effective - it doesn't really matter what the security UI does or looks like if it can be approximated by a web page. There was also the finding that the user training actually made people much more trusting of the spoof sites. After being told about phishing protection, people assumed that they could trust anything without a phishing warning. I don't see how that problem would be different for Firefox. smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Mozilla, Opera and co only tout open standards as it suits them
Duane wrote: you'd think the browsers with their cries of standards and openness so they don’t get locked out by Microsoft wouldn't be so quick to jump on this band wagon, but the complete opposite is true. It's also striking to read the introduction of the guidelines: The CA/Browser Forum is a voluntary _*open*_ organization of certification authorities and vendors of Internet browser software and other applications. It's about as open as Microsoft's kernel... EV certs are being touted by Microsoft as preventing phishing, but as so few phishing attacks utilise SSL at present this claim is laudable at best. With currently only 0.25 % of pishing sites using SSL certification (including self signed) as shown on this list earlier (source netcracft), this is certainly the wrong reason for EV certification...even the guidelines themselves, lists pishing only as secondary purpose... -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Opera article about EV
smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Why now? (Was: Extended Validation Certificates)
Heikki Toivonen wrote: The EV draft states auditing by WebTrust *or equivalent*. We made already a proposal for defining *equivalent*, to which there was no reply until now. Just to you inform you, that StartCom requested membership on the grounds of the following criteria as received from Tim Moses of the CA/B Forum: CA/Browser Forum members shall meet at least one of the following criteria. 1. The member organization operates a certification authority that has a current and successful WebTrust for CAs audit report (or equivalent) and that actively issues certificates to Web servers that are openly accessible from the Internet using any one of the mainstream browsers. 2. The member organization operates a certification authority that has a current and successful WebTrust for CAs audit report (or equivalent) and that actively issues certificates to subordinate CAs that, in turn, actively issue certificates to Web servers that are openly accessible from the Internet using any one of the mainstream browsers. 3. The member organization produces a software product intended for use by the general public for browsing the Web securely using SSL. Our application for membership was rejected because of their interpretation of *equivalent*, as expected! There is no *equivalent! *They obviously must be very afraid of StartCom, since this request was a bout membership, not issuance of EV certificates. It is interesting to note, that three out o four browser vendors accepted StartCom as a trustworthy certification authority (This is Mozilla and KDE, with Opera only depending on a down payment, which is a policy Opera intended to revise or are in the process of revising). Needless to say, that StartCom fulfills all the required criteria above with the word *equivalent *depending interpretation only*! * We hope, that Mozilla has the ability to change that decision taken by the CA/Browser Forum and get rid of the WebTust monopole which Microsoft and perhaps other CA's maintain. -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Why now? (Was: Extended Validation Certificates)
Hi Gervase, Gervase Markham wrote: Indeed. That's merely a statement of fact. And I'm sure removing Startcom as a CA would break some proportion of sites as well. The fact that we only have this nuclear option as a sanction is definitely a problem - and one that EV can help solve. I agree with you, that this is a problem. However the option should exist - and considered - if needed...even if it's ABC CA with 99% of market share... As I'm sure Verisign does also. Sure, however issuing a Class 3 certificate to a company or individual called CLICK YES TO CONTINUE simply shows something extremely broken. This is not a domain validated cert, but Class 3 code signing! And this didn't happen in the nineties, but just recently...I don't knowVerisign is not my business, but if somebody would have looked even once at this request, before CERTIFYING, this simply could not have happened! So much about that... So it seems we need standards for who one issues a cert to, not just how one does it. Hang on, didn't we just write some of those? Well, if you really believe, that there indeed was a company called CLICK YES TO CONTINUE, then I can't help you... :-) As suggested previously, the Mozilla CA policy would provide such alternatives. We are going round in circles here. WebTrust are writing new guidelines for auditing EV. If you want some alternative audit criteria, you need to name them specifically (if they exist already) or suggest who should write them. The Mozilla CA policy is not a set of EV audit criteria, it's a CA policy for a browser manufacturer. Sorry, perhaps I didn't made myself clear enough...The new guidelines for auditing EV by WebTrust might be just perfect, but the problem is the monopoly of authorized auditors by WebTrust. This is, where the Mozilla CA policy provides alternatives, which is from our point of view very important. Right, it's a CA related challenge...Obviously I'm looking at it, how a CA (including us) is going to comply with it...And what if there is no trustworthy agent available in that region? Quite obvious the CA must send somebody in to do this job. However this drives the costs upwards, which the client has to pay. In such a case, the client might prefer not to make the deal and the CA is going to loose business...or being very attempted to skip this requirement! I'm very skeptical about this one, because if a standard is set too high, it will be circumvented when not convenient! Simply as that... ...and the CA may well fail its audit. I'm not sure about this one! An audit is a current snapshot of the conduction of the CA business and its practices and procedures in place. It can't say anything about the Before and After. Therefore a policy and/or standard has to be realistic in order to be adhered to, otherwise as I indicated, it might be circumvented when convenientMost likely you will not know when this happens 99 % of the time...A risk a CA might take in order to make better business... Really? Are you buying anywhere without checking from whom and what you get? What are the guaranties you receive? What if you don't receive the goods? I don't think, that your argument is correct... So when you visit an SSL site to buy something, you read all the certificate contents before proceeding with the purchase? Every time? Well, personally I'm not a good example really...I'm not that objective as a manager of a CA. However it depends on the nature of the site (e-commerce or not) and indeed one should be bothered at least once with the details of subscriber. As I suggested, this should be either easy to reach and/or in a pleasant and informative manner. http://www.benedelman.org/news/020305-1.html http://www.benedelman.org/spyware/images/installers-020305.html While these are misleading, and probably undesirable, I don't think they could be called bogus. (Unless, perhaps, there isn't a company called Click Yes to Continue - but why couldn't there be?) Otherwise, all of them show the name of the company concerned. The fact that the dialog presentation sucks is an IE UI issue. Well, I meant the company called CLICK YES TO CONTINUE, not the rest -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extended Validation Certificates
Gervase Markham wrote: When Verisign issues a bogus certificate -- as it has in several cases -- Do you have a list, with references? I know about the MS code-signing certs, but no other cases. http://www.benedelman.org/news/020305-1.html http://www.benedelman.org/spyware/images/installers-020305.html -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Why now? (Was: Extended Validation Certificates)
, it's a CA related challenge...Obviously I'm looking at it, how a CA (including us) is going to comply with it...And what if there is no trustworthy agent available in that region? Quite obvious the CA must send somebody in to do this job. However this drives the costs upwards, which the client has to pay. In such a case, the client might prefer not to make the deal and the CA is going to loose business...or being very attempted to skip this requirement! I'm very skeptical about this one, because if a standard is set too high, it will be circumvented when not convenient! Simply as that... Yes! A new idea for this would be, on a first visit at an SSL enabled site to present the user with a window with important and informative details. Not a warning popup, but a friendly message, displaying the most critical information the CA has bothered to include in the certificate. Right. Straight away, you've distracted the user from their primary task (buying something) to make them read a bunch of what they see as irrelevant information. How many of these do you think it'll take for them to just start closing them without reading, and how many more for them to get really annoyed and switch to IE? It's an idea. There can be other, perhaps better suggestions as well. As proposed earlier, perhaps there need to be some work done in order to provide something better. I didn't say, this is the only solution, it might be one of them...Obviously making the user aware, that he is visiting a secured site and knows the details with whom he is going to make business is certainly not distracting the user, but quite the opposite. It's a service the browser should provide, not hide. Otherwise why should a CA bother to include this and other information, if you have to click through 5 buttons in order to get a clue about the subscriber. Because a user actually only needs this information extremely rarely - when they've got a problem with the site. Really? Are you buying anywhere without checking from whom and what you get? What are the guaranties you receive? What if you don't receive the goods? I don't think, that your argument is correct... No! Because YOU can't decide what's safe for ME and any other user. Oh, yes I can. I've decided that 56-bit keys are not safe but 128-bit are. I've decided that SSL2 is broken and shouldn't be supported. I decide a load of things. This are technical, crypto related decisions. However you seem to decide, which verification is good and which not, without taking into consideration, other, most likely valid procedures? Otherwise if this is what you are saying, I can sue YOU, if you are going to take the decision for ME and something happens! Perhaps the US legal system is now so broken that this might happen, I don't know. I doubt it. But certainly not in any other country. I'm not sure about that. Perhaps check... Security UI is opinion. Informed opinion, but nevertheless opinion. Just like a certificate. A digital certificate is certainly NOT an opinionA CA certifies according to the expected procedures and does not provide opinionsDid you think about what you just said? ;-) Huuu? So why are the decision makers not involved in this discussion? I mean, we spend time and effort in order to help and shape an important part of a security related component (mainly policy wise), if after all any of our inputs aren't being considered seriously?!? Can you clarify the decision making process and use of this thread perhaps? There is no concrete process. This is as clear as it gets :-) OK, perhaps define a process so we know, if and how to invest our time? -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extended Validation Certificates
Alaric Dailey wrote: Duane wrote: Gervase Markham wrote: The use of SSL in phishing is on the increase. Where's the proof of your statement? or is this another thought exercise? http://www.zdnet.com.au/news/security/soa/Latest_phishing_scam_most_devious_ever/0,130061744,139116416,00.htm http://news.netcraft.com/archives/2005/12/28/more_than_450_phishing_attacks_used_ssl_in_2005.html Well, based on Netcrafts [1] own data of over 200,000 recognized pishing sites, 450 sites a year ago is not really a tendency! This is about 0.25 % of all pishing sites. Certainly NOT the issue here. Is this it, what you are trying to say? [1] http://news.netcraft.com/archives/2006/10/09/september_phishing_site_competition_winners.html -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extended Validation Certificates
smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Why now? (Was: Extended Validation Certificates)
Hi David, So I represent a certification authority, I am also a user, a Linux vendor and supporter of Open Source in general! Except the initial questions and suggestions which were CA related and about which Gerv either provided sufficient information or promised to take care of, my proposals, suggestions and ideas were strictly related to the UI behavior and handling of digital certificates in general by the current Mozilla/Firefox browser. In order to give the current thread a better meaning and take it out of the current locked situation, I made a serious proposal how to solve this better. As a matter of fact I proposed to form a group of interested parties and individuals (which makes up the Mozilla community), which should continue the discussion and return with results (i.e. defined proposals and recommendations) to the original thread. You may call this domination, but I'm prepared (and perhaps others) to invest time and effort in order to make the handling of digital certificates by Mozilla/Firefox better. Obviously the current situation isn't sufficient (perhaps taken over and never changed since Netscape times) and therefore I feel it important enough to make this contribution. This has nothing to do with CA dominance, but perhaps with some knowledge on the subject, being it as a CA, Linux distributer and with lots of contact with user/clients of such certificates. I hope , that this changes your impression! -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 L. David Baron wrote: On Tuesday 2006-11-07 23:32 +0200, Eddy Nigg (StartCom Ltd.) wrote: Agreed! Did you read our proposal on the Extended Validation Certificates thread? Shall I post it here as well? Please don't. Gerv started this discussion so that the Mozilla community could discuss its position on EV certificates, and so that Gerv could report that position to the CA/Browser Forum, where browser makers and CAs discuss these issues. So far most of the posts in the thread have been by CA representatives (and Gerv's responses to those posts). While occasional comments from CAs may be useful in the thread for purposes of clarification, I certainly don't welcome such attempts to dominate the discussion. Given the existance of the CA/Browser Forum, I think discussion between CAs and Mozilla is more appropriate there. I'd like to see the Mozilla community be able to discuss what is best for Mozilla's users without having that discussion drowned out by people who have strong business interests (on one side or the other) in seeing a particular solution. -David ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extended Validation Certificates
smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extended Validation Certificates
Ka-Ping Yee wrote: How is the user to distinguish when the displayed name is correct? This is a crucial question. Right now we have the problem that the certificate-verified information (the domain name) is chosen by the attacker, and can be chosen to confuse users. A name like bankofthevvest.com is confusingly similar to bankofthewest.com, and a name like amazon.tv collides with amazon.com unless you are aware of that they belong to different namespaces. This is a common and effective attack tactic. Yes, this is a valid question and I guess, there is a multiple answer: First of all, CA's should prevent the issuing of certificates in obvious cases. Obviously identity/business validated certificates are most likely less problematic, since the CA holds various data about the subscriber, in addition to the displayed details within the certificate, which could be used against him. But also FF2 provides an excellent anti-pishing tool which helps to prevent such an attack. However one must note, that most pishing sites don't even bother to acquire digital certificates, but run their sites plain http. More than that, most pishing sites don't have any similarity to the domain name they are pishing. So how can EV certificates and EV certificate UIs avoid confusing users with displayed names that are similar, or the same but registered in different jurisdictions? That's perhaps a question for the EV/Browser Forum... but since the subscriber is supposed to get validated extensively, he would not dare to try something like this. Also, EV certificates would and should not be the common form of digital certification, therefore users might recognize and pay attention to the different color. It might help a user, if Paypal or eBay suddenly would loose it's green color (after the user got used to see it for a while when visiting their sites). Other type of confusion could happen however, if the entities are legitimate businesses and validated as such... -- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
