Regarding this Incident,
1, We prompt to response to Microsoft and Apple, and actively send incident report and CRL to Mozilla ASAP. We request MCS to take steps do more investigate. Quoting MCS report as following, “ MCS had received the Sub-ordinate certificate from CNNIC on mentioned date and started the test on same day inside MCS lab which is a protected environment, MCS had assured to store the private key in a FIPS compliant device (Firewall), to run the test which had started with no incidents on Thursday, and for the sack of unintentional action the Firewall had an active policy to act as SSL forward proxy with an automatic generation for a certificates for browsed domains on the internet, which had been taken place on a weekend time (Friday, and Saturday) during unintentional use from one of the IT Engineers for a browsing the internet using Google Chrome which had reported a miss-use at Google’s End.” MCS confirms that the reported issue is a human mistake that took place unintentionally through a single PC inside MCS Lab which had been dedicated for testing purposes. Quoting google spokesman, confirms: "We have no indication of abuse, and we are not suggesting that people change passwords or take other action". Claims by some public reports are inconsistent with statement by Google spokesman for abuse or spying activity for any traffic: “Google does not, however, believe the certificates were used for that purpose”. As stated by Google spokesman. 2, CNNIC request MCS to provide the screenshots and logs of detailed information of certificate issue, including SSL firewall logs, internet browsing logs of Google websites browsing records from personal browsers. We will update to Mozilla forum while we get and analyze the logs. 3, CNNIC are planning to update CA system to add name constrains function. 4, CNNIC will evaluate business security of the external subCA authorized and management 5, The device MCS used to mis-issuance cert is PaloAlto Firewall, we may consult more technical details about how it works as a SSL proxy and issue the cert automatically. We apply Mozilla do not remove CNNIC root from trust store as this is absolutely not a intension mis-issuance. CNNIC signed intermediate root for 2 weeks test, MCS signed cert for testing propose in Lab. While they made mistake, we prompt revoke the intermediate root not led to more harmful result. Regards, An Yin -----邮件原件----- 发件人: dev-security-policy-bounces+anyin=cnnic...@lists.mozilla.org [mailto:dev-security-policy-bounces+anyin=cnnic...@lists.mozilla.org] 代表 Kathleen Wilson 发送时间: 2015年3月26日 1:10 收件人: mozilla-dev-security-pol...@lists.mozilla.org 主题: Re: 答复: Consequences of mis-issuance under CNNIC All, I appreciate your thoughtful and constructive feedback on this situation. The suggestions regarding the CNNIC root certificates that I've interpreted from this discussion are as follows. These are listed in no particular order, and are not necessarily mutually exclusive. A) Remove both of the CNNIC root certificates from NSS. This would result in users seeing an over-rideable Untrusted Connection error. (Error code: sec_error_unknown_issuer) B) Take away EV treatment (green bar) from the "China Internet Network Information Center EV Certificates Root" certificate. Note that the "CNNIC ROOT" certificate is not enabled for EV treatment. C) Constrain the CNNIC root certificates to certain domains (e.g. .cn and .china) D) Suspend inclusion of (i.e. temporarily remove) the CNNIC root certificates until they have implemented CT, updated their CP/CPS to resolve the noted issues, updated their systems to enable issuing certs with name constraints, and have been re-audited. Did I miss any? Thanks, Kathleen _______________________________________________ dev-security-policy mailing list <mailto:dev-security-policy@lists.mozilla.org> dev-security-policy@lists.mozilla.org <https://lists.mozilla.org/listinfo/dev-security-policy> https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
