Hello Anyin, It's really unfortunate to get such absolute incorrect and prejudiced feedback I sent the truth inside the requested report and i am ready to submit any required proofs from our Firewall Logs as we reported I don’t think being a company established 8 years ago with a very successful projects references across the middle east with a direct partnership with a leading world wide companies like Intel, PaloAlto, Juniper and riverbed with a fully compliance history to the import regulations for the security products might submit a report with incorrect information!!!! i appreciate your revisiting to the report carefully then inquiring for the uncleared issues, studying our feedback and proofs Then finally to judge either the submitted information is delivering the truth or not !!! That’s the logic !! again, i am open for discussion and to respond to any objective inquiries !!
Regards, Amr Farouk Managing Director Mideast Communication Systems 5 Al Sherka Al Portsaidya St, off Asmaa Fahmy St. Behind Rekaba Idareya Building, 11341 Heliopolis. Cairo, Egypt Mobile: +2 (0122) 3929889 Office (Tel): +2 (02) 2290 9326 Office (Fax):+2 (02) 2415 3565 Email: a...@mcsholding.com <mailto:a...@mcsholding.com> Website: www.mcsholding.com <http://www.mcsholding.com/> Mideast Communication Systems – Tomorrow’s Solutions Today TM > On Mar 24, 2015, at 4:35 AM, Anyin <an...@cnnic.cn> wrote: > > It's so not ture. I am sure this misuse is not intentional. Actually the > MCSHolding is contact CNNIC first early in the 2015. After dicussion, we > signed agreement to issue a 2 weeks intermediate root for testing propose. > > And we take action to revoke the intermediate root as soon as we received > report from Microsoft and Apple, and strongly request MCS to provide sealed > and signed offcially report(attached). > > And I sent the incident report include whole timeline of this case to > Kathleen intiatively to avoid more harmful result of the misused cert. > > So this is absolutely not a intentional issue. > > Our Webtrust Audit will start soon in April, we surely will take action to > improve security management and dicussed with audit team(Ernst & Young) if > we decide to have external intermediate Root authorization in the future. > > CC to Amr from MCS HOLDING. > > > Regards, > An Yin > > > -----邮件原件----- > 发件人: dev-security-policy-bounces+anyin=cnnic...@lists.mozilla.org > [mailto:dev-security-policy-bounces+anyin=cnnic...@lists.mozilla.org] 代表 > David E. Ross > 发送时间: 2015年3月24日 10:23 > 收件人: mozilla-dev-security-pol...@lists.mozilla.org > 主题: Re: Consequences of mis-issuance under CNNIC > > On 3/23/2015 5:59 PM, Peter Kurrasch wrote: >> Hi Richard, >> >> Is the proposal to limit CNNIC roots to only .cn domains or would others > be allowed? >> >> I'm curious to know what CNNIC's perspective is on this proposal, so will > a representative be replying in this forum? >> >> Thanks. >> >> Original Message >> From: Richard Barnes >> Sent: Monday, March 23, 2015 5:48 PM >> To: mozilla-dev-security-pol...@lists.mozilla.org >> Subject: Consequences of mis-issuance under CNNIC >> >> 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-c >> ertificate-security.html >> [1] >> https://blog.mozilla.org/security/2015/03/23/revoking-trust-in-one-cnn >> ic-intermediate-certificate/ >> _______________________________________________ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy >> > > What assurance is there that the mis-issued certificates were not > intentional. The approval of the CNNIC was quite controversial. > Assertions were made that CNNIC is actually an agent of the Chinese > military. > > -- > David E. Ross > > I am sticking with SeaMonkey 2.26.1 until saved passwords can be used when > autocomplete=off. See > <https://bugzilla.mozilla.org/show_bug.cgi?id=433238>. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > <CCI20150319_00000.jpg><CCF20150319_00000.jpg><B1.pdf><B2.pdf> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
