On Wed, Jan 26, 2022 at 1:26 PM Ben Wilson <[email protected]> wrote:
> 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. > Yup, I think this is a great clarification to make, namely: Whenever a CA becomes aware that they have failed to meet requirements, such as via an external report from end-users, an internal discovery, or feedback during an audit or consultation, the CA should file a CA incident report to disclose that to the community. Additionally, CAs should consider raising issues that are flagged by auditors, but which may ultimately be determined not to be issues, both to provide an opportunity to ensure no misunderstandings, and to provide this as feedback and datapoints for how requirements can be clarified or improved in the future. These can be filed as Incident Reports, which can always be closed as Resolved/Invalid if the conclusion is supported, or raised on m.d.s.p. as items for discussion. I think DigiCert has been great about that last point, and I think a few other CAs have as well. I do know some CAs raise questions through their auditors to the [email protected] list, which offers yet another venue. While I think (incident or m.d.s.p.) is best, it seems like these would all be valuable clarifications, especially since the goal is "better, together" > 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. > Gotcha. I think that the following part: 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. Could potentially be reworded as: Mozilla expects the timely remediation of the problems that caused or gave rise to the incident, such as defined by the Baseline Requirements. Mozilla expects the CA operator to submit a plan of action with milestones and MAY require additional audits to ensure remediation and to regain confidence in the CA operator. Basically, this shifts the revocation expectation out - because that's covered by the BRs or (eventually) the S/MIME BRs, makes it clear that the expectation of actionable timeline (which is part of the incident report template) isn't conditional, but that there MAY be additional requirements beyond the resolutions set forth by the BRs. Then you can keep the rest of the proposed paragraph, which defines steps that Mozilla may take above-and-beyond the BRs. WDYT? -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHHfQgB-EQ0nvDBX887tB0p7W4VA2Ys_9pH7gHfCUbTDSw%40mail.gmail.com.
