On Thursday, March 7, 2019 at 10:17:21 AM UTC-5, Ryan Sleevi wrote: > On Thu, Mar 7, 2019 at 9:52 AM Jaime Hablutzel via dev-security-policy < > email@example.com> 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.
Fair enough, after all, Mozilla's root program is a private initiative, but could you please just confirm to me if the "default deny" policy is clearly and formally documented as part of the Mozilla Root Store Policy?. > > 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 , 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 . 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  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. > >  https://www.aicpa.org/research/standards/auditattest/ssae.html >  > https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/rNWEMEkUAQAJ >  > https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/LPCGngLxBwAJ >  > https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/rNWEMEkUAQAJ _______________________________________________ dev-security-policy mailing list firstname.lastname@example.org https://lists.mozilla.org/listinfo/dev-security-policy