> On May 16, 2017, at 7:42 AM, Jakob Bohm via dev-security-policy > <dev-security-policy@lists.mozilla.org> 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? Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
