On Fri, October 2, 2015 11:53 am, Peter Kurrasch wrote: >One final comment: in terms of the embedded space, without publicly > vetted roots I think it's safe to say that most products will include > whatever root is necessary just to make the product work and that security > concerns might not play much of a role, if any, in the decision making. I > don't think that's such a great outcome. Again, an opinion but one based > on first-hand experience.
Peter, I can't help but read your replies and reach the conclusion that you may be fundamentally confused about code signing. At the least, you're arguing for a strawman that is neither practical nor, in modern terms, secure. To be clear, this proposal is not an argument against the notion of signed code. I think there's a strong interest in ensuring code that runs is cryptographically verified - to avoid modification and ensure provenance. But what you're arguing for, perhaps operating under incomplete information or incorrect conclusions, is that there is a need to have a set of third-parties mediate identity information about the provenance of that code. We know this is not a necessary condition for "code signing" as a concept. Both Apple and the Android ecosystems demonstrate this - both have strong notions of code signing, but there, identity is based on first-party assertions (Apple/Google and their relationship with the particular developer), rather than outsourcing that to arbitrary third parties and systems. We also know it's not necessary for identity information to be an intrinsic part of code signing. Indeed, if you actually look at the embedded space - the home wireless routers, thermostats, smart refridgerators, etc - what you see is a desire to make sure the code comes from authorized parties, regardless of who they are. That authorization is determined by pre-existing relationships. For example, the WiFi router vendor will bake their vendor key into the device, and all future firmware updates will be signed by that vendor. This is a system that scales not just the embedded space, but you can see it equally in places like signed bootloaders for Android and ChromeOS devices. Again, establishing that you can have code-signing without the involvement of the PKI. What you're arguing for - which I'd go as far as to suggest it was a active strawman if I wasn't convinced you just earnestly misunderstand - is the specific need for third-party mediated identity information as part of a code-signing ecosystem. That has a tremendous number of tradeoffs, and in light of the already many failures of the commercial CA PKI, is arguably not worth the security hassle compared with mediating a first-party relationship (as in the Google and Android case). Organizations that do decide to rely on third-party CAs for codesigning have already ceded their security, independence, and control of their product's destiny, which is so bad an outcome that 'grabbing any root necessary' is not a significant issue. But I do want to emphasize that code signing is decidedly NOT equivalent to TLS, and this is not a case where you need to interoperate with existing systems, thus necessitating doing 'whatever is necessary'. Codesigning itself is necessarily green field - when you integrate code signing in a product, you HAVE to make a variety of choices about format, signature schemes, validation, etc - and there is zero need to interoperate. The only 'possible' exception to the above is the case for Microsoft Windows, Oracle's Java, or Adobe's AIR framework. Each of these systems decided to abdicate their security responsibilities and thus outsource customer-relationship management to third-party CAs and standards (such as Webtrust) so big you can drive a truck through and provide little reasonable assurances compared to what can be accomplished with a first-party system. But even in these cases, 'interoperability' is achieved by acting with the primary vendor's root store - of which they all maintain one - not forking one. I do hope you can see why the arguments you present are easily misinterprable as concern trolling; save for the fact that you've participated in past discussions and shown far more consideration, the arguments you've presented for code signing are somewhat indistinguishable from that. I can only hope it was based on a misunderstanding of how both modern and historic systems have deployed code signing, and perhaps confusion over the terminology, rather than deeply held beliefs in spite of that knowledge. Best, Ryan _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
