Thanks for the feedback on this plan, everyone. Gerv, Kathleen, and I have discussed it, and our judgement is that there's consensus here to move forward with the plan as proposed:
* 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 We may also enforce a whitelist, as suggested on the list, if it turns out to be feasible. We will need to have a follow-on discussion to work out some additional details, e.g., what conditions should be placed on CNNIC's re-inclusion. I will send a message starting that thread later today. There will shortly be a post on the Mozilla Security Blog outlining this decision, along with more background. https://blog.mozilla.org/security/ Thanks again to everyone for the robust discussion here. --Richard On Wed, Apr 1, 2015 at 1:35 PM, Richard Barnes <[email protected]> wrote: > 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 > will 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
