On 17/10/16 16:26, Kathleen Wilson wrote:
> ones who use NSS validation. I’m not sure what we can do about other
> consumers of the NSS root store, other than publish what we are doing
> and hope those folks read the news and update their version of their
> root store as they see appropriate for their use.
We cannot fix everyone else's code, but I think it would be reasonable
for us to produce and maintain a wiki page which complements
certdata.txt which gives all the other restrictions Mozilla recommends
on the roots therein.
> It will also impact CNNIC.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1177209#c13 So, does
> CNNIC's audit get grandfathered in? Or does CNNIC have to get audited
> by a different auditor before they can re-apply for full inclusion?
The audit report CNNIC has submitted covers the period from November 2,
2015 to February 29, 2016. Therefore, we would expect them to be
starting the process of getting another yearly audit in about 2 weeks
anyway, although it won't be done until next year.
I think the fairest thing is to allow them to proceed with the inclusion
application, get them in the queue, and follow through all the steps,
expecting that by the time they get to the end, their new audit (by
another auditor) will be completed. Assuming it is good, we can include
> ~~ I think we need to add an action item regarding making sure that
> all of the code and systems used by the CA are well-designed and
> updated, and fully meet the CA/Browser Forum’s Baseline
Well, we already require that they meet the Baseline Requirements, and
"updated" is covered by the Network Security Requirements which, for all
their flaws, are included by reference in the BRs. So that seems like a
no-op. And I don't know how to define "well-designed".
> Are there tests that we could require the CA to run/pass that would
> satisfy our concerns about quality of the code and systems?
Not really :-(
dev-security-policy mailing list