Hi Kathleen, My take on this is that any information that is relevant to a CA's conformance (or lack thereof) with the BRs (or any other part of Mozilla's inclusion criteria) needs to be disclosed to those who are passing judgment on the suitability of the CA for inclusion in the Mozilla trust store. If "the public" (or at least that subset which is subscribed to and participates on this list) are deemed to be "passing judgment", then yes, that information needs to be publically disclosed.
At this point, though, there shouldn't be any CAs with an adverse finding in their audit report. The audit done by Feb 2013 could list adverse findings, but the next audit statement (which was due in Feb 2014 -- six months ago) should have been clean and without qualification. Any CA who isn't willing to hold up their audit report to the world and say "See! We're clean!" is eligible for removal, either because their audit is out of date (by at least six months) or else is documented to not be in conformance with the BRs. On an unrelated point, I'd like to thank you, Kathleen, for the work you do in this area. Going over the minutiae of audit reports can't be a particularly fun job, but it *is* a very necessary one, so thanks for being the one who does it. - Matt On Tue, Aug 26, 2014 at 11:35:27AM -0700, Kathleen Wilson wrote: > I am running into a problem with BR audit statements that list > details about issues that have been found. > > https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Baseline_Requirements > "...The first BR audit for each CA and subCA may include a > reasonable list of BRs that the CA (or subCA) is not yet in > compliance with. ..." > > The problem is that some BR audit statements provide information > about the CA's BR non-conformance that the CA considers to be > sensitive (and non-publishable) information. > > As you know, Mozilla's policy requires public-facing audit statements. > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ > "6. ... provide public attestation of their conformance to the > stated verification requirements ..." > > So, I need a way forward that enables the CA to provide the required > BR audit statement without publicly disclosing sensitive > information. > > Just brainstorming... > > Would it be OK to accept public-facing BR audit statements that have > the information about the issues redacted? > > In the spreadsheet of included roots, I could add a column to list > BR section numbers that were in the redacted information. > > I will appreciate thoughtful and constructive input on this topic. > > Kathleen > -- > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
