On Thu, Mar 28, 2019 at 7:42 PM Wayne Thayer <wtha...@mozilla.com> wrote:
> On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi <r...@sleevi.com> wrote: > >> On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> **Incidents** >>> > When a CA fails to comply with any requirement of this policy - >>> whether it >>> > be a misissuance, a procedural or operational issue, or any other >>> variety >>> > of non-compliance - the event is classified as an incident. At a >>> minimum, >>> > CAs MUST promptly report all incidents to Mozilla in the form of an >>> Incident >>> > Report <https://wiki.mozilla.org/CA/Responding_To_An_Incident>, and >>> MUST >>> > regularly update the Incident Report until the corresponding bug is >>> > resolved by a Mozilla representative. In the case of misissuance, CAs >>> > SHOULD cease issuance until the problem has been prevented from >>> reoccurring. >>> >> For comparison, Microsoft's policy is >> https://aka.ms/rootcert#d-ca-responsibilities-in-the-event-of-an-incident >> > Thanks for the reference. I would note that Microsoft's requirements > appear to be much narrower in scope, applying to "Security Incidents" as > defined in section 6. Having said that, are there specific requirements > that we should consider adding to Mozilla policy? > There are two things that stand out to me that are unclear if you meant to incorporate by reference to the incident report: - Whether it's a policy violation if the CA fails to disclose the affected certificates, which MSFT policy explicitly requires - What, if any, timeframe for periodic updates. MSFT policy explicitly states that MSFT shall determine the update cadence. (This may be a non-issue) Additionally, in further consideration of both this proposal and the highlighted difference, it's unclear whether it's intended to create a hierarchy of incidents. I think the language, as worded, does - perhaps inadvertantly - by mentioning misissuance vs a procedural or operational issue. Consider, for example, a CA that determines they're copying the O field directly from CSRs into the final certificates. Such certificates are unquestionably misissued, but the language creates the opportunity that the CA would argue it's a "procedural or operational" issue, and thus they're not required to cease issuance until the problem has been prevented. One thing to consider with such a policy is whether to formalize the use of >> Bugzilla to track these. In looking through incident reports that have been >> filed, we see a fair distribution between the initial reporting being on >> the email list vs Bugzilla. We've certainly seen Bugzilla be more useful in >> tracking unacknowledged questions and responses (via the use of >> Needs-Info). Would it make sense to require that the incident report be >> provided via Bugzilla, with a notification to the mail list? >> > > I would be interested in everyone's opinion on this. While I agree that > Bugzilla is a necessary mechanism for tracking incidents, I believe that it > reduces community visibility and makes it more difficult for most members > to follow incident discussions. It has been suggested that we create a > process that automatically publishes a summary of new or updated incident > bugs to this list on a periodic basis, but that obviously isn't yet in > place. Even with that, I might argue that the requirement should be to > publish incident reports to m.d.s.p., with a bug then being created by the > CA or a Mozilla representative. > I do share those concerns, hence the attempt to split it in the middle. My concern is that there have been several high-profile incidents which have been discussed in m.d.s.p., in which very relevant questions from members of the community go ignored, perhaps deliberately, and it becomes difficult to track in all of the discussion what those points were. However, I suppose the same issue may similarly exist if tracking the discussion through Bugzilla. This suggestion may end up being orthogonal to the policy update question, but it's one largely motivated by wanting to either make sure CAs are aware of the need to respond to questions - or to make sure that it's accurately noted when CAs ignore or otherwise fail to do so. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
