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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
