It adds a sentence to section 2.4 ("A "qualification" in a WebTrust audit or a "finding of non-conformity" in an ETSI assessment is also an incident.") and a new section 2.5 titled "Sanctions":
Mozilla MAY require revocation of those leaf certificates or intermediate certificates that suffered or that are considered defective because of the incident. Mozilla expects the timely remediation of the problems that caused or gave rise to the incident. Mozilla MAY require the CA operator to submit a plan of action with milestones or additional audits to ensure remediation and to regain confidence in the CA operator. Multiple incidents with the same underlying cause, however minor, may lead to sanctions. If a CA operator has failed to remediate the causes giving rise to an incident, Mozilla MAY impose sanctions, including but not limited to: adding certificates to OneCRL; removing trust bits from root certificates; and removing root certificates from the trust store.
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYqmEEx6Oz9Xk3QdoPB6mEnvwowGj5vdszPLG2tCpwGBQ%40mail.gmail.com.
Hi Ben,Maybe I’m misunderstanding, but I’m not sure I understand how this proposal relates to the issue that was filed?
As my comment on the issue at the time tried to capture, the scenario on the bug was about the expectations for CAs when they receive qualified audits, and how that may be treated.
However, your new proposal seems to suggest that Mozilla doesn’t normally require CAs to follow the BRs, or the prescribed actions of the BRs, except in rare circumstances. That is, several of the MAY actions here are MUSTs in the BRs.
Have I misunderstood the original issue that is filed? Or is this language perhaps tackling something different? I would be worried if this language was adopted as-is, as is seems mostly to lower expectations.
Is there any circumstance where any of the MAYs not already MUSTs in the BRs wouldn’t be appropriate? Is it necessary to even enumerate the actions Mozilla may take, for those that are optional, versus addressing them as they arise (e.g. in incident reports)?
As my comment on the issue at the time tried to capture, the scenario on the bug was about the expectations for CAs when they receive qualified audits, and how that may be treated.I believed that in response to this, we need to make clearer that qualifications in audits are "incidents," which need to be tracked in Bugzilla through to remediation. I think that many CAs have understood that this has already been the practice for several years, as evidenced by the incidents filed by CAs in Bugzilla, but again, we needed to make sure that it was stated in policy.
Is there any circumstance where any of the MAYs not already MUSTs in the BRs wouldn’t be appropriate? Is it necessary to even enumerate the actions Mozilla may take, for those that are optional, versus addressing them as they arise (e.g. in incident reports)?I'm inviting comments and suggestions on improving the language.
“Any matter discovered during the course of an audit giving rise to a qualification, a modified opinion, or a non-conformity, is also considered an incident and MUST be reported to Mozilla as soon as the CA operator is made aware. In some cases, there may be disagreement between the CA operator and the auditor on the nature or severity of the situation. However, CA operators MUST report these as incidents to Mozilla. In these circumstances, reported incidents may be resolved as INVALID, if Mozilla determines that there has been no non-compliance or that they are not a matter of concern.”
I deleted the section heading for 2.5 (Sanctions) and added to 2.4:
" Mozilla expects the timely remediation of the problems that caused or gave rise to the incident. In response to incidents, Mozilla MAY require the CA operator to submit a plan of action with milestones or to submit one or more additional audits to provide sufficient assurance that the incident has been remediated. Such audits will be expected sooner than the CA operator’s next scheduled audit, and thus may be expected to be for a period less than a year."
Added to 3.2 (Auditors): "Mozilla MAY, at its sole discretion, determine that an audit provided does not provide sufficient assurance that the requirements within this section 3 have been sufficiently met. In such circumstances, CA operators will be expected to obtain a new audit, at the CA operator's expense, for the period of time in question. Additionally, depending on the nature of concerns with the audit, Mozilla MAY require that the CA operator obtain such an audit from a new auditor."
Then, in section 7.3, I added: "Mozilla MAY remove or disable a certificate if the CA operator has reoccurring incidents with the same underlying cause or failed to remediate the causes giving rise to incidents."
Ben