On Tue, May 16, 2017 at 1:59 PM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On Tue, May 16, 2017 at 10:52 AM, Jakob Bohm via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > On 16/05/2017 19:36, Peter Bowen wrote: > >> > >> My experience is that Mozilla is very open to taking patches and will > >> help contributors get things into acceptable form, so I'm sure they > >> would be happy to take patches if there is demand for such. It is > >> fairly important that someone who is going to use the attributes put > >> together the patch, otherwise it may prove to be useless. For > >> example, I could easily create a patch that add a CKA_TRUST_FILTER > >> attribute that is designed to be fed into a case statement to indicate > >> the filter to be applied. Based on the code, it looks like I probably > >> needs a "cnnic" case, a "wosign" case, and a "globalsignr2" case. > >> This meets my needs, but it might not need your needs. > >> > > > > Ok, can you point me to any "graduated trust" actually present in > > certdata.txt ? > > See the CKA_TRUST_SERVER_AUTH, CKA_TRUST_EMAIL_PROTECTION, > CKA_TRUST_CODE_SIGNING, and CKA_TRUST_STEP_UP_APPROVED attributes in > CKO_NSS_TRUST class objects. They all represent non-binary trust of > roots, similar to that contained in the OpenSSL X509_AUX structure > mentioned much earlier in the thread. > And as for other forms of restriction, it has already been mentioned : https://wiki.mozilla.org/CA:Root_Store_Trust_Mods You can see an example of implementing this in https://bugzilla.mozilla.org/show_bug.cgi?id=1349705 One aspect that is no doubt non-obvious, but important to note, is that Mozilla NSS using applications are permitted to ship with alternative trust stores, since the trust store is dynamically loaded (certdata.txt is fed to certdata.c , which is then part of nssckbi.[dll/so], which is dynamically loaded by NSS) You can see this being used by applications such as p11-kit, which provide alternative 'nssckbi's which then allow for more complex root store management. Because of this, when Mozilla responds to a security incident, or needs to constrain something, they want to ensure that constraint is uniformly applied - e.g. regardless of the (independent) root store update. Hence the implementation within the application layer, which guarantees that _regardless of the basis of trust_, the constraint is applied. This is one way to do it. It's different than how Microsoft does it, which expresses the constraints in authroot.stl, but the implementation of those constraints in crypt32.dll (or related). In the Microsoft case, unless you update *both* the root store and the crypt32, you don't get the security update. Perhaps unsurprisingly, this is a common occurrence - in part, because fetching authroot.stl can use a different network or application code path than fetching the Windows Updates for crypt32.dll. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
