On Tue, Dec 4, 2018 at 5:02 AM Fotis Loukos <[email protected]> wrote:
> An initial comment is that statements such as "I disagree that CAs are > "doing their best" to comply with the rules." because some CAs are > indeed not doing their best is simply a fallacy in Ryan's argumentation, > the fallacy of composition. Dimitris does not represent all CAs, and I'm > pretty sure that you are aware of this Ryan. Generalizations and the > distinction of two teams, our team (the browsers) and their team (the > CAs), where by default our team are the good guys and their team are > malicious is plain demagoguery. Since you like extreme examples, please > note that generalizations (we don't like a member of a demographic thus > all people from that demographic are bad) have lead humanity to > committing atrocities, let's not go down that road, especially since I > know you Ryan and you're definitely not that type of person. I appreciate you breaking this down. I think it's important to respond to the remark, because there is a substantive bit of this criticism that I think meaningfully affects this conversation, and it's worth diving into. Broadly speaking, it seems the interpretation of the first remark 'CAs are "doing their best"' can be interpreted as "(Some) CAs are doing their best" or "(All) CAs are doing their best". You rightfully point out that Dimitris does not represent all CAs, but that lack of representation can't be assumed to mean the statement could not possibly be meant as all CAs - that could have been the intent, and is a valid interpretation. Similarly, in the criticism, it seems the interpretation for 'I disagree that CAs are "doing their best"' can be interpreted as "I disagree that (some) CAs are doing their best", "I disagree that (all) CAs are doing their best", or "I disagree that (any) CAs are doing their best". While I doubt that any of these interpretations are likely to be seen as supporting genocide, they do underscore an issue: Ambiguity about whether we're talking about some CAs or all CAs. When we speak about policy requirements, whether in the CA/Browser Forum or here, it's necessary in the framing to consider all CAs in aggregate. Dimitris proposed a distinction between "good" CAs and "bad" CAs, on the basis that flexibility is needed for "good" CAs, while my counter-argument is that such flexibility is easily abused by "bad" CAs, and when "bad" CAs are the majority, there's no longer the distinction between "good" and "bad". Policies that propose ambiguity, flexibility and trust, whether through validation methods or revocation decisions, fundamentally rest on the assumption that all entities with that flexibility will use the flexibility "correctly." Codifying what that means removes the flexibility, and thus is incompatible with flexibility - so if there exists the possibility of abuse, it has to be dealt with by avoiding ambiguity and flexibility, and removing trust where it's "misused". This isn't a fallacy of composition - it's the fundamental risk assessment that others on this thread have proposed. The risk of a single bad CA spoiling the bunch, as it were, which is absolutely the case in a public trust ecosystem, is such that it cannot afford considerations of flexibility for the 'good' CAs. It's equally telling that the distinction between 'bad' CAs and 'good CAs' are "Those that are not following the rules" vs "Those that are", rather than the far more desirable "Those that are doing the bare minimum required of the rules" and "Those that are going above and beyond". If it truly was that latter case, one could imagine more flexibility being possible, but when we're at a state where there are literally CAs routinely failing to abide by the core minimum, then it's necessary and critical to consider in any conversation that is granting more trust to consider what "all CAs" when we talk about what "CAs are doing", just like we already assume that negative discussions and removing trust necessarily begin about "some CAs" when we talk about what "CAs are doing". _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
