Re: Unbelievable!
Kyle Hamilton wrote: I then have to click at least six times to try to figure out what's going on, and then when I do find a site that's protected by an unknown CA certificate (OR that I've removed the trust bits on), I have to do the following: 1) Click 'add an exception' 2) click 'get certificate' (why I should have to do this is beyond me, since firefox obviously already has the certificate downloaded since it told me 'sec_error_untrusted_issuer', which it couldn't have known without the certificate in its possession ANYWAY) Not that it changes your point any, but if you set the pref browser.ssl_override_behavior to 2 then you won't need to get Certificate. Firefox 3.1 will have this behavior by default. If you set browser.xul.error_pages.expert_bad_cert to true then you won't have to click a link to reveal the add exception button, saving a click at that step, too. Firefox 3.1 won't be adopting that default though. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Facts about Comodo Resellers and RAs
On 12/24/2008 05:44 PM, Eddy Nigg: I have received also testimonials that Mozilla and Microsoft received previously complaints and evidences about the business practices of Comodo. I'm not aware which specific actions were taken back then. I have to make a small correction about this statement. The complaints and evidences mentioned above are not recent and in severity of a lower extend than recent events. Thanks. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
Kyle Hamilton wrote: (Especially if Comodo delegates full Registration Authority capability without verification, which seems to be the case -- though they could have simply issued a sub-CA certificate.) Delegating the RA's tasks is still different from issuing a sub-CA cert since with a delegated RA the CA can look at all issued EE certs and revoke some of them if needed. A sub-CA typically runs completely on its own so the CA could only revoke the sub-CA cert and not certain EE certs. It occurs to me that there is no facility in Firefox or other Mozilla products to provide an explanatory dialog that there's an issue, and such a facility would be extremely useful at this point. Being able to print a message to the user like The Mozilla Foundation has identified issues with the trusted root that issued this certificate which prevent Firefox from being able to guarantee that this is truly the site to which you intended to go. While it is unlikely that this is a widespread problem, and an attack would rely on more technical intrusions into the network, the nature of these issues requires that you be warned of this circumstance so that you can exercise appropriate levels of caution. The Mozilla Foundation is working with the trusted root to resolve these issues. would help a lot. Either the trust bits are removed or not. Such a dialogue wouldn't help at all. It's too complicated. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Eddy Nigg wrote: I think Thawte uses the keygen tag as well. This is a signed public key and challenge (SPKAC). I also thought so. But there is some Javascript and the HTML looks like this: select name=spkac challenge=tURRaHXxYBDwCk58option2048 (High Grade)/optionoption1024 (Medium Grade)/option/select This is definitely not a keygen tag. If I disable Javascript and press [Next] it won't work. Hmm, strange. I've examined the data traffic exchanged with livehttpheaders. The data I've grabbed looks like a SPKAC blob but I really wonder why the hell they are not using keygen. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Suspend trust bit (was Unbelievable!)
Eddy Nigg wrote: On 12/23/2008 09:09 AM, Kyle Hamilton: Of course, this would be an NSS change (the addition of a 'trust suspended' bit, I think this to be an interesting idea and should be considered. I really wonder why there should be one state more. And how is it going to be set (updated)? A cert is either trusted or not. Period. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
Frank Hecker wrote: From my point of view I'd wait on more information regarding items 2 and 3 above before making a recommendation. Could you please define a time-frame within Comodo MUST react? Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
Kyle Hamilton wrote: I hate to say this, but this IS The Worst-Case Scenario. A CA has gone rogue and issued certificates that violate its standards, and the standards of the root programs that it's a part of -- it is true that Comodo didn't /intend/ to go rogue, but it has, and we can't afford to let it damage the greater PKI. Since every CA in the root store is treated the same, there is no differentiation between them -- and this means that Verisign and Comodo and Thawte and *every* CA share the same reputation. If one goes rogue, it's exactly the same as if all of them have gone rogue, in the eye of the end-user. I fully agree here. That's why I support to remove the trust bit from the Comodo root CA cert immediately and make them go through the whole process of applying to be a trusted root CA. THIS is why I want to see greater differentiation in the browser chrome between CAs, so that one bad apple doesn't spoil the whole root barrel. I don't think that's feasible. Nobody will be able to deal with that differentiation. That's also the reason why I think that EV certs does not help. The problem is the lack of auditing CAs and then punishing rogue CAs. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
Justin Dolske wrote: ...I think there's some risk that if a Firefox update suddenly breaks a large swath of legitimate SSL sites, that could end up training users to ignore the problem. Given the large amount of self-generated server certs this problem already exists. Ultimately you cannot hold a user back from shooting himself in the foot. I'm not even sure how you'd present this condition to Joe The User in a comprehensible way. I'm pretty sure that if this case is taken to popular news ticker sites or other publications many users will be aware of this. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
doug...@theros.info wrote: I, for example, have a ssl cert from comodo reseller, and they DO have made all the validation steps. My site, a legitimate one, would be in trouble with this. Are you all sure that it is a good measure to just knock off the root cert or security bit? please, think twice Douglas, I understand that this would be a problem for you. But after thinking twice the larger issue with bad operational practice at Comodo's CA and their resellers outweigh your personal damage. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
Kyle Hamilton wrote: [..many good observations snipped..] Because of this, my recommendation that Comodo's trust bits be removed until a full audit of their practices (and a full audit of all issued certificates) stands, and I am that much more resolute in my belief. Full ack! Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On 12/25/2008 02:39 PM, Michael Ströder: doug...@theros.info wrote: I, for example, have a ssl cert from comodo reseller, and they DO have made all the validation steps. My site, a legitimate one, would be in trouble with this. Are you all sure that it is a good measure to just knock off the root cert or security bit? please, think twice Douglas, I understand that this would be a problem for you. But after thinking twice the larger issue with bad operational practice at Comodo's CA and their resellers outweigh your personal damage. If the operations of certstar would have been a glitch and bug in their validation system and a very isolated event, I would not suggest to take any actions beyond requesting to have it fixed properly, reviewed and approved by the Comodo management. The very fact that there was no validation in place *at all* suggests however that Comodo hasn't done any review, testing and approval of their systems. This is beyond the acceptable norm of failures which certainly can happen - it suggests gross negligence by Comodo. Secondly, I believe that such crucial parts shouldn't be outsourced to a third party - an issue we'll have to look at very closely soon here at Mozilla. More than that, Comodo hasn't any controls in place to prevent fraudulent or mistaken issuance of certificates of high profile targets. This is another failure. Third and as noted, resellers don't have to undergo any or only some validations - insufficient and not adhering to the Mozilla CA Policy. The policy is very clear in this respect and Comodo has failed to disclose this properly during their review this spring. Douglas, if and when any actions will be taken, you'll be eligible for compensation by Comodo. You would have to look elsewhere to get a new certificates maybe. This would be perhaps annoying, however the risk of real damage to a third party would be much more severe. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On 24/12/08 15:17, Frank Hecker wrote: Gen Kanai wrote: More discussion on this topic over at Programming Reddit: http://www.reddit.com/r/programming/comments/7lb96/ssl_certificate_for_mozillacom_issued_without/ Unfortunately the discussion devolved (as it always does :-) into the merits of self-signed certificates. Oh well. And the merits of mineral water versus municipal water... There are a lot of people happy with municipal water, and a lot of people happy with mineral water, and they aren't likely to sit down and share a social drink :) iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
Michael Ströder wrote: Frank Hecker wrote: From my point of view I'd wait on more information regarding items 2 and 3 above before making a recommendation. Could you please define a time-frame within Comodo MUST react? Comodo (in the person of Robin Alden) has already made a reply: http://groups.google.com/group/mozilla.dev.tech.crypto/msg/b24e70ea2c396bb5 The question is, what else do what want Comodo to do in this case? They still have some certificates unaccounted for in terms of verifying the validation, and certainly I'd like to hear the status of that as soon as possible. Beyond that? It's somewhat of an open question. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
Kyle Hamilton wrote: What is the effect of this problem on the request to enable the UTN-UserFirst-Hardware root for EV, https://bugzilla.mozilla.org/show_bug.cgi?id=401587 ? I think (but don't have time to confirm right at the moment) that that request is moot. As far as I know, Comodo EV certificates are working fine right now even in the absence of the UTN-UserFirst-Hardware root being enabled for EV. This is due to EV-enabling of the new Comodo EV root and also IIRC due to code that was added to PSM (?) to specially handle cases like this where the EV root was cross-signed by a non-EV legacy root. (AFAIK this scenario was/is not unique to Comodo. I believe all the VeriSign EV CAs work this way as well: a newly added and EV-enabled EV root cross-signed by a non-EV legacy root.) Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
Frank Hecker wrote: Michael Ströder wrote: Frank Hecker wrote: From my point of view I'd wait on more information regarding items 2 and 3 above before making a recommendation. Could you please define a time-frame within Comodo MUST react? Comodo (in the person of Robin Alden) has already made a reply: http://groups.google.com/group/mozilla.dev.tech.crypto/msg/b24e70ea2c396bb5 Yes, already saw that in the meantime. But it does not really say much. The question is, what else do what want Comodo to do in this case? I'd like to know whether there are more contractors serving as RA for Comodo. A list should provided who they are and which measures are taken for domain validation. What really strikes me is that this case was only detected by Eddy because of Certstar's spam e-mails. They still have some certificates unaccounted for in terms of verifying the validation, and certainly I'd like to hear the status of that as soon as possible. Beyond that? It's somewhat of an open question. I'd tend to punish a rogue CA by removing their root CA cert from NSS. Maybe this serves as a good example to other CAs that the Mozilla CA policy is really enforced. Otherwise nobody will care. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
I've already stated my preference. To reiterate: Actually, I think it's very important that the accounting include this: for each name (not just certificate, but name in subjectAlternativeNames) that has been certified, a connection to the TLS ports should be made, and the certificate presented by the site compared against the certificate that Comodo issued. This obviously won't be a complete verification, but it should give a start to see how widespread the problem is. A script to do this could probably be written fairly easily, but depending on the number of certificates Comodo has issued that are currently valid (and I'd like to see some hard numbers on that, as well) it could take a while to run. From the script, the numbers I'd like to see are: the number of unreachable/not-answering names/hosts, the number of matching certificates, and the number of mismatched certificates. From that output plus Comodo's records, I would also like to see how many resellers there are and how many of them have sold mismatched certificates. (The 'resellers' I refer to here are 'contracted registration authorities', not those who make money by funnelling users into Comodo's pages. I'd also like to know how Robin/Comodo performed the audit on certificates for proper domain validation -- if they're relying on the presence or absence of that check-box I have verified the domain control in accordance with..., I think the entire audit is useless and that they should be removed from the root store out of spite -- for making a mockery of the entire process.) I do think that Comodo should be required to suspend their Registration Authority processing until they in-source their domain-control verification as a condition of staying in Mozilla's trust list. I also have not heard word 1 about if they use registration authorites for higher-assurance certificates. -Kyle H On Thu, Dec 25, 2008 at 8:49 AM, Frank Hecker hec...@mozillafoundation.org wrote: Michael Ströder wrote: Frank Hecker wrote: From my point of view I'd wait on more information regarding items 2 and 3 above before making a recommendation. Could you please define a time-frame within Comodo MUST react? Comodo (in the person of Robin Alden) has already made a reply: http://groups.google.com/group/mozilla.dev.tech.crypto/msg/b24e70ea2c396bb5 The question is, what else do what want Comodo to do in this case? They still have some certificates unaccounted for in terms of verifying the validation, and certainly I'd like to hear the status of that as soon as possible. Beyond that? It's somewhat of an open question. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Suspend trust bit (was Unbelievable!)
If Frank's desire to balance user benefit from keeping the root in with user security by taking the root out is to be upheld, then there needs to be a way to notify the software user that there is a valid complaint against the operator of the CA in question. If it drives business away from the CA in question (because the owner of the site doesn't want to have to deal with the warning every time she browses to it using Firefox), well, that's the CA's own fault. The setting of that bit should encompass the following: 1) A complaint has been made, 2) Mozilla has examined the complaint, and 3) Mozilla has found good cause for believing that the conduct of the CA has violated its root CA policy. Thus, such a statement would not (and could not) be made until Mozilla has done its own due diligence, and thus such a statement would not be libelous. (I wish that Mozilla's general counsel was on this list.) -Kyle H On Thu, Dec 25, 2008 at 3:21 AM, Michael Ströder mich...@stroeder.com wrote: Eddy Nigg wrote: On 12/23/2008 09:09 AM, Kyle Hamilton: Of course, this would be an NSS change (the addition of a 'trust suspended' bit, I think this to be an interesting idea and should be considered. I really wonder why there should be one state more. And how is it going to be set (updated)? A cert is either trusted or not. Period. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
among other things, because keygen is not a standardized mechanism. -Kyle H On Thu, Dec 25, 2008 at 4:10 AM, Michael Ströder mich...@stroeder.com wrote: Eddy Nigg wrote: I think Thawte uses the keygen tag as well. This is a signed public key and challenge (SPKAC). I also thought so. But there is some Javascript and the HTML looks like this: select name=spkac challenge=tURRaHXxYBDwCk58option2048 (High Grade)/optionoption1024 (Medium Grade)/option/select This is definitely not a keygen tag. If I disable Javascript and press [Next] it won't work. Hmm, strange. I've examined the data traffic exchanged with livehttpheaders. The data I've grabbed looks like a SPKAC blob but I really wonder why the hell they are not using keygen. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Dear Firefox Developers, I understand that this should be the right place to ask: Using Firefox we would like to generate Thawte X.509 E-Mail Certificates. When generating the Private/Public key pair using Firefox as well as requesting the certificate, we are logged in on the Thawte Website. *Our security relevant question:* Which data is transmitted to Thawte during the Private/Public key pair and certificate generation process using Firefox (and Thawte) ? *Does Firefox send to Thawte any form of private key during this process, or not ?* If the private key was transmitted to Thawte, in theory a Thawte staff member –would he gain access to the private key at thawte- could decrypt emails encrypted by us, or sign an email in our names … We would be happy to understand better the key and certificate generation process using Firefox (and Thawte), considering the security critical point mentioned above. Thank you in advance, Proud Firefox users ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
At 11:13 PM -0800 12/24/08, Daniel Veditz wrote: Paul Hoffman wrote: At 1:16 AM +0200 12/24/08, Eddy Nigg wrote: Select Preferences - Advanced - View Certificates - Authorities. Search for AddTrust AB - AddTrust External CA Root and click Edit. Remove all Flags. Doesn't this seem like a better solution than sue Mozilla for theoretical future damages incurred by using their free software? Put more rudely, why do you expect Daddy to fix it for you when you can fix it yourself, more easily and more quickly, if you want to? Isn't that a bit like an auto maker issuing a notice If you don't want your car to explode in a fender bender you can crawl under the right rear and remove the screw marked 34A on the following diagram. It depends on what you mean by a bit. I don't remember paying for Firefox. Nor do I remember anything in the software that made any strong assertion of the validity of all the certs that might be issued by any of the CAs in the root pile. Maybe you had a different experience. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
At 7:16 PM +0100 12/25/08, Michael Ströder wrote: I'd tend to punish a rogue CA by removing their root CA cert from NSS. Maybe this serves as a good example to other CAs that the Mozilla CA policy is really enforced. Otherwise nobody will care. This is Firefox we're talking about, not IE. Do you really think that this is going to help end users, or just hurt people who bought certificates from the lax (not rogue) CA? Like most punishment, the origin is more often the desire of the punisher to feel powerful. In this case, it is also for financial gain by the first one to propose the punishment, of course, but the base desire is the same. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On 12/25/2008 08:16 PM, Michael Ströder: The question is, what else do what want Comodo to do in this case? What really strikes me is that this case was only detected by Eddy because of Certstar's spam e-mails. Even though I believe that Robin and his crew are really angry with me right now for disclosing it publicly, this was really the least price they could pay and best case scenario for this situation. None of the 109 other cert holders suspected that anything might be wrong. I'm certain that this would not have remained undetected for long and somebody could have brought some real damage upon all parties involved. Speaking about Robin, I wouldn't want to be in his shoes right now - it's more or less one of the nightmares of a CA. On the other hand, if this is case (it would be for me) than I really anticipate and hope that some real changes are going to happen. Additionally, whatever actions are taken against Comodo and whatever lessons they learned, one thing is clear, that the company which spammed and mislead other CAs customers so shamelessly has nothing lost in this industry. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On 12/26/2008 12:24 AM, Paul Hoffman: At 7:16 PM +0100 12/25/08, Michael Ströder wrote: I'd tend to punish a rogue CA by removing their root CA cert from NSS. Maybe this serves as a good example to other CAs that the Mozilla CA policy is really enforced. Otherwise nobody will care. This is Firefox we're talking about, not IE. Depending on country and audience, Internet Explorer has even less market share than Firefox. We are in 2009, not 2003 if you forgot. Do you really think that this is going to help end users, In the longer term it might. And it really depends on other factors like how many potentially other certs could have been issued this way. or just hurt people who bought certificates from the lax (not rogue) CA? So? They may claim damage from Comodo. Comodo even lists the compatible browsers in their CPS [1] under section 2.1.5 CA Root Public Key Delivery to Subscribers. A CA shouldn't guaranty browser support at any time (and I doubt if Comodo really did). In this case, it is also for financial gain by the first one to propose the punishment, of course, but the base desire is the same. Do you mean me? Go back and read what I really proposed: http://groups.google.com/group/mozilla.dev.tech.crypto/msg/fb8c1fbd0c219eb4 But perhaps you'd disclose how many Comodo shares you've got? ;-) [1] http://www.comodo.com/repository/09_22_2006_Certification_Practice_Statement_v.3.0.pdf -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
xbcvb cvbcvbvcb wrote: Using Firefox we would like to generate Thawte X.509 E-Mail Certificates. When generating the Private/Public key pair using Firefox as well as requesting the certificate, we are logged in on the Thawte Website. *Our security relevant question:* Which data is transmitted to Thawte during the Private/Public key pair and certificate generation process using Firefox (and Thawte) ? *Does Firefox send to Thawte any form of private key during this process, or not ?* I don't think so and I checked it today. The SPKAC blob with the public key seems to be transferred (examined it with livehttpheaders and dumpasn1). But as I wrote in my other posting they unfortunately seem to not use the static HTML keygen tag and the process does not function without Javascript. So they could silently change the behaviour of the enrollment interface to use the CRMFRequest Javascript call. IIRC the CRMFRequest could contain the private key. (Any good Javascript tracer for Seamonkey 1.1.x out there?) I'd love to have an option to forbid CRMFRequest calls... Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
Paul Hoffman wrote: At 7:16 PM +0100 12/25/08, Michael Ströder wrote: I'd tend to punish a rogue CA by removing their root CA cert from NSS. Maybe this serves as a good example to other CAs that the Mozilla CA policy is really enforced. Otherwise nobody will care. This is Firefox we're talking about, not IE. Do you really think that this is going to help end users, or just hurt people who bought certificates from the lax (not rogue) CA? PKI is about security. Strange I have to remind you about that. There is a Mozilla CA policy which was violated possibly causing a risk for end-users. Mozilla has to give some evidence to the community and CAs that the policy is enforced. Like most punishment, the origin is more often the desire of the punisher to feel powerful. In this case, it is also for financial gain by the first one to propose the punishment, of course, but the base desire is the same. Personally I have absolutely no benefit from withdrawing the trust flags from Comodo's root CA cert. So it seems strange to me that you're accusing me in such an arrogant way. This does not contribute anything to this discussion. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On Dec 26, 2008, at 1:49 AM, Frank Hecker wrote: Beyond that? It's somewhat of an open question. Frank Mozilla needs to have a concrete policy and procedures in place so that there is no question as to what the penalties would be for future actions of this kind. I personally like John Nagle's proposal from earlier in this thread: http://groups.google.com/group/mozilla.dev.tech.crypto/msg/9443ba781a669879 I think there are other actions that need to be taken beyond John Nagle's proposal, but it is a good start. In addition to John Nagle's propsosal, I believe Mozilla needs to act early in 2009, and not let weeks or months go by without resolution. We can discuss the details of what happened and why endlessly to no benefit of our users. Gen ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Kyle Hamilton wrote, On 2008-12-25 12:15: among other things, because keygen is not a standardized mechanism. True, but neither is crypto.generateCRMFRequest. There is no standardize html or JavaScript feature for this purpose. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On 12/26/2008 03:28 AM, Gen Kanai: I personally like John Nagle's proposal from earlier in this thread: http://groups.google.com/group/mozilla.dev.tech.crypto/msg/9443ba781a669879 Gen, one thing to note, that Comodo most likely performs a yearly WebTrust audit, though the last one I can see currently is from the tenth of July 2007. Also important to note that the audit itself isn't enough - that's why there is the Mozilla CA Policy which clearly defines the minimal requirements. (A CAs can pass a WebTrust audit without conforming to those requirements set up by Mozilla). As a matter of fact, we are still missing a procedure to make sure that CAs issuing EV certificates indeed perform the yearly audit as required by the EV guidelines. Those which don't, have to have EV status removed as they wouldn't be in compliance with the EV guidelines. Additionally, Mozilla has no control directly over certificates issued through certstar, since the certificates are issued from an intermediate CA certificate of Comodo. It's however possible and relatively easy to ADD this intermediate to NSS and deliberately mark it untrusted. It could be a good solution to prevent damage in case there should be more certificates in the wild (and assuming that resellers certs are issued through this intermediate). Incidentally I've brought up the issue of AddTrust and UserSomething CAs during the review discussion this year. It isn't exactly surprising that now all those questionable practices come up again, isn't it?! There were many more concerns brought up, which had no effect whatsoever on the status of Comodo and their request to upgrade to EV was eventually approved. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On 26/12/08 00:36, Michael Ströder wrote: Paul Hoffman wrote: At 7:16 PM +0100 12/25/08, Michael Ströder wrote: I'd tend to punish a rogue CA by removing their root CA cert from NSS. I do not see a rogue CA. The evidence of the posts here suggests a flaw leading to false certs was found and such certs were issued; and that the CA responded when made aware. What is rogue about that? Are you saying they didn't respond? Maybe this serves as a good example to other CAs that the Mozilla CA policy is really enforced. Otherwise nobody will care. This is Firefox we're talking about, not IE. Do you really think that this is going to help end users, or just hurt people who bought certificates from the lax (not rogue) CA? PKI is about security. Security is risks and costs. In this case, there is low risk and zero costs. Perhaps because the problem was caught early on, but security is about real hard facts not conjecture. (If you want real hard costs and losses and grief, check out phishing. Where's the lynch mob when we are dealing with phishing, I wonder?) Strange I have to remind you about that. There is a Mozilla CA policy which was violated possibly causing a risk for end-users. Mozilla has to give some evidence to the community and CAs that the policy is enforced. But it has! Mozilla talked to the CA. The CA is dealing with it. There are emails to that extent, posted here. What else is necessary? And more importantly, why? iang, curiosity mode switched to hard-ON. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
keygen specification? (was long thread about various HTML/javascript key generation)
On Friday 26 December 2008 07:15:59 am Kyle Hamilton wrote: among other things, because keygen is not a standardized mechanism. FWIW, is there a description of how keygen is actually supposed to work, and a set of test cases? Brad ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
