On Wed, Jan 24, 2018 at 4:41 PM, Wayne Thayer <wtha...@mozilla.com> wrote:
> To the best of my knowledge, the only "standard" sanction we have today is > complete distrust of a root or intermediate, and in practice that rarely > happens. On the surface, the idea of lesser sanctions like removing the EV > indicator for some period of time is appealing to me, but I think we need > to take a step back and discuss whether or not this is really a good idea. > Would Mozilla be better off in the long run having lesser sanctions readily > at our disposal? > > First off, I question if we would really use lesser sanctions more often. > I think we would still want to coordinate their implementation with other > user agents, and that is a tedious process. > While probably not your intent, that does mean that any program requirements Mozilla imposes - for example, disclosing the BR validation method used - that aren't also adopted by other Root Programs - would be somewhat toothless. Why would another user agent take an action against a root that failed to disclose the methods used, if they didn't require that? And if taking action requires that degree of coordination, to what end? > Second, what might be the unintended consequences? For example, would CAs > shift their focus from maintaining trust to avoiding sanctions? > So, when the only option is distrust, and when it's seen as a heavy option (rather than what I think it should be - a regular occurrence until things improve), then the only thing a CA has to worry about is not being so bad that you get distrusted. We know you shouldn't be PROCERT bad [1] , but you can seemingly be Visa bad [2] - their first audit wasn't until September 2016, despite Mozilla clearly communicating expectations in May 2014 [3], and they still weren't compliant by the time of discussion. So it doesn't _seem_ like CAs are focused on maintaining trust, per-se - more like maintaining the status quo, and only making changes when required, where "required" means threat of removal, which is a high-bar that apparently Visa did not rise to (sadly, surprisingly). Further, the argument seems to have been accepted that once you're in, it should be harder to remove than what would normally be a complete disqualification for a new entrant. Sanctions, on the other hand, help balance that - by actually and effectively communicating that requirements are requirements, and leveraging the host of options available to a Root Store appropriate to their role as gatekeepers of trust. A UA/Root Store is ultimately balancing the risk of 'past certificates' with the risk of 'new certificates' - and making it easier to more rapidly mitigate the risk of 'new certificates' (such as distrust periods and requiring new roots, limiting the types of issuance accepted, etc) are effective means of minimizing the risk to 'past certificates'. Alternatively, abilities to more effectively mitigate 'past certificates' - such as whitelists (despite the size hit) - can also help express that requirements _are_ requirements. The challenge is the changes must be meaningful, and not just things to dance around. Preventing new certs and requiring new roots are an effective way of actually minimizing that legacy-compat risk, while providing real protection [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/Ymrpsm7s5_I/Gki--pwHBgAJ [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/NNV3zvX43vE/rae9kNkWAgAJ [3] https://wiki.mozilla.org/CA/Communications#May_2014 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
