On 16/05/2017 17:10, Peter Bowen wrote:
On May 16, 2017, at 7:42 AM, Jakob Bohm via dev-security-policy
<[email protected]> wrote:
On 13/05/2017 00:48, Ryan Sleevi wrote:
And in the original message, what was requested was
"If Mozilla is interested in doing a substantial public service, this
situation could be improved by having Mozilla and MDSP define a static
configuration format that expresses the graduated trust rules as data, not
code."
Mozilla does express such graduated trust rules as data, not code, when
possible. This is available with in the certdata.txt module data as
expressive records using the NSS vendor attributes.
Not all such requirements can be expressed as data, not code, but when
possible, Mozilla does. That consuming applications do not make use of that
information is something that consuming applications should deal with.
I suggest you read and understand the OP in this thread, which is
*entirely* about using the Mozilla Root Store outside Mozilla code.
Yet you keep posting noise about using the Mozilla store with Mozilla
code such as NSS, with Mozilla internal database formats, etc. etc.
Just above you commented "Not all such requirements can be expressed as
code", which is completely backwards thinking when the request is for
putting all additional conditions in an open database in a *stable*
data format that can be easily and fully consumed by non-Mozilla code.
Jakob,
What I think Ryan has been trying to express is his view that this request is
not possible. A *stable* data format is unable to express future graduated
trust rules.
To see why Ryan likely has this view, consider the authroot.stl file used by
Microsoft Windows. The structure is essentially a certificate plus a set of
properties. The properties are name value pairs. The challenge in using this
file is that the list of properties keeps extending. New property names are
added on a fairly routine basis. For example, the last update added
NOT_BEFORE_FILETIME and NOT_BEFORE_ENHKEY_USAGE. This is great — we now know
that certain roots have one or both of these properties with both represent
some sort of restriction. However we have zero clue what they mean or how to
process them.
Now consider certdata.txt, the Mozilla trust store format. It is similarly
extensible, after all it is just a serialization of a PKCS#11 token. PKCS#11
has objects which each have attributes. Mozilla certdata.txt could take the
exact same path as authroot.stl and just add attributes for each new rule.
Imagine a new attribute on CKO_NSS_TRUST class objects called
CKA_NAME_CONSTRAINTS. This is contains DER encoded NameConstraints. If this
were suddenly added, what would existing libraries do? Probably just ignore
it, because they don’t query for CKA_NAME_CONSTRAINTS. Taking this to an
extreme, certain objects could even having attributes like
CKA_CONSTRAINT_METHOD with a value that is the name of a function.
While this would be stable and would express all the rules, it isn’t clear that
such is valuable to anyone because you need the matching code to query
attributes and do something with the value. It also can lead to a false sense
of security because using a new certdata.txt with an old library will not
actually implement the trust changes.
Does this help explain the problem?
Your post above is the first response actually saying what is wrong
with the Microsoft format and the first post saying all the
restrictions are actually in the certdata.txt file, and not just in the
binary file used by the the NSS library.
This is much more constructive than anything Ryan posted in this thread.
Thanks for this.
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
