I like this approach. You could either add a page in the policy document or include the information in the management assertion letter (or auditor letter) that gives information about the auditor’s credentials and background. I also like the idea of summary on what the auditor followed up on from the previous year. This could be helpful to document where an auditor changed between years to see what they reviewed that another auditor noted or to see where the auditor had concerns from year to year. It can track where the CA may have a re-occurring issue instead of something that is a one-off concern.
From: Ryan Sleevi <[email protected]> Sent: Monday, October 14, 2019 4:12 PM To: Ryan Sleevi <[email protected]> Cc: Jeremy Rowley <[email protected]>; Wayne Thayer <[email protected]>; mozilla-dev-security-policy <[email protected]> Subject: Re: Mozilla Policy Requirements CA Incidents In the spirit of improving transparency, I've gone and filed https://github.com/mozilla/pkipolicy/issues/192 , which is specific to auditors. However, I want to highlight this model (the model used by the US Federal PKI), because it may also provide a roadmap for dealing with issues like this / those called by policy changes. Appendix C of those annual requirements for the US Federal PKI includes a number of useful requirements (really, all of them are in line with things we've discussed here), but two particularly relevant requirements are: Guidance: Previous year findings Did the auditor review findings from previous year and ensure all findings were corrected as proposed during the previous audit? Commentary: Often, the auditor sees an Audit Correction Action Plan, POA&M, or other evidence that the organization has recognized audit findings and intends to correct them, but the auditor is not necessarily engaged to assess the corrections at the time they are applied. The auditor should review that all proposed corrections have addressed the previous year’s findings. Guidance: Changes Because the FPKI relies on a mapped CP and/or CPS for comparable operations, has the auditor been apprised of changes both to documentation and operations from the previous audit? Commentary: CPs change over time and each Participating PKI in the FPKI has an obligation to remain in synch with the changing requirements of the applicable FPKI CP (either FBCA or COMMON Policy) – has the participating PKI’s CP and CPS been updated appropriately? If there have been other major changes in operations, has a summary since the last year’s audit been provided or discussed with the auditor? This might be a model to further include/require within the overall audit package. This would likely only make sense if also adding "Audit Operational Findings" (which Illustrative Guidance for WebTrust now includes guidance on, but which ETSI continues to refuse to add) and "Audit MOA Findings" (for which "MOA" may be instead seen as "Mozilla Root Certificate Policy" - i.e. the things above/beyond the BRs). We've already seen WebTrust similarly developing reporting for "Architectural Overview", and they've already updated reporting for "Assertion of Audit Scope", thus showing in many ways, WebTrust already has the tools available to meet these requirements. It would similarly be possible for ETSI-based audits to meet these requirements, since the reports provided to browsers need not be as limited as a Certification statement; they could include more holistic reporting, in line with the eIDAS Conformity Assessment Reports. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
