On 07/03/17 20:37, Ryan Sleevi wrote: > To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated > Third Parties from participating in the issuance process? This would be > effectively the same, in as much as the only capability to allow a > third-party to participate in issuance is to operate a subordinate CA.
Is this the same as banning the concept of DTPs? I note, reading the BRs, that there's no process for root programs to get any access to, or validate, the audit documentation for DTPs. That doesn't sound great. Making them sub-CAs would solve that? > have you examined the most recent set of audits? I have glanced over them, but not studied them in depth. > Do you, in your capacity > as CA Certificate policy peer, believe the audits were correct for their > capability and role? Note that several of them were "WebTrust for CAs" - > not "WebTrust for CAs - SSL BR and Network Security". Do you believe that > complies with letter of the Baseline Requirements? That would be a question I would leave to Kathleen, who is the team expert here. > Similarly, do you believe Symantec had an obligation to ensure the proper > licensing status of auditors, prior to accepting such audits? No. This may surprise you but, for better or worse, the Mozilla requirements override those of the BRs (see the Audit section of policy 2.4) and those do not require official licensing of auditors. Historically, this was because we wanted to leave room for CACert. What they actually say is that they give definitions of a "competent party" and "independent party", and then say: "The burden is on the CA to prove that it has met the above requirements. However the CA may request a preliminary determination from us regarding the acceptability of the criteria and/or the competent independent party or parties by which it proposes to meet the requirements of this policy." I think a reasonable person might interpret this to mean that they needed to pick auditors who fulfilled the requirements in our policy, but don't need to _prove_ it unless asked. And they are not obliged to seek our determination. And I think that if we did ask Symantec to prove that the various bits of E&Y met the criteria in the policy at the time, I think they could probably do that. Other root programs may differ, of course. One could argue that, with CACert and its creative approach to cheaper auditing not really on the horizon any more, we should drop our custom definitions and just ask for a licensed auditor. > I think these may represent important questions for Mozilla to determine, > in order to evaluate the fullness of the claim you have summarized, and I > think would equally apply if we were discussing externally-operated > subordinate CAs, correct? Yes, I would expect externally-operated sub CAs to have the correct audits from a Mozilla-qualified auditor. > Considering the capability afforded to these RAs - full certificate > issuance through independent domain validation - I'm curious whether you > believe this materially represents a practical distinction from the > issuance of an unconstrained subordinate CA, and how responsible the > issuing CA is for overseeing those operations. If they didn't have control of the private key of their issuing intermediate(s) (as it seems they did not), then I do think this is a practical distinction from them being an unconstrained subordinate CA, in that they would e.g. not be audited for things like key management. In terms of the power they have, it's close - and, if the overseeing CA is not watching, basically identical. And there's the rub. As there is a distinction, then the CA should have been watching. If the CA were permitted not to watch, there would or should be no distinction in the BRs. And there is. Make sense? Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy