On Monday 09 May 2005 17:34, Ram A Moskovitz wrote: > On 5/9/05, Jean-Marc Desperrier <[EMAIL PROTECTED]> wrote: > > Ram A Moskovitz wrote: > > > > > > They can not truly attack the signature,
Actually, be careful there. The fact that they cannot theoretically forge a digital signature should not be confused with the myriad of ways in which an attacker can futz with an *implementation* of a signing tech. I don't know anything about the code signing tech, but if it is anything like any of a dozen other signing techs out there, it will probably surprise in how vulnerable it is. Most signing applications were put together with so many false assumptions that they are either unusable or not worth using. Included in that list is cousins like S/MIME. > > so they will in fact attack the > > registration process. We have been warned here several time it will not > > resist so much when *actually* under attack. > > Personally I've been warned of many things by many people. I am > selective in what I take as fact and further I believe that a dynamic > system may change to reflect reality. Indeed. Establish facts, and build on them. Sadly, we have very little experience of signing weapons being used under fire. Things like the PGP family's fairly sophisticated web of trust have not really ever been attacked, and neither has my own contract signing technology. Attacks always filter to the most economical attack. That's why for example, the great gaping hole of the substitute CA attack is unexploited; it's cheaper to simply bypass any crypto tech if the core app does not force the use of crypto. But this also gives you the direction of defence: put in place something that is cheap for you and expensive for the attacker; it doesn't have to stop the attack, just make it expensive enough for the attacker to move on. That's why displaying the CA and identity of the cert is such a good idea, it exposes the information without really blocking the attack. Cheap for the good guy, revealing for the bad guy. > > > Having said that I'd point out that signed deceptive (not > > > disclosing) spyware is revoked as a normal course of operations at > > > VeriSign. > > > > That's the point : "Deceptive (not disclosing)". > > > > So if the user has clicked "OK" when asked if he agreed with the > > conditions of use that say that in order to better service him, a record > > of his actions will be sent back, it's not deceptive and there's no > > ground to ask Verisign to revoke the certificate. > > Yes. If the installation page for a piece of software says "this > extension will do this horrible thing" and the use decides to install > it I would hope that you would not insist on prevent the > distribution. If on the other hand the installation or terms of use of > a software package is deceptive about what it does, ie doesn't mention > things that are paramount to many users, that would be grounds to ask > VeriSign to revoke the certificate. The problem with relying on deception as a trigger for action is that it requires a human decision, which is very difficult to rely upon. See for example the chinese proxy attack, which we all think we should be able to simply say "NO!" to but in reality we will probably not ever get the chance to say no, at least before it is too late. About the only thing that is reliable is also incomplete: state who signed the code. And who signed the signer. Then let the reputation either work or not. It's one of those dilemmas, on the Internet, anyone can download any junk and commit digital hari kari. Just because we can see this happening, and we might be able to stop it sometimes doesn't mean that we have to, every time, guarantee a safe browsing experience. Life just isn't like that. > > >>I agree with that but I maintain digital signing is still the solution > > >>only with some additional measures, in one word making sure an > > >>*effective* revocation framework is in place. > > > > > > That is part of the solution. Another part is requiring signatures - > > > perhaps only to access certain APIs. > > > > Ram, extensions already /can/ be signed. So the change would be to > > /require/ it, and I'm certain in that case MoFo would silently drop > > unsigned content. > > I said require not allow. If a user wants to override this it should > be a non-inline method or the user should change the default behavior > to enable inline. The default setting for "probably a bad idea" > should be "don't allow." Possibly. As long as the cert info is shown, try it and see how many sites pop up with info on how to turn off the protection. If Mozilla distributes with required signing for code, then it should also distribute easy ways for developers to create keys and self-sign them. Asking developers to pay for a Verisign cert so they can contribute free code to people downloading Mozilla for free is not going to work real well, it's hitting the people that make Mozilla what it is to no end. iang -- http://iang.org/ _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
