On Tue, Dec 4, 2018 at 1:29 PM Dimitris Zacharopoulos via dev-security-policy <[email protected]> wrote:
> I tried to highlight in this discussion that there were real cases in > m.d.s.p. where the revocation was delayed in practice. However, the > circumstances of these extended revocations remain unclear. Yet, the > community didn't ask for more details. The expectation is that there will already be a discussion about this. At the worst case, this discussion will be delayed until the audit qualifications come in - the absence of audit qualifications in such situations would be incredibly damning. It sounds like you believe this is not, in fact, a requirement today, and it may be possible to clarify that already. Do you think the language in https://wiki.mozilla.org/CA/Responding_To_An_Incident is sufficient, or do you feel it's ambiguous as to whether or not a failure to abide by the BRs constitutes "an incident"? As to the second half, the community not asking for details, as a member of this community, you can and should feel empowered to ask the details you feel are relevant. Do you believe that something about the handling of this makes it inappropriate for you to ask questions you believe are relevant? > Seeing this repeated, was the > reason I suggested that more disclosure is necessary for CAs that > require more time to revoke than the BRs require. It's not at all clear how this result is linked to the remarks you make above. Above, your remark seems to focus on CAs not disclosing in a timely fashion, nor disclosing the circumstances. The former is a violation of the existing requirements, the latter is something you can and should inquire on if you feel is relevant. It's unclear what is "more" about the existing disclosure, and certainly, the framing used in this statement implies that the issue is time, but seemingly acknowledges we don't have data to support that. > At the very minimum, > it would help the community understand in more detail the circumstances > why a CA asks for more time to revoke. > I think there's an equally flawed assumption here - which is that CAs should be asking for exceptions to policies. I don't think this is at all a reasonable model - and the one time it did happen (with respect to SHA-1) was one that caused a lot of pain and harm overall. I think it should be uncontroversial to suggest that "exceptions" don't exempt the need from qualifications - certainly, neither the professional standards behind the ETSI audit criteria nor the standards behind the WebTrust would allow a CA to argue an event is not a qualification solely because Mozilla "granted an exception". Instead, the concept of "exceptions" is one of asking the community whether or not they will agree to ignore, apriori, a matter of non-compliance. In a world without "exceptions", the CA will take the qualification, and will need to disclose (as part of an Incident Report and, later, the audit report) the nature behind the incident, the facts, and those details. In determining ongoing trust, the community will take a holistic look at the incidents and qualifications, whether sufficient detail was presented, and what the patterns and issues are. This is a healthy system, whereas introducing "exceptions" and agreement, a priori, to exclude certain facts from consideration is not. For one, it prevents the determination and establishment of patterns - granting exceptions as "one-offs" can (and demonstrably does) lead to patterns of misissuance, and asking the community to overlook those patterns because it agreed to overlook the specific events is very much an unreasonable, and harmful, request. This is similar to the harm of creating "tiers" of misissuance, as both acts seek to legitimize some forms of non-compliance, without concrete data, which then collectively erodes the very notion of compliance to begin with. Thus, if we disabuse the notion that some CAs have, or worse, have promoted to their subscribers - that browsers can, do, and will grant promises to overlook certain areas of non-compliance - then the proposal itself goes away. That's because the existing mechanisms - for disclosure and detail gathering - function, and the community can and will consider those facts when holistically considering the CA. It may be that some forms of misissuance are so egregious that no CA should ever attempt (e.g. granting an unconstrained CA), and it may be that other forms are considered holistically as part of patterns, but the CA is ultimately going to be gambling, and that's all the more reason that a CA shouldn't violate in the first place. If (some) CAs do feel the requirements are overly burdensome, then proposing changes is not unreasonble - but it MUST be accompanied with concrete and meaningful data. Absent that, it leads to the harmful problems I discuss above, and thus is not worth the time spent or electrons wasted on the discussion. However, if (most) CAs systemically provide data, then we can have meaningful discussions about what the bounds for flexibility look like for (all) CAs. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
