On Tue, Apr 17, 2018 at 12:24 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On 17/04/2018 00:13, Ryan Sleevi wrote: > >> If you expect that, you're absolutely wrong for expecting that, because >> that's not what a High Risk Request is. >> >> > I am not the only one with that expectation. In the concrete case the > expectation was succinctly stated by Mathew in Message-ID > mailman.312.1523571519.2176.dev-security-policy at lists.mozilla.org as > And someone else is wrong on the Internet. That doesn't make it any more correct or reasonable assumption, no more than if you and I both agreed we deserved to be paid $1 million a year by CAs for exchanging emails on this list. > The definition is in section 1.6.1 of the BRs and does not limit itself > to blacklisted site names. Nor does it require blacklisted site names. That's the point. It's describing illustrative, not normative, examples of a process, not an exact output. That is hugely meaningful in explaining why your expectations have no basis in the requirements - nor, for that matter, are desirable. > >>> But just to please your pedantry, I will add two additional outcome >>> options: >>> >>> -1. Thay CA does not really check for high risk names at all. This >>> might be permitted by some readings of BR 4.2.1 / Ballot 78. >>> >>> >> It absolutely is permitted, and not a negative. Your expectations are >> wrong, and you should adjust them, because they're not based in reality. >> >> > BR 4.2.1 is a SHALL, not a SHOULD. > Yes - that you have a process. It does define the process for what quantifies as that high risk in any form of MUST/SHALL language. I can say high-risk requests are anything received via an InterPlanetaryNetwork ( https://en.wikipedia.org/wiki/Interplanetary_Internet ) and that is fully conforment - and in line with expectations. The notion of "High-risk" is fundamentally at the definition of the CA - what the objectives of certificates are, from the CAs view. Thankfully, there are competent CAs that recognize that certificates are not a phishing mitigation, and treat "risk" as an operational risk category (or, to sate some of the frothing masses, a PR risk), since there fundamentally is not some enhanced 'phishing' risk from certifying a domain. > Weak is a common security term and a common English term with similar > meaning in both contexts. > This is patently false. > The question asked by Matthew and me, and which you keep blocking, is if > jomo has publicly disclosed a case in which that CA's procedures > accidentally fail to achieve that CA's security goals for those > procedures. This is a perfectly normally vulnerability issue > investigation, which jomo (not I) made public 4 days ago. No, this is not. Because you're hinging on a flawed understanding of what you're asking, a flawed set of expectations, Matthew is working from a flawed sense of angst, which all are rooted in an improper understanding of the BRs or the goals of certificates, and for which the notion of "security goals" is clearly one you Have Opinions about, but those opinions are not in line with industry best practice or stated CA goals. So your questioning is not whether the CA has failed to achieve their goals, but whether they've failed to achieve your goals, and that's very much a nonsequitur with no basis in the actual goals of certificates. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
