CA/Audit Statements

Audit Letter Content

CA Audits are one of the primary mechanisms relied upon by Mozilla to ensure that a CA is operating securely and in compliance with our policies. CA audits and audit statements must comply with the following requirements.

• Section 3 of Mozilla's Root Store Policy
• Section 5.1 of the Common CCADB Policy.
• Section 8 of the CA/Browser Forum Baseline Requirements, if the root certificate has the Websites (TLS/SSL) trust bit enabled.

Format Requirements:

• SHA-256 Fingerprints
  • MUST: No colons, no spaces, and no line feeds
  • MUST: Uppercase letters
  • MUST: be encoded in the document (PDF) as text searchable, not an image
• Dates
  • Month DD, YYYY example: May 7, 2016
  • DD Month YYYY example: 7 May 2016
  • YYYY-MM-DD example: 2016-05-07
  • Month names in English
  • No extra text within the date, such as “7th” or “the”

Audited Locations

Both ETSI and WebTrust Audits should:

• Disclose each location (at the state/province level) that was included in the scope of the audit or should have been included in the scope of the audit, whether the inspection was physically carried out in person at each location, and which audit criteria were checked (or not checked) at each location.
  • If the CA has more than one location in the same state/province, then use terminology to clarify the number of facilities in that state/province and whether or not all of them were audited. For example: "Facility 1 in Province", "Facility 2 in Province, Facility 3 in Province" or "Primary Facility in Province", "Secondary Facility in Province", "Tertiary Facility in Province".
    • The public audit statement does not need to identify the type of Facility.
    • "Facility" includes: data center locations, registration authority locations, where IT and business process controls of CA operations are performed, facility hosting an active HSM with CA private keys, facility or bank deposit box storing a deactivated and encrypted copy of a private key.

Audit Lifecycle

Mozilla's Root Store Policy states the following requirements which apply to root certificates and all intermediate certificates that have at least one valid, unrevoked chain up to an included root certificate and which are technically capable of issuing working server or email certificates as described in section 1.1 of Mozilla's Root Store Policy .

• Before being included and periodically thereafter, CAs MUST obtain certain audits for their root certificates and all of their intermediate certificates that are technically capable of issuing working server or email certificates.
• Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually from the time of CA key pair generation until the CA certificate is no longer trusted by Mozilla's root store.
  • A CA certificate is considered to be trusted by Mozilla's root store as long as it is not expired, not in OneCRL, and either is directly included in Mozilla's root store or chains up (via subject/issuer) to another certificate that is included in Mozilla's root store.
    • A CA certificate that has the Websites trust bit enabled is considered to be trusted by Mozilla's root store as long as Firefox continues to treat is as either a trusted root certificate or a trusted intermediate certificate. Reference: How Firefox Performs Certificate Verification and path construction
  • Note: If a CA stops providing audit statements for a root certificate for any reason, then the certificate may be added to OneCRL in addition to being removed from Mozilla's root store.
• Successive audits MUST be contiguous (no gaps).
• Audit reports which are being supplied to maintain a certificate within the Mozilla root program MUST be provided to Mozilla via the CCADB within three months of the end date of the period.
• For Intermediate Certificates only: If the CA has a currently valid audit report at the time of creation of the certificate, then the new certificate MUST appear on the CA's next periodic audit reports.

Other Audits:

• Point-in-Time Audits: Point-in-time audit statements may be used to confirm that all problems previously identified by an auditor in a qualified audit statement have been corrected. However, a point-in-time audit does not replace the period-of-time audit.
• Readiness Assessment: See section 8.1 of the CA/Browser Forum's Baseline Requirements.

Audit Letter Validation

The contents of this section and its sub-sections have been moved to https://www.ccadb.org/cas/alv.

Root Certificates

This section has been moved to https://www.ccadb.org/cas/alv#root-certificates

Intermediate Certificates

This section has been moved to https://www.ccadb.org/cas/alv#intermediate-certificates

Common ALV Findings

This section has been moved to https://www.ccadb.org/cas/alv#common-alv-findings

Audit Delay

An Audit Delay is when one or more of the following requirements in section 3.1.3 of Mozilla's Root Store Policy cannot be met:

• "Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually."
• "... MUST be provided to Mozilla via the CCADB within three months of the point-in-time date or the end date of the period."

If a CA fails to deliver audit statements to Mozilla when they are due, Mozilla may take action to reduce the risks this presents to our users. The following guidance is intended for CAs in such a situation.

When a CA realizes that their audits will be delayed by a force majeure, Mozilla expects the CA to promptly disclose the issue, to provide regular updates, and to remain fully compliant with all other aspects of the Mozilla Root Store policy. CAs that are unable to deliver timely and complete audit statements should arrange with their auditors to supply Mozilla with partial information whenever possible, via publicly-available audit statements listing qualifications, agreed-upon procedures (AUP) reports, or similar partial reporting mechanisms (described in more detail below).

The CA must file an incident bug in Bugzilla to provide an Incident Report explaining the situation with their audits, mitigations that have been or will be implemented, and their plan to move forward in reaching compliance again.

• Whiteboard = [ca-compliance][audit-delay]
• For audit delays due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][audit-delay][covid-19]

Minimum Expectations

Situations will be considered and treated on a case by case basis.
The audit statement needs to clearly indicate which audited locations were and were not audited, and whether the inspection at each location was physically carried out in person, and which audit criteria were checked (or not checked) at each location.

ETSI Audits

Guidance provided in mozilla.dev.security.policy included the following:
If facilities can’t be audited by auditors of the CAB in person, possible alternatives are:

• “Network-assisted auditing techniques” are possible (ETSI EN 319 403, 7.4.1.2) or
• CAB may subcontract auditors that do not fall under the restriction, if they fulfil the auditor requirements. The CAB always remains fully responsible for such outsourced activities. (ISO/IEC 17065, 6.2.2 ).

If such alternatives were accepted by the CAB to provide reasonable assurance with regard to the requirements to be audited, this would result in a normal audit conclusion and would not be visible on an audit attestation letter.

An ETSI audit shall be performed in any case making sure that everything which reasonably can be audited will be audited - there is especially no restriction to do a full Stage 1 document audit. If facilities cannot be audited by auditors of the CAB in person and the two alternatives stated above are not possible or the CAB does not regard them to provide reasonable assurance with regard to the requirements to be audited in order to draw a reasonable audit conclusion this shall be documented in the audit report.
In any case an ETSI Audit Attestation Letter (AAL) shall be issued for the required audit period clearly stating in case limitations have been encountered by the auditor: the type of the limitation (e.g. control not audited in person or not audited at all) and description of the limitation (e.g. which controls were not covered in person or not covered at all).

After audit restrictions have been lifted: An ETSI audit shall be performed as soon as restrictions have been lifted. It is possible to re-use the original audit results and perform an additional audit just with regard to the non audited requirements (ISO/IEC 17065, 7.4). Usually, the period during which this is possible is limited by the CAB (ACAB’c: 6 month). Once the original audit becomes too old, a completely new audit would be necessary. Therefore, the ETSI audit shall

• either be focused on the parts not covered throughout the previous audit as stated in the AAL and comprise the same audit period as stated in the last report. In this case an amendment AAL for the original period would to be issued even it is dated more than 3 month after the end of the audit period.
• or comprise the full audit scope of an ETSI audit and the audit period starting with the same begin date as stated in the last report. In this case a new AAL will be issued replacing the previous one and resulting in an extend period of more than 12 month.

Please note: Such an extend period would only be possible, if a new full audit has been performed (covering the time of the original period plus the extension till the last day of the audit).

For more guidance please refer to www.acab-c.com or send your request to cabforum@acab-c.com.

WebTrust Audits

Guidance provided in mozilla.dev.security.policy included the following:
Ultimately, when an auditor is not able to obtain assurance on the entire scope of the engagement, and realizing a carved out approach is not permitted in a WebTrust audit, for example, when a certain data center is not able to be visited to observe controls operating and underlying documentation, the auditor will not be able to provide an unmodified/unqualified/clean opinion and the client would not be able to display the WebTrust seal. In these situations, the auditor would include an explanatory paragraph that details what gave rise to the scope limitation and issue one of the following modified opinions:

• Qualified opinion (when conditions are least severe but significant enough to mention), stating an except for paragraph explaining the condition(s) arising from the scope limitation, such as not being able to test the data center.
• Adverse opinion (when conditions are more severe), stating that the conditions are such that due to the severity of the scope limitation, the auditor states controls are not operating effectively and they were not able to satisfy themselves that the necessary controls were able to operate.
• Disclaimer of opinion (when conditions are most severe), stating that the auditor is unable to form any opinion due to the nature of the scope limitation.

If the potential threat of a scope limitation is primarily due to an auditor not being able to travel to perform necessary testing, as with the Coronavirus, there are potential remedies for the auditor to consider, including, but not limited to:

• Using the work of another auditor, whereby the lead auditor verifies the independence, qualifications and technical competency of another firm that can do a portion of the work, and the lead auditor directs the work, plans, supervises and reviews the other auditor’s work, taking ultimate responsibility. In this case, no mention of the other firm is made in the report as the lead auditor is taking responsibility for the other firm’s work.
• Using technology to observe physical controls and underlying documents/artifacts via remote means, such as video. In this case, the auditor must ensure the authenticity, integrity, security and confidentiality of the transmission.

Auditor Qualifications

Section 3.2 of Mozilla's Root Store Policy says: "Mozilla requires that audits MUST be performed by a Qualified Auditor, as defined in the Baseline Requirements section 8.2."

Section 8.2 of the Baseline Requirements says: The CA’s audit SHALL be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills:

1. Independence from the subject of the audit;
2. The ability to conduct an audit that addresses the criteria specified in an Eligible Audit Scheme (see Section 8.1);
3. Employs individuals who have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function;
4. (For audits conducted in accordance with any one of the ETSI standards) accredited in accordance with ISO/IEC 17065 applying the requirements specified in ETSI EN 319 403;
5. (For audits conducted in accordance with the WebTrust standard) licensed by WebTrust;
6. Bound by law, government regulation, or professional code of ethics; and
7. Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage.

Providing Auditor Qualifications

Version 2.7.1 of Mozilla's Root Store Policy requires CAs to have their auditor provide information about the auditor's qualifications when they provide audit statements. The information needs to be sufficient for us to see that the requirements listed above have been met by the audit team, but does not need to specifically name the individuals on the team, other than the lead auditor who signs the audit statement. The Audit Team may consist of one person provided that the person meets all criteria set out above and that there is an audit quality reviewer.

CAs must submit a summary of the Audit Team's qualifications and experience, as outlined below with respect to the audit. The information can also be provided as part of the audit result documentation, like the ETSI Audit Attestation Letter (AAL), or as a supplement to the WebTrust Assurance Report.

• Date that the audit report was signed
• Full name of the CA that was audited
• Name and address of the audit firm or Conformity Assessment Body (CAB)
• Audit Criteria, e.g. ETSI / WebTrust
• Proof of audit firm or CAB Accreditation (URL), see paragraphs below.
• Name of Lead Auditor (except where prohibited by law or other public policy, in which case, we ask that you not provide any personally identifiable information)
• For the Audit Team and the Audit Quality Reviewer, qualification information such as:
  • Number of Audit Team Members
  • Academic qualifications or professional training received
  • Average Years of Auditing Experience auditing trust services or similar information systems
  • Experience, Special Skills, and Qualifications (e.g. audit/assessment principles and functions, information technology, software development, trust services, public key infrastructure, CA operations, and information security including risk assessment/management, network security, physical security, etc.)
  • Credentials, Designations, or Certifications (e.g. CPA, CISA, CITP, CISSP, CCSP/CCA/CCP, etc.)
• How the Audit Team and team members are bound by law, regulation or professional standards to render an independent assessment of the CA (e.g.https://pub.aicpa.org/codeofconduct/Ethics.aspx# 0.300.050 Objectivity and Independence; CPA Canada, Rule 204; or Annex A of ETSI EN 319 403/403-1, respectively)
• Whether the Audit Team relied on any third-party specialists or affiliate audit firms, and if so, their names and where they performed services.

Verifying WebTrust Auditor Qualifications

For WebTrust auditors, a representative of Mozilla confirms that the auditor's name and country are listed in CPA Canada's Licensed WebTrust practitioners web page.

Send email to webtrust@cpacanada.ca for more information about this list or about the process to become a licensed WebTrust practitioner.

Verifying ETSI Auditor Qualifications

For ETSI auditors, a representative of Mozilla confirms that the auditor's name and Accreditation Attestation are listed in the ACAB'c CAB-member List.

Send email to secretary@acab-c.org for more information about this list or about the process to become a accredited auditor for Trust Services under the EU eIDAS scheme following ETSI normative requirements as applicable to serve the CA/B Forum ecosystem and the Mozilla Browser Root Store Policy.

Comprehensive Check

The following additional check is only needed if the auditor's name and Accreditation Attestation are not listed in the ACAB'c CAB-member List.

• Require the ETSI auditor to provide a comprehensive written explanation about why they are not listed in not listed in the ACAB'c CAB-member List.
• The auditor must provide a rationale clearly referring back to all of the following:
  • European Accreditation to demonstrate they act under the EU accreditation scheme,
  • ISO/IEC 17065 plus ETSI EN 319 403-1 to demonstrate they are accredited/allowed to audit publicly trusted CA/Trust Service Provider according to
    • ETSI EN 319 401 and ETSI EN 319 411-1 and
    • ETSI EN 319 411-2 for QWACS certificates according to the EU eIDAS Regulation 910/2014.
• Review the documents and explanation.
• Request external review from ACAB’c to provide opinion about the CAB's accreditation.