On Wed, Nov 22, 2017 at 12:24 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On 22/11/17 17:03, Matthew Hardeman wrote: > > approval in terms of community buy-in. The downside, of course, is that > > while this alternative pre-discussion allows for discussion of the > nebulous > > concept of "trust" and integrity, it actually denies the community those > > matters which can be most objectively evaluated -- the CPS, the > subscriber > > agreements, certificate policy, auditor's opinions, etc. (which makes > > sense -- the development of these is pricey). > > That's a fair point. Let us assume for the sake of discussion that all > of those things are standard and unobjectionable in themselves. > Let's assume it meets the standard boilerplate. Would it meet community expectations, based on past behaviour? Given that WoSign's CP/CPS itself was met by standard boilerplate, I would pose that it is insufficient - the past behaviour as a predictor of future behaviour means that the existing documentation approaches are insufficient to make an evaluation about the trustworthiness going forward. How would this be remedied? It seems at a minimum, there'd need to be safeguards within the new documents that sufficiently describe and mitigate the past failures of safeguards. But would such statements, such as "I promise I won't do X again, and look, here's a document that now says explicitly 'We have trained sharks and equipped them with lasers to ensure we do not do X again'" be seen as a sufficient mitigation? I think an important part of this discussion is trying to understand to what side of Hanlon's razor did WoSign's actions fall (or, to that matter, of any CA). If it was incompetence, is there sufficient explanation for how such incompetence happened? If there sufficient evidence that both the specific incident and any underlying causes have been remediated? Alternatively, if we allow it to be attributed to malice (or, for that matter, greed), is it possible to design a system of trust that is robust against such considerations? If not, is it an acceptable risk to take going forward. If we can, what are those controls and expectations? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
