On 5/9/05, Jean-Marc Desperrier <[EMAIL PROTECTED]> wrote: > Ram A Moskovitz wrote: > >
> They can not truly attack the signature, 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. > > 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. > >>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." > >>The next step is to make sure the crl that includes the revocation > >>information gets widely distributed to FF users. > > > > Exerience tells me you would regret going down the CRL path. You want > > to use OCSP on the client side. > > Well, OCSP can bring problems too. I really think this would be used in > a situation with a large number of users and small number of revoked > certificates, where CRL work well. I understand that your expectation is there are and will be relatively few extension publishers. I think that the less checking you do on the way into the process (authentication) the more revocations you will have and the larger your CRLs will be. Further as the number of users of FF increases this will become an economic pain point. There are other problems compolexities you may not be considering that affect this. What do you do with a piece of code signed by a certificate that you have as revoked once the certificate has expired? > And CRL don't restrict you to on-line use. I don't install extensions when I'm offline as I tend to install them when I download them. _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
