On Thu, Mar 7, 2019 at 9:52 AM Jaime Hablutzel via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> I would just like to remind you all the universally accepted concept of > "Presumption of innocence". Quoting from > https://en.wikipedia.org/wiki/Presumption_of_innocence: > > >The presumption of innocence is the legal principle that one is > considered innocent unless proven guilty. It was traditionally expressed by > the Latin maxim ei incumbit probatio qui dicit, non qui negat (“the burden > of proof is on the one who declares, not on one who denies”). > > Where it is useful to highlight the following phrases: > > - one is considered innocent unless *proven* guilty > - the *burden of proof is on the one who declares*, not on one who denies > > So, unless MDSP is the jury responsible for proving DM guilty, I think > they should be accepted until their mischief can be proved, although I'm > not sure who should/could be responsible for such a task. > Thanks for sharing this, Jaime, and thank you for engaging in this discussion. Unfortunately, there are a number of flaws with this thinking, which I want to highlight, although I hope it does not discourage further participation. As you seem to acknowledge, MDSP is not a jury and this is not a legal proceeding. On that basis, the application of a "Presumption of Innocence" is not necessary nor relevant - we're not discussing legal proceedings here, nor is the goal to assess "guilt" or "innocence". The fundamental question of a root program is whether or not an organization is trustworthy. In some ways, you may wish to think of CAs as custodians of a given root programs' trust, and since we're applying Latin concepts, the phrase "Quis custodiet ipsos custodes" is perhaps applicable here. The answer is that the root program supervises the CAs, through consultation with the public. If it helps to frame this in concepts that may be more familiar - even if they are far from a perfect match - you might think of this as how officers of organizations or politicians are held to higher standards, and things which might be acceptable in the general case are not acceptable for such parties. However, I think it's more fundamentally flawed to see the process as "default trust". The answer is rather the opposite; the default answer is "do not trust", and it is the CAs duty to provide sufficient evidence to demonstrate both their trustworthiness and utility to a root program, such that the vendor is willing to enter into a business relationship with them and entrust them with protecting the security of their users. A good example of this principle ("default deny") at play is in the reliance upon audits. As practiced by WebTrust practitioners, the professional standards of auditors actually work from a view of assuming that none of the principles or criteria have been met by the organization. The organization being audited has a duty to produce and demonstrate sufficient evidence so as to convince a "reasonable" auditor that the CA is and has been meeting the various requirements. Using the AICPA as an example (and similar examples exist for ISAE and CPA Canada and other professional auditing bodies), you can see this at [1], and in particular, AT-C 105.10a or 105.25iii. As noted elsewhere, the programs goals are not necessarily to include any entity who meets some perfunctory checklist, but to ensure that the benefits outweigh the risks for the typical user. As such, there is an inherent burden to highlight the benefits, just as there is a responsibility to evaluate solutions to mitigate risks, as some have offered [3]. Going back to legal concepts, as inappropriate for this discussion as they are, one might say that the "burden of proof" exists with each CA participating or applying to participate in a given root program to demonstrate their value and to produce evidence counter to the claims provided. My previous message [4] highlighted some approaches that CAs might use to do that, while also highlighting that, fundamentally, audits alone do not and have never met that fundamental sufficiency. I hope that helps explain the flaws in this reasoning, while also highlighting the standards being applied are well-understood and accepted concepts. [1] https://www.aicpa.org/research/standards/auditattest/ssae.html [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/rNWEMEkUAQAJ [3] https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/LPCGngLxBwAJ [4] https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/rNWEMEkUAQAJ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
