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
