Hi, We had this interesting discussion about signing extension, and I'm really sorry that I didn't have more time to answer Gervase and Eddy's objections against my point of view. I don't have much more time to develop it now.
But I'd like to point out I'm not the only who is doubtful about the real level of authentication current commercial CA provide for code signing certificate. See this SyScan'07 presentation : http://www.symantec.com/avcenter/reference/attack.surface.analysis.of.blackberry.devices.pdf Malicious Code Signing chapter : "signatures can still be obtained with relative ease and anonymity. Code-signing keys can be obtained anonymously via the use of prepaid credit-cards and false details. Pre-paid credit cards can be bought and charged locally with cash without the requirement of presenting I.D.8 This makes it potentially impossible to determine the creator of a signed malicious application, and as a result track the perpetrator." Also about the previous objection of gerv and eddy : - ed : "same (failed) approach of blacklisting mail servers, phishing web sites" No, just the opposite. If only a single private CA is accepted, the number of certificate is *under control*. You create them, and you know exactly how many are out there. This is *not* the same as mail server and web site, where nothing can control how many are available. - ed : "What if YOU failed to detect a serious problem ... You'll be liable ... Remember you suggest to review the code, not verify the identity!" Good point, but if I look at the documents CAs publish, I see they are also very careful to have very little liability were they to fail at verifying identity. I mean *very* *little*. The point here would be to document that you engage yourself to respect a given procedure, not that this procedure will successfully detect problem. If people don't agree, they don't accept the EULA. - grev : "barrier to entry" on extensions, "level of control over the extension community which we have so far been entirely unwilling to even consider" I'm sorry there must be some misunderstanding, because it was my understanding that there was already some level of barrier to entry on addons.mozilla.org. If not, and if any extension will, as a question of principle, be accepted on addons.mozilla.org, why does this site have the special priviledge to be allowed to install add-on without prompt ? I mean if *anything* goes on addons.mozilla.org, why has it a special treatment ? I understand the principle of choice and innovation, but it seems to me that providing something that is "secure by default", I mean providing something that the average internet user can *just* *trust* is almost about equally important for MoFo. Isn't it ? If today malware extensions are little more than a theorical concept, and the infrastructure to make them secure, any infrastructure, will create a significant barrier to entry, then it's simply a bad idea to try to do that. And both seem accurate descriptions, so ... But if tomorrow malware extensions really become an every day threat, then here will be a hard choice to be done between this two principles. I really thought that the idea of a community organized review of extensions would be be something that could match MoFo's philosophy, even if limiting choice but for good reasons and in a /good/ manner. My view was not to impose something "coming from above", but to have a process that every community member could be a part of. But if that's no good, then when malware extensions become a real risk MoFo will have to find another solution. And with reference to the point rised the doc at start of this message, which is very similar, whilst quite more detailled, to what I said here earlier, but I hope if the message comes a Symantec employee at an important security conference it's better accepted, I believe accepting any code signing cert will not be adequate. And the only commercial CA based alternative I see, strongly restricting the choice of acceptable commercial CAs, seems very impure in terms of "choice and alternative". An important point also is that there's no use of fake cert for crookery today, because crooks do go the easiest way always and there's no need to use fake cert today to do crookery. If and only fake cert become the only way, fake certs will be used. And weaknesses like the one James O’Connor points will become very important. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
