On Fri, June 19, 2015 11:10 am, Brian Smith wrote: > The current set of roots is already too big for small devices to > reasonably > manage, and that problem will get worse as more roots are added. Thus, > small devices have to take a subset of Mozilla's/Microsoft's/Apple's > roots.
Without wanting to fracture the discussion, I think it's reasonable to say "citation needed". It's also neither fair nor reasonable to ask Mozilla to design a policy for situations that Mozilla has no activity in, has no visibility in, and has no influence in. I've admittedly presumed when you say "smaller devices" you're talking "IoT", since it's demonstrably false for the space of 'mobile' and demonstrably false for the space of 'small device' (e.g. Chromecast, Amazon FireTV, Roku), which are ostensibly small devices. It also doesn't apply to the 'smaller still' line of devices - for example, Google's Brillo framework is smaller overhead than that of Chromecast/FireTV, and yet still manages to find a reasonable trust store without compromising. It's also worth noting that these devices (which Mozilla does not develop code for, AFAIK) can further optimize their handling by treating roots as trust anchors (Subject + public key), the same way that NSS trust records are expressed, rather than storing the full certificate. NSS's libpkix was certainly designed for this, although I believe mozilla::pkix requires a full cert? Still, it means the cost is not the 560K of the full root store, but far les. Of course, it's completely unreasonable to talk about the constraints of IoT security on the internet when many of the devices being produced lack a basic capability of updating or security fixes. If you want to posit that these devices 'divide the internet' (as you suggest), then the first and foremost you must acknowledge the potential harm and self-inflicted wounds these devices are causing, before it be suggested that it's Mozilla's responsibility. > In particular, Mozilla should put into place a mechanism to ensure that it > doesn't end up with ~400 government roots, instead of just hoping that 200 > governments don't apply. Apologies if you feel I'm mischaracterizing your response, but the only (technical, policy) argument that you seem to positing is that "It's hard for IoT devices to access the Internet if there's a lot of roots". How is that Mozilla's responsibility (which isn't in that space), and what other reasons are there for prohibiting ~400 roots, beyond that? How or why is this not a problem that the IoT device manufacturer can/should solve? Now, that said, I'm extremely sympathetic and deeply appreciative of the fact that the Mozilla Root Inclusion Policy has historically been operated in the community-at-larges interest, and not strictly Mozilla's interests. This has allowed a variety of Linux distributions, for example, to reuse the Mozilla store as a canonical root of trust for their users. So if there as an argument of "Mozilla's policy X would make it hard for downstream user Y to consume and reuse the trust store", then I think that's entirely reasonable. But I don't think it's fair to suggest that Mozilla solely bears responsibility for changing to accommodate downstream user Y, nor is it clear if there even is a downstream user Y in this hypothetical discussion of "smaller" devices in order to actually weigh the technical or policy tradeoffs. For example, your proposed "Don't allow non-global CAs into the root program, because small devices" fails to account for why CAs enter the non-global market to begin with. If you review the policies, you will see it's because many of these CAs wish to target specific classes of users for which they can employ a more rigorous form of request validation than required by the Baseline Requirements, often to enable new classes of services that cannot be directly served by the commercial CA market according to the security/threat model of their constituents. Look at CNNIC, which primarily serves a domestic Chinese userbase, and their policies and practices related to validating the identity of the requester in a way that's specialized and tailored to the identity structure employed in China. Or look at many of the CAs participating in ETSI programs that allow PTC-BR and Qualified certificates (such as those in the PKIoverheid program). These CAs employ verification and validation techniques specific to their regional security needs. Now, if the only option for recognizing these certificates was that these CAs would have to be globally accessible / serve a global market (again, a definitional issue that is surprisingly hard to pin down if you work through it), then the natural outcome of this is policies that go from: "We serve [population of users X] and employ [more rigorous method Y]" to "We serve all users globally. For [population of users X], we employ [more rigorous method Y]. For [everyone else], we employ [as little as possible]." The "as little as possible" isn't because they're apathetic, but because that's the minimum required of them in order to satisfy the needs of "population of users X" by being included in the trust stores. And for many of these CAs, their knowledge and expertise is in [more rigorous method Y] than it is in the [as little as possible], which can easily be seen when reviewing CAs' policies or CAs' misissuances. My goal is not to dismiss your arguments as irrelevant (as they aren't, they're highly relevant and I totally appreciate you bringing them up), but to show that in the IoT space, both fragmentation and security issues are already incipient, and viable alternatives exist, and that in a "serve a global user case" has a greater chance of harm than help, since it requires either an element of lipservice (on the CA) or of arbitrary and capricious judgement (in the case of Mozilla operating the root policy and determining whether or not it's "global" enough). _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
