On Tue, May 16, 2017 at 10:04 AM, Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > On 16/05/2017 18:10, Peter Bowen wrote: >> >> On Tue, May 16, 2017 at 9:00 AM, Jakob Bohm via dev-security-policy >> <dev-security-policy@lists.mozilla.org> wrote: >>> >>> 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. >> >> >> What "binary file" are you referring to? NSS is distributed as source >> and I'm unaware of any binary file used by the NSS library for trust >> decisions. >> > > Source code for Mozilla products presumably includes some binary files > (such as PNG files), so why not a binary database file that becomes > that data that end users can view (and partially edit) in the Mozilla > product dialogs. Existence of a file named "generate_certdata.py", > which is not easily grokked also confused me into thinking that > certdata.txt was some kind of extracted subset. > > Anyway, having now looked closer at the file contents (which does look > like computer output), I have been unable to find a line that actually > expresses any of the already established "gradual trusts". > > Could you please point out where in certdata.txt the following are > expressed, as I couldn't find it in a quick scan: > > 1. The date restrictions on WoSign-issued certificates. > > 2. The EV trust bit for some CAs.
These are not included in certdata.txt for the reasons described earlier -- they are application-only things, not Mozilla platform things. I know it is non-obvious, but there are two parts of processing certificates in many applications: 1) The certificate is passed to the platform library (along with some other data, like name to validate) and a result is returned. 2) Then the application makes further decisions. This is not only true for Chrome but also Firefox. EV information is decided by the application. See https://dxr.mozilla.org/mozilla-central/source/security/certverifier/ExtendedValidation.cpp for information about deciding on EV. See https://dxr.mozilla.org/mozilla-central/source/security/certverifier/NSSCertDBTrustDomain.cpp#898 for additional checks (outside NSS) added by Firefox. This could be moved into NSS, but there hasn't been demand to do so at this point. It could also be added as unused attributes in certdata.txt (which is the master), but no one has volunteered extended this to support the additional info and add the necessary tests to ensure that it doesn't go stale. 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. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
