I think it's also important to note that this attack could as easily be used to create end-entity certificates. It likely wouldn't be as huge of a security hole as creating a fake CA, but if we focus on CAs without realizing that there are other classes of attack thus enabled we're ultimately doing the users and ourselves a disservice.
This is one reason why I think KCM is a good idea. I'm trying to write up a proposal on a means of handling it within the certificate structure, as an optional capability. -Kyle H On Sat, Jan 10, 2009 at 4:43 PM, Jan Schejbal <jan.schejbal_n...@gmx.de> wrote: >> why the proposal I made (force CAs to agree not to issue new MD5 certs, >> and to not allow any sub-CAs signed with MD5) does not cover your desire. > > I said that your proposal DOES (mostly) cover my desire and should be > implemented. I also tried to point out the differences I see between the > proposals and what conditions would (all) have to be met so it is not > necessary to go the additional step of invalidating existing MD5 > certificates. > > I said that assuming that (1) there will be no preimage attack on MD5 for > the next years (I did not make any assumptions on how probable that is, I > don't consider it very probable that someone finds such an attack in the > next few years) AND (2) if we are willing to take the small risk that > someone might have already done (and not published but kept for later abuse) > exactly the attack that was demonstrated at the end of the last year (which > I considered OK), AND (3) we don't care about non-default CAs, then your > proposal is way better than mine. > > I already pointed out in my last post that (2) shouldn't be a problem but > still wanted to point that risk out as something that is there and should be > considered by people who can assess it better. I also did not consider (1) a > problem (might not have been clear enough) and again just did not want to > conceal that assumption. So it all depends on if we should care about CAs > not trusted in the default install of Mozilla apps and thus bound by mozilla > policies, and if we don't (which is reasonable) then I was and am saying > that your solution IS better. In case we want to care about CAs that are not > bound by mozilla policies (which I also consider reasonable), then (and only > then) my proposal might have advantages. > > I don't know why this makes you assume that I >> >> mistrust the cryptographer community so deeply > >>> No matter what way will be chosen, the sooner >>> it happens, the sooner we will get rid of this >>> security risk. >> >> Please state your security risk, > > CAs that may still be issuing MD5 certs if *nothing* gets done. This is why > the proposal you made *does* cover my desire. Your proposal would put all > the risks we know to be significant out of the way, while mine would also > fix some smaller ones that can *probably* be ignored as insignificant (but > we can't be 100% sure). > > I think mine is a tiny bit more secure (mostly by avoiding the risk that > someone might already have a colliding cert using the known attack and > didn't publish it) at the expense of refusing some valid certs, while yours > is probably still secure enough and avoids invalidating certs. > > As I learned that in security, it is often attempted not to take any risks, > not even quite far-fetched ones, I don't know if someone who takes the > decisions will not prefer the "paranoid" way despite the disadvantages. I > really do not know what choice is the right one, taking certain minor risks > or avoiding them too at a certain cost. > > To put it short and clean: I consider your proposal better than mine, but > depending on what one wants to achieve, mine could have some advantages at > the cost of (bigger) disadvantages. > > Jan > > -- > Please avoid sending mails, use the group instead. > If you really need to send me an e-mail, mention "FROM NG" > in the subject line, otherwise my spam filter will delete your mail. > Sorry for the inconvenience, thank the spammers... > _______________________________________________ > 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
