On Fri, Jun 19, 2015 at 1:38 PM, Ryan Sleevi < ryan-mozdevsecpol...@sleevi.com> wrote:
> 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. > <snip> > 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), + name constraints, at least. This thread is about, AFAICT, making the amount of name constraint information in the root database quite large, and making it necessary to update that name constraint information frequently. What you're suggesting as far as minimizing the amount of data stored per root is a good one. Having to store and update sets of name constraints for each root seems counterproductive to that, to put it mildly. > 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? > I agree that it is wasteful to encode trust anchors as full X.509 certificates. Many things in Gecko expect the trust anchors to be encoded that way, though, so in order to accommodate that and to keep things simple, mozilla::pkix work like that. This is one of the improvements I'm looking forward to with the certificate verification stuff you are working on now. > 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. > I agree that we should consider devices designed to have terrible security to be out of scope. Not every device is inherently non-secure, though. > 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. > Any time any root program adds a new root, it costs many people something in terms of (a) increased risk of mis-issuance by the new root, (b) increased update costs, (c) increased resource consumption, and (d) increased compatibility risk. It's worth considering whether the addition of a root is justified given these costs. > 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]." > With what I'm suggesting in having a "best N" approach, the new CA's "as little as possible" would have to be better than one of the N best CAs "as little as possible" in order to even be considered. I also think it is likely that Let's Encrypt and similar initiatives will put root programs in a better position to hold out for "more rigorous" AND "global," at least for future CA inclusions. If we raise the "as little as possible" bar high enough, then I'm not sure it's worthwhile to bother considering "more rigorous" anyway. > 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). > Saying whatever is expected to get included is already part of what the organization buying inclusion to the root programs pays for; i.e. we already dealing with the lip service problem. Root programs already reserve the right to make arbitrary judgements. I think risking being too arbitrary in assessing the marginal utility and risk/reward as part of an inclusion request, with a default "no" policy, seems less harmful than just accepting everybody who writes down the right things in the application and passes the audits. Cheers, Brian _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
