Not looking for blanket approval – I stated it’d still be part of the audit report. We also aren’t directly impacted by this particular incident (which is why I brought it up here). The actual evaluation of the CA would remain up to Mozilla of course, but the really good discussion about 63 bits (especially the proposed ballot language) got me thinking about how we could apply this more generally to incident reports and how CAs can use them before deciding on a course of action. The underscore discussion was definitely good as well, and I felt had a great outcome.
I think the primary change I’m proposing is that the initial report shouldn’t be an incident report. Instead, the initial report can be short blurb posted to Mozilla along with a description on what the Ca plans to do. Then the community can talk about the plan in addition to the incident, rather than just the incident. Jeremy From: Ryan Sleevi <ryan.sle...@gmail.com> Sent: Tuesday, March 12, 2019 2:31 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: GoDaddy Revocation Disclosure On Tue, Mar 12, 2019 at 4:17 PM Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: A new flow that includes the community more fully could be: 1) Post to Mozilla, the post must include an initial proposed plan of action 2) Create an incident report (to track bugs) 3) Discuss on the Mozilla forum the proposed plan and post updated plans based on member suggestions 4) Post a final draft to Bugzilla 5) Post updates per a timeline set in the incident report 6) Wayne closes the bug. This is probably a lot more work for the CA, but I know we'd find the community feedback on how to resolve issues useful. Maybe it could also change into a continuous flow of "How can X CA do better - here's some suggestions" instead of "Better put up the lightning rod and get through this". So, I think many of these elements are already captured in the current process, as the lengthy discussion with DigiCert regarding underscores [1], and this provides a model for engaging with the community and gathering feedback and concerns about the response. CAs are responsible for drafting their initial incident reports, gathering feedback, and making a decision - much as DigiCert did with underscores. The CA is judged based on how well they considered and balanced the risks, there is opportunity for concerns about improving (an area DigiCert encountered with its own reports), and we move forward. It would seem, from your broader message, that this is looking for some sort of blanket approval, independent of the CA or facts specific to that CA, and I think that's something that we've been explicitly trying to avoid - as the context matters. There are a number of hazards, which Matt Palmer highlighted during the discussion of underscores [2][3][4], and I think those still apply now as much as they did two and a half months ago. [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/0oy4uTEVnus/pnywuWbmBwAJ [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/0oy4uTEVnus/APSWO4SYCgAJ [3] https://groups.google.com/d/msg/mozilla.dev.security.policy/0oy4uTEVnus/voFCTMFVAwAJ [4] https://groups.google.com/d/msg/mozilla.dev.security.policy/0oy4uTEVnus/ZqO9fHZMAwAJ
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
