CA/BR Audit Guidance: Difference between revisions

Jump to navigation Jump to search
Line 83: Line 83:
During evaluation of a CA's root inclusion or change request, Mozilla uses public audit statements to help confirm that the CA is in compliance with the stated verification requirements, the BRs, and Mozilla's policy. Therefore, when members of Mozilla's community find a problem with certificates in the CA's hierarchy that should have been noted in the audit statement (as an exception or point of non-compliance), the CA may need to be re-audited to confirm that the problem has been resolved.
During evaluation of a CA's root inclusion or change request, Mozilla uses public audit statements to help confirm that the CA is in compliance with the stated verification requirements, the BRs, and Mozilla's policy. Therefore, when members of Mozilla's community find a problem with certificates in the CA's hierarchy that should have been noted in the audit statement (as an exception or point of non-compliance), the CA may need to be re-audited to confirm that the problem has been resolved.


When egregious mistakes were overlooked by the auditor, or there are a significant number of oversights, or the auditor did not notice BR compliance problems with the root or intermediate certificates, then the CA must resolve the issues and be re-audited. For the re-audit the CA can '''either''' get re-audited by a ''different'' auditor, '''or''' have the current auditor provide an immediate plan for correction and compliance, and then present a mid-term partial audit following that plan. In either case, the auditor must provide documentation about steps they are taking to avoid making the same mistakes in future audits.  
When egregious mistakes were overlooked by the auditor, or there are a significant number of oversights, or the auditor did not notice BR compliance problems with the root or intermediate certificates, then the CA must resolve the issues and be re-audited. For the re-audit the CA can '''either''' get re-audited by a ''different'' auditor, '''or''' have the current auditor provide an immediate plan for correction and compliance, and then present a mid-term partial audit following that plan. In either case, the auditor must provide documentation about steps they are taking to avoid making the same mistakes in future audits. If the auditor fails to assure Mozilla that they have corrected the deficiencies in their auditing process, then their standing as a trusted auditor for the Mozilla root program may be jeopardized.


Non-compliance to the following policies are examples of mistakes that auditors must '''not''' overlook.
Non-compliance to the following policies are examples of mistakes that auditors must '''not''' overlook.
Confirmed users, Administrators
5,526

edits

Navigation menu