On Fri, Dec 21, 2018 at 4:43 PM Jeremy Rowley <[email protected]> wrote:
> But this part isn't true "Browsers are not capable of granting > 'exceptions' to the Baseline Requirements", at least for Mozilla. See the > Mozilla auditor requirements for example. Perhaps better stated that they > don't have to implement the standards they don't like? > I mean, we can get pedantic if you want to get pedantic, but I don't think it really conflicts with any of the discussion here. I'll use WebTrust as an example here: - When a CA engages with an auditor, they specify the criteria to be used (i.e. http://www.webtrust.org/principles-and-criteria/item83172.aspx ). - If we assume a US-based auditor, then we're talking an auditor bound to AICPA with regards to attestation engagements against those criteria - The auditor may consider the perspective of Google and Mozilla in some regards, but those are secondary sources for them, and the auditor has professional obligations captured within AICPA's various codes that express what their expectations and interpretations are, as well as what they communicate, and no browser can override those - As a result, we can't tell you "You won't get a qualified audit" on that, because that's up to the auditor. Now, it's true that there are ways to change that calculus, by redefining the audit expectations - For example, if Mozilla or Google engaged the auditor, to audit a third-party (the CA), then Mozilla or Google could develop the criteria for that assessment in collaboration with the auditor (Agreed Upon Procedures), for which the auditor would then report on - But then you're no longer using those WebTrust criteria (or you may, with modified interpretations), and I'm sure if Don or Jeff from the WebTrust TF are lurking here, they'd probably chime in with a whole host of complications Now, the point of a CA getting audited is so that they can submit it to the Root Program that expects such audits. Such Root Programs can define whatever expectations they want - such as allowing anyone to perform the audit - with whatever the risks or tradeoffs that may come with. In the case of most root programs, you already see the acceptance of two audit criteria (WebTrust and ETSI), with sets of licensed auditors managed independently by those programs. Mozilla's policy, as the example you called out, specifically allows it to extend or reduce the set of auditors, but without respect to the criteria. Certainly, a root program can, upon receipt of a qualified audit, determine that no further action is warranted, or that the qualification is not a concern. But that does not absolve the auditor of their own duties (modulo if Mozilla were to appoint a random auditor or to directly negotiate the criteria, procedures, or reporting) The point being is that, short of directly developing the audit criteria or engaging directly with the auditor with respect to third-party audits using agreed-upon procedures, Root Programs - such as those operated by Google or Mozilla - don't really say whether or not something is or is not a qualification/non-conformity. That's the auditor, using fixed criteria, expressing their opinion based on the material facts. We do consider the auditor's opinion and expression of those facts, and they are relevant to Root Programs, but they don't somehow cause the auditor to say "Oh, my opinion doesn't matter, I'll do whatever they say" (Unless, again, that's what the engagement agreed to) This is all pedantry lost in the woods, because I don't think any CA can or should reasonably expect that the view of one browser (which is merely a consumer of the report, not the initiator) could declare something not-a-qualification. They might declare it not-relevant for their program, but that's an entirely different thing - that's part of the incident response process I described, which is fairly consistent among all programs. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
