Regarding Peter's questions, - What response has their been from CNNIC on this issue? How do they explain issuing a subordinate CA certificate with a private key not being on a HSM meeting the Baseline Requirements? We informed MCS Holding provide an official report(attached) for this issue and revoked the intermediate root ASAP. I already send timeline and report of this incident to Kathleen. We issued this intermediate root for 2 weeks with testing proposal, we should constrain name constrain to the Sub CA as we already did constrain in EKU. At this question ,we need find a way to confirm how the private generated from HSMs or not.
- How many other CA certs has CNNIC issued which are not stored on HSMs? This is the first time we signed an external intermediate root. The current sub-CA(CNNIC SSL) is operated by CNNIC own and the private key is generate and stored in the HSMs. Regards, An Yin CA Product Manager --------------------------------------------------- = =Profession • Responsibility • Service= = China Internet Network Information Center （CNNIC） Tel: (8610)-58812432 mobile：13683527697 Fax: (8610)-58812666-168 Web: http://www.cnnic.cn Add: 4 South 4th Street, Zhongguancun, Haidian district, 100190 Beijing, China POB: Beijing 349, Branch 6 --------------------------------------------------- -----邮件原件----- 发件人: [email protected] [mailto:[email protected]] 代表 Peter Bowen 发送时间: 2015年3月24日 8:00 收件人: Richard Barnes 抄送: [email protected] 主题: Re: Consequences of mis-issuance under CNNIC On Mon, Mar 23, 2015 at 3:47 PM, Richard Barnes <[email protected]> wrote: > 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. Is there any data on this intermediate? - Was it publicly disclosed as per Mozilla's unconstrained subordinate policy? - Was it issued since their latest complete audit period ended and, if not, did their auditor flag it? - What response has their been from CNNIC on this issue? How do they explain issuing a subordinate CA certificate with a private key not being on a HSM meeting the Baseline Requirements? - How many other CA certs has CNNIC issued which are not stored on HSMs? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
