There's a bug about signing FF extension in bugzilla, that what closed WONTFIX. There was some comments by the FF developers that digitally signing ActiveX has not proved effective against spyware.
I somewhat agree, though the reason it's not effective is that it's not really used. Users know they "should" click OK when their computer asks them a question that seemingly interferes with their normal goings on.
Silently drop unsigned/badly signed content instead of displaying a warning, and attaquers will start to attack the signature itself.
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.
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.
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.
In my view, the door to logically leave open for unsigned extensions would be to manually expand them in the extension folder, in a subfolder named after their GUI. That's the install process Ben Goodger describes for extension developers in :
http://weblogs.mozillazine.org/ben/archives/008066.html
Extension have complete access to the browser, and can contain binary libraries, but the domain where the signature is required to access certain API is the one of signed scripts.
At the moment, no commercial provider of code signing offers a proper solution for that,
I disagree. VeriSign operates a variety of solutions for a environments with similar if not identical needs.
See above for a first problem.
A second problem is that extension creation is largely a grassroot thing. Creators don't make any benefit on the extension they create. They find the appreciation of users enough of a reward, but if MoFo tells them they must now *pay* to diffuse it ...
[...] As long as the only intended market is mozilla's intrinsic use, this is not such a big deal, and you could find competence to do that on this group.
Competency certainly. Economically viable would require finding generous volunteers. A commercial CA has the benefit of leveraging their people / systems / bandwidth / crypto hardware across thousands of deployments. Scale matters.
The idea is that the scale of extension developpement for Firefox is not that large. A few hundreds, at most in the thousand range. If it gets larger, yes, it would be no more something that can be handled easily, but I don't see how it would.
The idea I describe in my other message shows how to make it so that only the right people get those certificates, and limit the requirement for revocation (but *not* count on the fact it wont be required at all), the aim is definitively to keep this a small scale market.
On the contrary, mozilla.org purpose is to satisfy FF's users, if the CA policy says it has the final say on any decision, there's is then no risk someone can sucessfully abuse signed extensions.
Precisely. VeriSign operates thousands if not tens of thousands of CAs under a variety of policies including ones specified by platform providers (OS, hardware, other) and others specified by industry standards and others specified by VeriSign policy alone.
The involvement of RedHat in the project means a solution based on the RedHat certificate management product is a much more natural choice.
The RedHat product is not ready yet, but meanwhile the version used could supposedly be based on binaries corresponding to what the last AOL release consisted of.
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.
And CRL don't restrict you to on-line use.
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
