The first thing that comes to mind is to define an intermediate representation of per-root constraints, that Mozilla can distribute alongside certdata.txt.
The simplest piece would be name constraints, but incorporating things like CT constraints and date-based constraints would clearly be useful. I think the tricky part would be deciding which things should go into the data and which should go into the code. The spectrum could run all the way from having the data store store all of "one Google and one non-Google log, where certificates whose length is over X days require Y SCTs, etc." to something as simple as "apply [the standard for this client] CT policy" and having clients decide/iterate on what their preferred CT constraint policy is. (I suspect the right answer is closer to the latter, but I don't manage a client that performs TLS validation.) I guess there's actually an RFC for something like this? https://tools.ietf.org/html/rfc5914 But I haven't looked at it in depth to see whether it's a good solution for this problem. I also don't think it requires an RFC to get something started. -- Eric On Tue, Oct 18, 2016 at 2:13 PM, Ryan Hurst <ryan.hu...@gmail.com> wrote: > Tom, > > On the topic of tooling I have a console tool, and library, that can be > used to parse and filter various certificate stores, you can find it here: > https://github.com/PeculiarVentures/tl-create > > Ryan > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
