On Mon, Nov 9, 2020 at 11:53 AM Clemens Wanko via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Hi Ryan, hi all, > well, isn’t the point to make here just, that there are multiple ways to > ensure proper auditor qualification? No matter which way you like to go > however, you must define the details of your regime: what is the criteria > you require the auditor to fulfill, how do you organize that these criteria > are checked, how do you ensure the quality of this process, how do you > publish any results with regard to the auditors qualification, etc. Clemens, I see you doubled down on this approach, but I already responded previously. I think this mindset to compliance does a great disservice, and also substantially misrepresents, the values and principles at play here. That is, you've again anchored on the notion here tha compliance should be a checklist - this exact approach and mindset that has led to countless security issues and incidents. This is the fundamentally wrong approach here that I think bears calling out, and it's worth again, emphasizing, that no, it doesn't have to be like how you describe, and also (unsurprisingly) overlooks the downsides. If you examine the posts I referenced previously, you'll see this in action, so I do hope you will. So your questions are a bit nonsense here, because they start from a conceptually bad foundation. <snip> > Certainly, there are always alternatives. But the alternative should be > clearly defined and described in order to allow an evaluation of all the > options before taking a decision. In the current case I like to understand > the alternatives you suggest for Mozilla. > You've turned this thread into a broader discussion of ETSI standards, and while many criticisms could be fairly stated, I think that detracts from this thread, and ignores the very thing it was started to discuss. I'd like to reorient you back to the original purpose, of bringing transparency to the auditor skills and competencies. It would seem your position is that there should be no independent evaluation, by affected software vendors, of the skills and competencies of the auditor or how they perform the audit. You would like us to rely solely on the NAB and Supervisory Body for carrying that out, even for a totally unrelated audit scheme (the eIDAS Regulation), which can incidentally make use of largely-unrelated standards for audits (the EN 319 403 series). You seem to argue that's superior to any form of transparency or accountability, and seem to reject the notion that, were auditors skills and qualifications known and part of the report, it can tangibly lead to improvements on the requirements. Frankly, I think that idea is nonsense. We know, from the Supervisory Bodies involved in the eIDAS Regulation, that there are vast differences in quality and expectation from CABs. Browsers have shared those same concerns to ENISA, and ACAB'c seems to recognize it as well, from its very existence. Yet you seem to reject efforts to improve that, and suggest that we simply "trust the process" that it'll get sorted out. We have ample evidence, from Certificate Transparency, about how bringing transparency reveals systemic issues and flaws. Yet, rather than embrace this for audits, it's seemingly rejected with unsubstantiated roadblocks. You've not responded, in substance, to my previous message, and so I'm not sure how to interpret that, especially since this largely repeats the same points. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
