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
