Alright, one more pass at this. After more feedback from this list (thanks, all!) and some more conversation, I would like to propose something stronger than my last proposal:
* Do not remove the CNNIC root, but * Reject certificates chaining to CNNIC with a notBefore date after a threshold date*.* * Request that CNNIC provide a list of currently valid certificates, and publish that list so that the community can recognize any back-dated certs * Allow CNNIC to re-apply for full inclusion, with some additional requirements (to be discussed on this list) * If CNNIC's re-application is unsuccessful, then their root certificates w ill be removed This corresponds roughly to option (E) that Peter Bowen raised, and combines the E1 and E2 options noted by Ryan. I do not anticipate that we would make software changes to enforce a whitelist, but instead would rely on CNNIC not back-dating certificates, with the published list usable as a check for any certificates that the community finds (in the spirit of CT). The fact that CNNIC violated its CPS in issuing the MCS Holdings intermediate certificate calls into question whether they are adhering to their obligations more generally. The idea of this proposal is effectively to impose a moratorium on CNNIC issuing more certificates until they have assured the community that this is the case. Please consider this a last call for comments on this plan, and send any objections now. We hope to make a final decision in the next day or two. Thanks, --Richard On Sun, Mar 29, 2015 at 10:24 PM, Richard Barnes <[email protected]> wrote: > After some further thought on this issue, I would like to propose the > following course of action: > > 1. Remove the CNNIC root certificates > 2. (possibly) Temporarily add the CNNIC intermediate certificates > > Removing the CNNIC root certificates reflects the seriousness of the > breach of trust that CNNIC has incurred by deliberately issuing an > intermediate certificate in violation of its CPS, the BRs, and Mozilla > policies. CNNIC is of course free to re-apply to the root program, so this > removal is not necessarily permanent > > Adding the intermediates would allow CNNIC to continue to issue end-entity > certificates, and not penalize site owners immediately (as Peter notes). > However, it would prevent the acceptance of other intermediates, since the > improper issuance of intermediates is the immediate issue here. > > Further reasoning for this course of action follows. > > > # Recap of the options > > Summarizing the options expressed by Kathleen and Peter earlier: > > A) Remove both CNNIC root certificates > > B) Remove EV treatment for the CNNIC EV root > > C) Name-constrain the CNNIC roots > > D) Remove both CNNIC roots temporarily, with conditions for re-acceptance > > E) Only accept certificates already issued by CNNIC (not future ones) > > To these, I would like to add: > > F) Remove both CNNIC roots, but temporarily add the CNNIC intermediates > > This latter option would continue to allow CNNIC to issue end-entity > certicates, but not to issue further intermediates. > > > # My Analysis > > The underlying issue here is that CNNIC, apparently deliberately, violated > the BRs, Mozilla policy, and its own CPS by issuing an intermediate without > proper vetting. For me, the most troubling aspect of this is that CNNIC > violated their own CPS -- the covenant they make with the community for how > they will behave, and the basis for all the decisions that we make about > whether to trust them. > > The basic need here is thus to re-establish the community's confidence > that CNNIC will adhere to their obligations under their CPS, the BRs, and > Mozilla policy. As long as there is uncertainty on this point, it is > inappropriate for us to grant the unbounded trust implied by inclusion in > the root program, so there is at least a need place bounds on how CNNIC is > trusted. Ultimately, if CNNIC cannot assure the community that they will > adhere to their obligations, then they should not be in the root program. > > > ## Not (B), (C), or (E) > > Options (B) and (C) are only loosely related to the concerns about CNNIC's > behavior. While in general I'm enthusiastic about constraining CAs (see > the "Name Constraints" thread), in the context of this discussion, it would > be better to focus on the issues raised by CNNIC's incorrect decision to > issue an intermediate certificate to MCS Holdings. > > Option (E) is technically infeasible, for the reasons that Ryan noted. > > > ## Between (A), (D), and (F) > > In brief, my preference order is (A) > (F) > (D) > > Given how fundamental a violation it is for a CA to deliberately violate > its obligations, I think Mozilla would be within its rights to remove the > CNNIC roots (A). The Mozilla Certificate Policy says that roots may be > removed as a result of "ongoing or egregious" violations. Given the > multiple violations noted in Ryan's earlier message, I feel comfortable > labeling this incident "egregious", in the sense of "unusually serious". > > The only difference between (A) and (D) is that (D) establishes conditions > up front for CNNIC's readmission. Even in case (A), CNNIC may re-apply, > and they will have to go through the normal process for community approval. > I am hesitant to commit to conditions for re-admission up front, in case > any new issues arise in the interim. Any conditions that might be stated > in case (D) could also be stated in case (A) as part of the re-application > process. > > As a compromise, however, I would be willing to add the CNNIC > intermediates to the Mozilla root list (F). (Ideally, with an additional > path length constraint, set to zero.) This would enable CNNIC to continue > issuing end-entity certificates, without the possibility of adding > intermediates. Since CNNIC's policy regarding intermediates is the > immediate issue here, this seems like a reasonable compromise. However, > these intermediate certificates should not be admitted indefinitely. > Rather, we should plan to remove them after a fixed time (say 6 months) or > after CNNIC's re-application is resolved, whichever comes first. > > On Mon, Mar 23, 2015 at 6:47 PM, Richard Barnes <[email protected]> > wrote: > >> Dear dev.security.policy, >> >> It has been discovered that an intermediate CA under the CNNIC root has >> mis-issued certificates for some Google domains. Full details can be found >> in blog posts by Google [0] and Mozilla [1]. We would like to discuss what >> further action might be necessary in order to maintain the integrity of the >> Mozilla root program, and the safety of its users. >> >> There have been incidents of this character before. When ANSSI issued an >> intermediate that was used for MitM, name constraints were added to limit >> its scope to French government domains. When TurkTrust mis-issued >> intermediate certificates, they changed their procedures and then they were >> required to be re-audited in order to confirm their adherence to those >> procedures. >> >> We propose to add name constraints to the CNNIC root in NSS to minimize >> the impact of any future mis-issuance incidents. The “update procedures >> and re-audit” approach taken with TurkTrust is not suitable for this >> scenario. Because the mis-issuance was done by a customer of CNNIC, it’s >> not clear that updates to CNNIC’s procedures would address the risks that >> led to this mis-issuance. We will follow up this post soon with a specific >> list of proposed constraints. >> >> Please send comments to this mailing list. We would like to have a final >> plan by around 1 April. >> >> Thanks, >> --Richard >> >> [0] >> http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html >> [1] >> https://blog.mozilla.org/security/2015/03/23/revoking-trust-in-one-cnnic-intermediate-certificate/ >> > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
