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 <
> 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.
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 [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
