On Tue, May 16, 2017 at 10:24 AM, Alex Gaynor <agay...@mozilla.com> wrote:
> Hi Ryan, > > I've lost the thread on how this addresses Cory's original problem > statement, if you could spell that out that'd be very helpful. > Sure, the original problem statement arises from the fact that CAs have 'limited trust' applied to them, and wanting to express this for use in other applications which consume the Mozilla trust store. First and foremost, in order for that limited trust to be relevant/applicable, we must presume these clients are capable of being updated. If they weren't, any expression of limited trust would be irrelevant, since they wouldn't consume the update. At best, it would simply ensure that, at a fixed point in time (e.g. when the application was built), to the best of the app devs knowledge, all roots were constrained appropriately. As we've seen from CA issues - whether Symantec or the top 5 CAs responsible for >90% of the Web's public trust - there's a whole host of complex scenarios involved with distrusting. Cory's problem also highlighted that there are a host of non-web consumers of the Mozilla trust store, and their compatibility needs are different. By posing the 'shorter lived root' scenario, we get to a scenario where a device that is staying up to date (e.g. tracking the Mozilla store at a frequency where 'limited trust' is applicable) is able to migrate off 'problematic' roots sooner, by providing a transition path that is constantly moving forward. Thus, rather than needing to express 'limited trust' for roots (which otherwise remain trusted), we provide a faster path to distrusting the problematic roots, independent of whatever trust is afforded the organization (which might have 'new' roots that are less/unconstrained) This is in conjunction with the expressions already found in certdata.txt which applications can use (e.g. name constraints). It doesn't address scenarios like whitelisting (e.g. CNNIC), since those are application-specific anyways. The proposal is meant to, in parallel, reduce the 'legacy compat risk' by providing a path to allow both 'legacy' and 'modern' clients to operate side-by-side, without indefinite expressions of constraints on 'legacy' roots. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
