Mozilla Root Store Elsewhere (Was Re: StartCom & Qihoo Incidents)

[Tom Ritter]

On 18 October 2016 at 08:00, Jakob Bohm <jb-mo...@wisemo.com> wrote:
> On 18/10/2016 14:35, Gervase Markham wrote:
>>
>> On 17/10/16 16:35, Jakob Bohm wrote:
>>>
>>> In the not so distant past, the Mozilla root program was much more
>>> useful due to different behavior:
>>>
>>> 1. Mozilla managed the root program based on an assumption that relying
>>> parties would use the common standard revocation checking methods
>>> *only* (regular CRLs as present since Netscape created SSL and OCSP).
>>
>>
>> Now is not the time to re-debate the failings of those methods, but
>> please don't pretend you don't know why this change was made.
>>
>
> I wasn't in this instance, simply noting the following problem: By
> assuming all relying parties run code that implements Mozilla's other
> revocation methods (OneCRL, custom notBefore checks etc.), the root
> list published by Mozilla becomes less useful for relying parties whose
> applications do not.


I'm sympathetic to this - it's unfortunate that we've had to bolt on
certificate validation checks that do not appear in any standardized
form, in any central location, and differ from client to client. It
makes 'the most dangerous code in the world' even harder to get
correct. It seems like more and more of CA/HTTPS related ecosystem
could benefit from an equivalent to caniuse.com

But I'm not sure what Mozilla could do to help downstream users of the
root store? What would make you happier? Projects who blindly import
and trust it will be subject to the default decision Mozilla takes -
sure. (And hopefully they have the prescience to delineate between
default-trust certs and default-don't-trust certs!)

Two things I can see would be:
- Carefully choose the action taken with the root store to be a 'keep
in the root store' choice or a 'remove from the root store' choice.
For example, WoSign would probably be in the 'remove' category and
then FF gets special processing code to accept WoSign under specific
circumstances.
- Have some additional comments or tooling that are designed for
downstream importers. Maybe a script that runs over the official file
converting it to other frmats (Java keystore, directory-of-certs, etc)
and prompts people 'This CA is subject to specific filtering in FF, do
you want to include it in the export?'

Are there other actionable things Mozilla could do to make things
better-by-default for downstream users?

-tom

[Ryan Hurst]

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

[Eric Mill]

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

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

[Ryan Sleevi]

On Tuesday, October 18, 2016 at 11:42:17 AM UTC-7, Eric Mill wrote:
> 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.

It's not bad, for sure, but I think both Microsoft and Google's experiences with specialized constraints and extensions aren't always fully represented by 5914. On a purely pragmatic level, it is a real pain to encode those constraints - which is an ongoing issue itself with the NSS_TRUST flags and how the binary representation of the structure is, is it extensible, etc.

The TL;DR: is that each CA incident has resulted in a special response, always with the goal of minimizing user impact relevant to the significance of the incident.

But it's doable, if we don't hate ASN.1 too much :)

[Jakob Bohm]

On 18/10/2016 20:40, Eric Mill wrote:
> 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 don't know the format of certdata.txt (since I am not the one who
clones it, or one of its historic formats(!)), but perhaps a simple
solution would be if that file was allowed, for each trust bit, to
specify the "third boolean value": Maybe, aka "X", aka "?".

That would signify, that for that particular trust bit, that there are
additional rules that a cloner need to look up and consider how this
applies to inclusion in his/her particular repository.

There should also be a web page, updated *before* the NSS code, with
those additional rules, as decided by the module owner.

Also there should obviously be a ChangeLog for certdata.txt split into
a "big news" document containing messages such as

"as of version X.Y.Z, the codesigning trust bit is no longer valid, and
roots that are only trusted for code signing have been omitted as if
they were distrusted, even though they might not be, Mozilla just isn't
tracking them anymore (Bugzilla #12345678)"
"As of version X.Y.Z, the trust bits columns in certdata.txt may now
contain the character (whatever) to indicate that trust for that
purpose is limited by a specific rule listed on the web page
https://foo.mozilla.org/bar/baz. Changes to those rules will be listed
in the certdata ChangeLog even if the certdata.txt line was technically
not changed (Bugzilla #12345678)"

While the main ChangeLog would also contain more normal changes such as:

"As of version X.Y.Z, WoSign was changed from trusted to maybe in
preparation for full distrust at a future date (Bugzilla #12345678)"
"As of version X.Y.Z, LetsEncrypt was added as trusted for TLS
(Bugzilla #12345678)"
"As of version X.Y.Z, certdata.txt is now encoded in UTF-8, previously
it was in ISO-8859-1 (Bugzilla #12345678)"
"As of version X.Y.Z, Geotrust root ABC was removed, because it is now
only trusted for codesigning, at the request of Symantec, and Mozilla
doesn't track codesigning (Bugzilla #12345678)"

(Of cause all of this would be in a more regular changelog format,
compatible with Mozilla internal procedures, the main point is to
include brief snippets that help downstream stores understand how a
change should be interpreted, with a special highlighting of changes
that affect the downstream import at a conceptual rather than just a
technical level).

Each of my examples above are examples of changes that could (and have
apparently in the past) lead downstream stores astray without that
tidbit of information.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded