On Wed, Mar 8, 2017 at 10:30 AM, Gervase Markham <g...@mozilla.org> wrote:
> 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? > That is precisely the goal. We could define a set of process and procedures specific to DTPs, which is effectively duplicitive with the handling of subordinate CAs, or we could strive to align the two both conceptually and materially, since, as you note below, there's a number of similarities in the risk profile. The concern with the approach of both DTPs and subCAs is that it's very easy for nuanced and subtle distinctions to be introduced, and as such, it seems better to avoid that when possible by aligning on the majority-common portion. > > 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) Note: It does not appear you've updated https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ - do you plan to? https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/ still links to it, as does https://wiki.mozilla.org/CA:Overview - so I suspect there's still a substantial bit of cleanup work to do here ;) (Plus the bugs introduced in 2.4 that were missed until the 2.4.1 discussion, such as the scope, which isn't present in 2.3) > 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: > I'm surprised by that reading, because Item 3 of that section states By "competent party" we mean a person or other entity who is authorized to perform audits according to the stated criteria (e.g., by the organization responsible for the criteria or by a relevant government agency) or for whom there is sufficient public information available to determine that the party is competent to judge the CA’s conformance to the stated criteria. In the absence of a proper license, such parties are not "authorized to perform audits according to the stated criteria", so the only question is whether "there is sufficient public information available to determine that the party is competent to judge the CA's conformance to the stated criteria". I recognize that Item 2 "replaces" the criteria for Section 8.2, but such a replacement is neither reflected within the audit report produced (when complying with the BRs) with respect to the issuing CA's oversight of the DTP - that is, you might reasonably expect a qualification, but for Mozilla to ignore said qualification, consistent with Item 2 of "Audit Requirements". "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. > I find this an interesting and surprising interpretation, because I long believed the intent and letter of Mozilla policy is that Mozilla required such determination in the cases of accepting subordinate material, and the burden of proof rests with them when presenting such material to Mozilla during inclusion. > Yes, I would expect externally-operated sub CAs to have the correct > audits from a Mozilla-qualified auditor. > Just to be clear: Given the definitions above, you believe it's acceptable for sub-CAs to be issued to parties on the basis of the CA's judgement as to whether there is "sufficient public information available to determine that the party is competent to judge the CA's conformance to the stated criteria", and that so long as they do so, it does not represent any form of violation of Mozilla Policy, even if the CA makes an error in that judgement? I can understand and appreciate its relevance to root inclusion requests - in which Mozilla is ultimately responsible for making that judgement and evaluation - but as you've described, you've suggested a scenario where even if Mozilla disagrees with the CA's evaluation, and even if the CA is unable to prove to Mozilla's satisfaction that the auditor meets that qualified definition, because the CA exercised that judgement, it does not represent a violation of Mozilla's policy? I'm sure you can see the danger in that interpretation :) > > > 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. > So the extent of your concern is whether sufficient audit logs were maintained, since key management is simply a subset of ensuring an appropriate trail related to issuance and services. I highlight this, because at least one of these DTPs failed to maintain sufficient audit logs, and Symantec has stated it plans to continue using this information - information improperly secured, improperly maintained, and with improper access controls - for the issuance of certificates. > 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? > Unfortunately, I'm not sure I follow. Would you be able to rephrase? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
