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? 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 <> 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:
> Ryan
> _______________________________________________
> dev-security-policy mailing list

-- | @konklone <>
dev-security-policy mailing list

Reply via email to