On Wed, Mar 8, 2017 at 1:36 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> I am simply going by the wording in Gervs posting not stating what you > stated. I presume that if Gerv wanted to complete eliminate the DTP > concept for Mozilla trusted CAs, then that's what he would have written. > Jakob, This is a frustrating excerise, and I hope you can appreciate. You are again ascribing an intent, one of which you explicitly stated, to Gerv, without evidence or support. When challenged on this, you acknowledge support for this conclusion isn't present - but now you're trying to again suggest the presumption/wording. Can we at least agree - for the sake of productive discussion - that there's no explicit statement that removing DTPs is off the table, so that we can discuss the substance of that, and you can acknowledge that there's no provided evidence to support your claim that removing DTPs was not intended? Can you imagine the possibility that Gerv just simply didn't word it as such? > Having not fully studied the exact wording of the BRs, I operate under > the assumption that the longer phrasing "... an audit report, issued > under the auditing standards that underlie the accepted audit schemes > found in Section 8.1 ..." as quoted from section 8.4 in earlier > discussion of the Symantec case was intentionally so phrased to > indicate that the audit of a DTP would not be the same as a full > WebTrust CA audit, but would only cover those aspects of those criteria > which would be applicable to the performance of the particular DTP role. > > > If that quote is indeed from the relevant part of the BRs, then I > would posit that if the BR authors had wanted all kinds of DTPs to be > subject to a full WebTrust audit, they would not have used this more > complex phrase. > The BR authors are terribly flawed (I'm one of them, or at least maintainers), and the wording complexity and confusion is more often confusing than intentional. I hope you consider my reply to Peter on this topic, in which I try to highlight how the point upon which you're stuck on 'full audit', is a practical matter that, when applied, is indistinguishable from an DTP audit. I think you can readily agree that the 'intent' is that the fullness of capabilities relative to causing issuance are desired to be audited. Namely, whether we're talking a DTP audit or a CA audit, the intent is that all CA functions outlined in the Baseilne Requirements can have Principles and/or Criteria attached to / derived from them, and that every party who performs some role within it is audited according to that role. If you can agree to that - which is, I think, the point you're trying to make with DTP audits - then what we have is a scenario where some functions are performed by Company A, some functions are performed by Company B. Whether it's a DTP performing 3.2 validation (Company B) or an entity performing 3.2 validation for an externally operated sub-CA (Company B), I think we're in violent agreement that we want to ensure that Company B is audited according to its role. Before I introduce any more complexity - can you agree to that as the goal? Then everything else is just semantics that we can hammer out. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
