On Tue, Mar 13, 2018 at 4:13 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> I am not at all suggesting consequences for Let's Encrypt, but rather > raising a question as to whether that position on new inclusions / renewals > is appropriate. If these things can happen in a celebrated best-practices > environment, can they really in isolation be cause to reject a new > application or a new root from an existing CA? > While I certainly appreciate the comparison, I think it's apples and oranges when we consider both the nature and degree, nor do I think it's fair to suggest "in isolation" is a comparison. I'm sure you can agree that incident response is defined by both the nature and severity of the incident itself, the surrounding ecosystem factors (i.e. was this a well-understood problem), and the detection, response, and disclosure practices that follow. A system that does not implement any checks whatsoever is, I hope, something we can agree is worse than a system that relies on human checks (and virtually indistinguishable from no checks), and that both are worse than a system with incomplete technical checks. I do agree with you that I find it challenging with how the staging environment was tested - failure to have robust profile tests in staging, for example, are what ultimately resulted in Turktrust's notable misissuance of unconstrained CA certificates. Similarly, given the wide availability of certificate linting tools - such as ZLint, x509Lint, (AWS's) certlint, and (GlobalSign's) certlint - there's no dearth of availability of open tools and checks. Given the industry push towards integration of these automated tools, it's not entirely clear why LE would invent yet another, but it's also not reasonable to require that LE use something 'off the shelf'. I'm hoping that LE can provide more details about the change management process and how, in light of this incident, it may change - both in terms of automated testing and in certificate policy review. > Another question this incident raised in my mind pertains to the parallel > staging and production environment paradigm: If one truly has the 'courage > of conviction' of the equivalence of the two environments, why would one > not perform all tests in ONLY the staging environment, with no tests and > nothing other than production transactions on the production environment? > That tests continue to be executed in the production environment while > holding to the notion that a fully parallel staging environment is the > place for tests seems to signal that confidence in the staging environment > is -- in some measure, however small -- limited. That's ... just a bad conclusion, especially for a publicly-trusted CA :) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
