On Mon, Nov 26, 2018 at 10:31 AM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> CA/B is the right place for CAs to make the case for a general rule about > giving themselves more time to handle technical non-compliances whose > correct resolution will annoy customers but impose little or no risk to > relying parties, > CAs have made the case - it was not accepted. On a more fundamental and philosophical level, I think this is well-intentioned but misguided. Let's consider that the issue is one that the CA had the full power-and-ability to prevent - namely, they violated the requirements and misissued. A CA is only in this situation if they are a bad CA - a good CA will never run the risk of "annoying" the customer. This also presumes that "annoyance" of the subscriber is a bad thing - but this is also wrong. If we accept that CAs are differentiated based on security, then a CA that regularly misissues and annoys its customers is a CA that will lose customers. This is, arguably, better than the alternative, which is to remove trust in a CA entirely, which will annoy all of its customers. This presumes that the customer cannot take steps to avoid this. However, as suggested by others, the customer could have minimized or eliminated annoyance, such as by ensuring they have a robust system to automate the issuance/replacement of certificates. That they didn't is an operational failure on their fault. This presumes that there is "little or no risk to relying parties." Unfortunately, they are by design not a stakeholder in those conversations - the stakeholders are the CA and the Subscriber, both of which are incentivized to do nothing (it avoids annoying the customer for the CA, it avoids having to change for the customer). This creates the tragedy of the commons that we absolutely saw result from browsers not regularly enforcing compliance on CAs - areas of technical non-compliance that prevented developing interoperable solutions from the spec, which required all sorts of hacks, which then subsequently introduced security issues. This is not a 'broken windows' argument so much as a statement of the demonstrable reality we lived in prior to Amazon's development and publication of linting tools that simplified compliance and enforcement, and the subsequent improvements by ZLint. Conceptually, this is similar to an ISP that regularly cuts its own backbone cables or publishes bad routes. By ensuring that the system consistently functions as designs - and that the CA follows their own stated practices and procedures and revokes everything that doesn't - the disruption is entirely self-inflicted and avoidable, and the market can be left to correct for that. > I personally at least would much rather see CAs actually formally agree > they should all have say 28 days in such cases - even though that's surely > far longer than it should be - than a series of increasingly implausible > "important" but ultimately purely self-serving undocumented exceptions that > make the rules on paper worthless. > I disagree that encouraging regulatory capture (and the CA/Browser Forum doesn't work by formal agreement of CAs, nor does it alter root program expectations) is the solution here. I agree that it's entirely worthless the increasingly implausible "important" revocations. I think a real and meaningful solution is what is being more consistently pursued, and that's to distrust CAs that are not adhering to the set of expectations. There's no reason to believe the "impact" argument, particularly when it's one that both the Subscriber and the CA can and should have avoided, and CAs that continue to make that argument are increasingly showing that they're not working in the best interests of Relying Parties (see above) or Subscribers (by "annoying" them or lying to them), and that's worthy of distrust. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
