On Tue, May 26, 2015 10:56 pm, Matt Palmer wrote: > On Tue, May 26, 2015 at 02:26:33PM -0700, Kathleen Wilson wrote: > > But this raises the question of whether their re-application can be for > > the > > same (currently-included) root certificates, or if it has to be for a > > new > > root certificate. In other words, should we consider taking the stance > > that > > we will require a new root certificate for their re-application? (i.e. > > the > > restrictions would remain in place for the currently-included roots.) > > I think it would be best if CNNIC did not re-use the same roots when > applying for reinclusion.
I think it best that we settle this particular matter quickly, since it has the greatest impact on CNNIC's ability to adapt to any program requirements for re-inclusion. This, among every other requirement, has the greatest impact to timing, implementation (e.g. must be ceremonialized key construction), and evaluation. For what it's worth, I have a hard time seeing the benefits to requiring a new root, especially as it's played out for other inclusions, and in practice how it's played out for non-BR compliance (of which there are still a variety of CAs that are either non-compliant or have qualifications on their compliance). Naturally, the concern is the ambiguity for the period of time between removal and re-inclusion. However, that's a time that can be audited (no different than a point-in-time readiness assessment plus a covering period of time ex-post audit, arguably). Now, perhaps we don't trust the audits - after all, there were deficiencies in technical controls that lead to an event that was, from an auditor's perspective, undiscoverable, and it was only through sheer luck that it happened to be noticed. But that's a problem inherent to and endemic in audits, and doesn't disappear when you replace with a new root (... which will have a PITRA before application, and a period of time after application). While I realize Gerv responded earlier that Mozilla does not have an official position of support for CT, it is worth noting that this ambiguity (both during new inclusions and, potentially, for re-inclusions) is something that CT can solve quite well. This is because it offers a way to disclose the existing certs issued in the interim, if any (establishing reasonable evidence of good faith), and, if technically enforced (e.g. via a policy of trusted logs), provide strong assurances that there are no misissued certificates that might be trusted between the point of removal and the point of reinclusion (and all points in the future) To circle back on the new root, and to explain why I don't think it makes sense, the arguments would be: 1) Certificates that violate policy (such as the one that lead to CNNIC's quasi-removal) may have been issued that, if CNNIC were accepted, would become recognized as valid. 2) Auditors may not discover such certificates in the interim audit periods. #2 is true regardless of new or existing root. #1 can be mitigated through a variety of means (CT would reveal the policy violation, a date enforcement of a notBefore check could offer a soft policy check, I'm sure other options exist) that don't necessarily require creating a new root. Anyways, it would help to spell out the problems you think would be solved by a new root, even if not exhaustively, so that the arguments can be evaluated. Given the impact to CNNIC, we (the Mozilla-trusting community) need to have that conversation sooner than later, so I appreciate Kathleen pushing it forward. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
