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

Reply via email to