I come from the discuss of the bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=542689
this is my opinion about your latest plan: The CNNIC's root CA on how to issue an intermediate certificate process obviously lack of transparency and responsibility, while you still ask the community members to provide you the so called professional evidence: "We ask your continued patience and request that further input remain professional and focused on providing concrete evidence that can be acted on according to the Mozilla CA Certificate Policy" Is this sound like a joke? is this unauthorized digital certificates for several Google domains are professional enough evidence? And still you give CNNIC a chance to re-apply, without any detailed requirement on the transparency (yes, you said you will discuss this later, but you allowed CNNIC to re-apply already), meanwhile you chose to only revoke one CNNIC Intermediate Certificate not the root CA, it is fully not acceptable by me and it still hurt the security of the Mozilla products user. and for your Request for CNNIC to provide a list of balabala, I will be very very happy to see you will get a buggy English response/Statement from CNNIC like this later: http://www1.cnnic.cn/AU/MediaC/Announcement/201504/t20150402_52049.htm At that time, I hope it is not another 5 or 6 years later, I will personally ask you(who decided to include CNNIC root CA into Mozilla before and refuse to revoke CNNIC CA now) a question: is it hurt to be slapped on the face again and again? On Thursday, April 2, 2015 at 1:35:34 AM UTC+8, Richard Barnes 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 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
