On 2014-08-27 18:15, Kathleen Wilson wrote:
Based on the discussion so far, I think the answer is that the CAs need to work with their auditors to create a public-facing audit statement that does not have information in it that the CA considers sensitive, but that sufficiently lists the BRs that the CA is still working to conform with.
I agree with this too. I think it's important to know that there are problems and that they are being worked on.
I've been checking certificates and filing bugs in Mozilla's bugzilla, so all those things are currently also public. But I try to only put there what I think is needed, and if the CA wants more detailed information I'm happy to send it to them directly instead of via bugzilla.
The wiki you pointed to about the baseline requirements says that the first audit might have a list of things it's not in compliance with and that we expect the next one confirm they have been fixed. Do such reports explicitly confirm that they have been fixed?
It seems to give the impression that next audit report is not supposed to give a (public) list of requirements it's not in compliance with. But since the requirements change over time, for instance 1024/2048 bit, SHA1/SHA256, procedures and used software might change over time, and so on, I expect that a next audit might find new issues that were previously not found. So I expect every report to give such a list, or explicitly say that no problems where found. And that would go for all the audit reports.
Kurt _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
