Eddy Nigg (StartCom Ltd.) wrote: > 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.
Could maybe try to brute-force the old key until they come up with a forged certificate that an SSL library accepts? The whole point is that all the weak keys come from a limited keyspace, right? In any case, I'm not going to argue this point, since now I've said everything I can usefully say about it. >>>> - 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 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". >> web-crawlers are not exactly rocket science. > > Nope, but needs quite some resources in order to receive some valuable > results within reasonable time. Yes, it does. > Yes, certainly, but even this might require quite some CPU cycles. Sure. >>> 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. I see no problem with explicitly listing CAs who won't say whether they're actually doing something. In a different group from the ones who say they're doing nothing, probably. >> 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. The premise (and a not unreasonable one) is that such a list can be generated if needed. > That's not something coordinated. I didn't mean to imply that it was, by any means. -Boris _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
