Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report
All,
I've modified the proposed change to MRSP section 3.2 so that it would now
insert a middle paragraph that would read:
"A Qualified Auditor MUST have relevant IT Security experience, or have
audited a number of CAs, and be independent and not conflicted. Individuals
have competence, partnerships and corporations do not. Each Audit Report
MUST be accompanied by documentation provided to Mozilla of individual
auditor qualifications sufficient for Mozilla to determine the competence,
experience, and independence of the Qualified Auditor."
See
https://github.com/BenWilson-Mozilla/pkipolicy/commit/57063dc07f5b753184c94dbf5d0d30d0b9b90789
The basis for further interpretation of the above language would still be
section 8.2 of the Baseline Requirements. ("In normal circumstances,
Mozilla requires that audits MUST be performed by a Qualified Auditor, as
defined in the Baseline Requirements section 8.2").
Section 3.1.4 still remains with a proposed subsection 3 - "name(s) and
qualifications of individuals performing the audit, as required by section
3.2."
I anticipate that additional guidance for how CAs should submit this
information will be made available here on the wiki -
https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications.
Ben
On Thu, Jan 28, 2021 at 2:10 PM Ryan Sleevi wrote:
>
> On Thu, Jan 28, 2021 at 3:05 PM Ben Wilson wrote:
>
>> Thanks. My current thinking is that we can leave the MRSP "as is" and
>> that we write up what we want in
>> https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications,
>> which is, as you note, information about members of the audit team and how
>> individual members meet #2, #3, and #6.
>>
>
> Is this intended as a temporary fix until the issue is meaningfully
> addressed? Or are you seeing this as a long-term resolution of the issue?
>
> I thought the goal was to make the policy clearer on the expectations, and
> my worry is that it would be creating more work for you and Kathleen, and
> the broader community, because it puts the onus on you to chase down CAs to
> provide the demonstration because they didn't pay attention to it in the
> policy. This was the complaint previously raised about "CA Problematic
> Practices" and things that are forbidden, so I'm not sure I understand the
> distinction/benefit here from moving it out?
>
> I think the relevance to MRSP is trying to clarify whether Mozilla thinks
> of auditors as individuals (as it originally did), or whether it thinks of
> auditors as organizations. I think that if MRSP was clarified regarding
> that, then the path you're proposing may work (at the risk of creating more
> work for y'all to request that CAs provide the information that they're
> required to provide, but didn't know that).
>
> If the issue you're trying to solve is one about whether it's in the audit
> letter vs communicated to Mozilla, then I think it should be possible to
> achieve that within the MRSP and explicitly say that (i.e. not require it
> in the audit letter, but still requiring it).
>
> Just trying to make sure I'm not overlooking or misunderstanding your
> concerns there :)
>
>>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots
On Tue, 9 Feb 2021 14:29:15 -0700 Ben Wilson via dev-security-policy wrote: > All, > GlobalSign has provided a very detailed incident report in Bugzilla - > see https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c2. > There are a few remaining questions that still need to be answered, > so this email is just to keep you aware. > Hopefully later this week I'll be able to come back and see if people > are satisfied and whether we can proceed with the root inclusion > request. I have a question (if I should write it in Bugzilla instead please say so it is unclear to me what the correct protocol is) GlobalSign have provided a list of 112 other certificates which were issued for the same reason, I examined some of them manually and determined that they are in appearance unextraordinary (2048-bit RSA keys for example) and so it's unsurprising we didn't notice they were issued previously. However, the list does not tell me when these certificates were ordered or, if substantially different, when the email used to "validate" these orders was sent. As a result it's hard to be sure whether these certificates were issued perhaps only a few weeks after they were ordered, which is a relatively minor oversight, or, like the incident certificate, many years afterwards. I'd like maybe a column of "order date" and "email sent date" if the two can be different. - I also have noticed something that definitely isn't (just) for GlobalSign. It seems to me that the current Ten Blessed Methods do not tell issuers to prevent robots from "clicking" email links. We don't need a CAPTCHA, just a "Yes I want this certificate" POST form ought to be enough to defuse typical "anti-virus", "anti-malware" or automated crawling/ cache building robots. Maybe I just missed where the BRs tell you to prevent that, and hopefully even without prompting all issuers using the email-based Blessed Methods have prevented this, Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports
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 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
Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots
On Thu, Feb 11, 2021 at 1:11 PM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I have a question (if I should write it in Bugzilla instead please say > so it is unclear to me what the correct protocol is) > While Mozilla Policy permits discussion in both, I will say it's significantly easier when the discussion is on Bugzilla to ensure the feedback is considered and promptly responded to. So if you want to consider posing your questions there, that's really helpful for posterity. If, for example, it became necessary to discuss a set of issues for a CA, Bugzilla incident reports are going to be the primary source of the incident report and discussion, and unless there's a clear link *on the bug* to such mailing list discussion, it will no doubt be overlooked. So I'd say feel free to ask your question there, which helps make sure it's answered before the issue is closed. > I also have noticed something that definitely isn't (just) for > GlobalSign. It seems to me that the current Ten Blessed Methods do not > tell issuers to prevent robots from "clicking" email links. We don't > need a CAPTCHA, just a "Yes I want this certificate" POST form ought to > be enough to defuse typical "anti-virus", "anti-malware" or automated > crawling/ cache building robots. Maybe I just missed where the BRs > tell you to prevent that, and hopefully even without prompting all > issuers using the email-based Blessed Methods have prevented this, > Yes, this has been raised previously in the Forum by Peter Bowen (then at Amazon), as part of the discussion and input with respect to the validation methods. This is one of many outstanding items still for the Validation Working Group of the CA/B Forum, as possible mitigations were also discussed. In short, "capability URLs" (where the entire URL is, in effect, the capability) are dangerous. Note that there have been far more than "Ten Blessed Methods" since those discussions, so perhaps it's clearer to just say 3.2.2.4. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.7.1: MRSP Issue #221: Wrong hyperlink for "Material Change" in MRSP Section 8
All, I am proposing for v. 2.7.1 a minor change that corrects a hyperlink issue in MRSP section 8. The link to "material change" here redirects to "alteration of instruments" - https://legal-dictionary.thefreedictionary.com/Material+Changes, which is altogether wrong since we're talking about a "material change" to CA operations, not changes to legal documents. Rather than replace the hyperlink, I think it is better to say what we mean by "material change" and replace it with "there is a change in the CA's operations that could significantly affect a CA's ability to comply with the requirements of this Policy." See https://github.com/BenWilson-Mozilla/pkipolicy/commit/fbe04aa64f931940af967ed90ab98aa95789f057. Thanks, Ben ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
