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
