On Tue, Aug 26, 2014 at 1:24 PM, Kathleen Wilson <kwil...@mozilla.com> wrote: >> On Tue, Aug 26, 2014 at 1:09 PM, Kathleen Wilson <kwil...@mozilla.com> wrote: >> >>> BR 9.5 – 1024-bit certs with validity beyond 2013 (in order to support >>> legacy customer apps) >>> >>> BR 13.2.6 - OCSP giving status “good” for unknown serial numbers. >>> >>> BR 16.5 - multi-factor authentication for *all* accounts capable of >>> directly causing certificate issuance >>> >>> BR 17.5 - The audit period for the Delegated Third Party SHALL NOT exceed >>> one year >>> >>> BR 17.8 – audits on at least a quarterly basis against a randomly >>> selected sample of the greater of one certificate or *at least three >>> percent* of >>> the Certificates issued by it during the period commencing immediately after >>> the previous self-audit sample was taken >>> >>> BR 11.2 – re-verifying identity for cert renewal requests > > This is the level of information I could list for each CA who had a redacted > section in their BR audit. > > The problem is that the BR audit statements have further details that the > CAs do not want published. > > I'm just exploring how to get past the current situation of CAs not being > able to provide public-facing BR audit statements for their first full-year > BR audit.
The Mozilla CA Communcation in Jan 2013 asked each CA whether they comply with the BR. (https://wiki.mozilla.org/CA:Communications#January_10.2C_2013 question 2). According to the results spreadsheet, a number of CAs disclosed non-compliance with remediation dates (Option C under Action 2). I would propose than any findings that match those called out in that spreadsheet be redacted. For example, unfairly picking on a CA, Unizeto said they would have the OCSP requirement met by Oct 2013. If their audit shows that they did not meet BR 13.2.6 until September 2013, then this would match the spreadsheet and the finding would be redacted. However if, again unfairly picking a CA, A-Trust, who chose option A, had findings, these would not be redacted. This would allow the finer/more sensitive details of previously disclosed items (for example the names of Unizeto's sub-CAs who didn't have OCSP) to not be further disclosed. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
