Here is an edit to proposed subparagraph 11 of MRSP section 3.1.4: The publicly-available documentation relating to each audit MUST contain at least the following clearly-labelled information:
11. all incidents (as defined in section 2.4), including those reported in Bugzilla, that were: * disclosed by the CA or discovered by the auditor, and * unresolved at any time during the audit period; See https://github.com/BenWilson-Mozilla/pkipolicy/commit/d832883749280a1ee434c299e8d6bb0597dc8095 The idea is that all "incidents" must be reported if they were "unresolved" - which would include those that occurred or were open - at any time during the audit period. Additional guidance and interpretation of the above would be available on the wiki. On Thu, Jan 28, 2021 at 2:05 PM Ryan Sleevi <r...@sleevi.com> wrote: > > > On Sun, Jan 24, 2021 at 11:33 PM Ben Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> All, >> >> Based on the comments received, I am inclined to clarify the proposed >> language under Issues #154 and #187 with reference to a CA's Bugzilla >> compliance bugs rather than "incidents". The existing language in section >> 2.4 of the MRSP already requires the CA to promptly file an Incident >> Report >> in Bugzilla for all incidents. >> >> My proposal for Issue #154 is to add a final sentence to MRSP section 2.4 >> which would say, "If being audited according to the WebTrust criteria, the >> CA’s Management Assertion letter MUST include a complete list of the CA's >> Bugzilla compliance bugs that were unresolved at any time during the audit >> period." >> >> Under Issue #187, I propose that new item 11 in MRSP section 3.1.4 >> (required >> publicly-available audit documentation) would read: "11. a complete list >> of the CA’s Bugzilla compliance bugs that were unresolved at any time >> during the audit period." >> > > I don't think this is a good change, and doesn't meet the intent of the > problem. > > This implies that if Mozilla believed an incident resolved (or, as we've > seen certain CAs do, the CA themselves mark their issue as resolved), that > there's no requirement to disclose this to the auditor other than "Hope the > CA is nice" (which, sadly, is not reasonable). > > I explicitly think incident is the right approach, and disagree that > flagging it as compliance bugs is good or useful for the ecosystem. I > further think that even matters flagged as "Duplicate" or "Invalid" _are_ > useful to ensure that the auditor is aware of the relevant discussion. For > example, if evidence contrary to the facts stated on the bug (i.e. it was > *not* a duplicate), this is absolutely relevant. > > So I guess I'm disagreeing with Jeff and Clemens here, by suggesting that > incident should be any known or reported violation of Mozilla policy, which > may be manifested as bugs, in order to ensure transparency and confirmation > that the auditor had the necessary information and facts available and that > it was considered as part of the statement. This still permits auditors to, > for example, consider the issue as a duplicate/remediated, but given that > the whole goal is to receive confirmation from the auditors that they were > aware of all the same things the community is, I don't think the proposed > language gets to that. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy