Nick, I find your continued suggestions to be actively harmful - to the discussion, for sure, but also to the reputation of ETSI.
You've attempted to frame this, again, as an either/or approach - that is, that we can only have one of these discussions. You've attempted to "thread-jack" the conversation by suggesting that we ignore specific failures of a specific auditor, repeatedly, by instead suggesting that through closed-door negotiations and smokey-room summits (notably, in which browsers will be absent) will somehow resolve the issues. That's difficult to believe, and even more difficult to stomach, given the attempt to deflect any responsibility or accountability in favor of some abstract 'process'. That's not to dismiss there being value in improving ETSI. Certainly, if ETSI is to provide any value to the Web Ecosystem going forward, it needs to address those needs. There's nothing inherently valuable in the ETSI audits that makes them immune from concern or rejection. However, this thread is about specific failures of a specific auditor. If you do not believe these are failures - that is, you do not believe the ETSI EN 319 * series has any normative guidance on CABs with respect to assessing compliance with the stated certificate profiles - then we should reject ETSI for the time being. If you do agree, however, that there is specific guidance throughout those series regarding the expectations of CABs, and that there is a pattern of failing to examine or adhere to that, then I hope you can see and agree on the critical necessity of why the CAB is failing. We still have yet to receive a meaningful post-mortem from TUVIT regarding this failure, nor of any acknowledgement of the pattern, as demonstrated by past CAs they have audited, in which they failed to detect or account for material non-conformities. That silence and lack of a meaningful response - as to what practices are applied in the audit, why they failed, and what can be done to improve - is exactly why it's reasonable to discuss rejection of their future audit statements. Suggesting that taking this up with ETSI will resolve this is akin to suggesting that the CA/Browser Forum should be consulted every time there's material misissuance. That misunderstands the ecosystem, misunderstands the purpose, and misunderstands how to appropriately protect users. There needs to be a resolution, to this thread. If you would like to continue suggesting improvements to ETSI, which while I agree with, do not believe this is at all an appropriate time, I would request you create a new thread to share your thoughts. They are not, despite any possible intent, productive for this conversation. On Mon, Nov 12, 2018 at 11:00 AM Nick Pope via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Ryan, > > I see the main question is what is the most productive way ahead. We can > continue discussing a specific concern in the context of just 1 of the > European auditor, or work in the EU on a considered approach to all the > concerns which can be applied to all European based audits. The first does > not seem to be working towards something that you are happy with and even > then would only provide an answer in a limited context. With the second > approach we can take into account all your concerns and work towards an > approach that can be applied to all EU audits which is acceptable to all. > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
