On Thu, Nov 21, 2019 at 10:54 AM Wayne Thayer via dev-security-policy < [email protected]> wrote:
> During the recent CA/Browser Forum meeting, I was asked to provide better > guidance on Mozilla's expectations for incident reporting. We're adding a > requirement for incident reporting to the new version of our policy [1], > but in this message I'm focused on the guidance provided on our wiki [2]. > The question was when to add information to an existing bug versus creating > a new one. I'd like to propose adding the following guidance to the wiki to > address this question: > > CAs should create a separate bug and file a new incident report when: > * In the process of researching one incident another incident with a > distinct root cause and/or remediation is discovered > * After an incident bug is marked resolved, the incident reoccurs > > A third possible addition would be: > * When a CA accidentally or intentionally misses a revocation deadline, a > separate bug should/must be filed examining the root cause and remediation > for missing the deadline > > I believe the argument for this is that tracking revocation issues > separately will help us to focus on improving the agility of the web PKI. > On the other hand, Mozilla has not generally required separate reports in > the past, and doing so certainly creates more work for everyone involved. > It's not clear to me that the benefit of this outweighs the cost. > Yeah, I've been thinking about this in light of the feedback Kathleen offered on https://groups.google.com/d/msg/mozilla.dev.security.policy/M7NGwCh14DI/jZft5ZH_AgAJ My primary objectives in treating it as two distinct issues are: 1) Ensuring the timely remediation of the root causes of whatever 'caused' the incident. In general, this should be 'sooner' than 'later' 2) Ensuring transparency about when CAs are having repeat "delayed revocation" issues; buried within issues themselves makes it difficult to track when there are repeat offenders, but also limits visibility into systemic issues that all CAs can/should be aware of when contemplating the design and maintenance of their PKI 3) Ensuring progress is made towards revocation, by not having bugs prematurely closed when the 'root' incident is resolved but the CA has taken no meaningful steps to bring their PKI back into compliance (yet) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
