回复：Fond Farewell to Gerv Markham

[谭晓生 via dev-security-policy]

So sad to hear that.
Respect him.

Best,
Xiaosheng Tan

 原始邮件 
主题：Fond Farewell to Gerv Markham
发件人：Kathleen Wilson via dev-security-policy
收件人：mozilla-dev-security-pol...@lists.mozilla.org
抄送：

Dear Fellow Mozillians,

It is with deep sorrow that we share the news that our friend and
colleague, Gerv Markham, passed away on July 27, 2018. Along with the
many others whom he worked alongside over his time at Mozilla, we will
remember Gerv as caring, honest, inquisitive, opinionated, energetic,
and a lot of fun to work with! He enjoyed and looked forward to meeting
with people in person, and loved diving into the details. He was often
the first to pick up the phone to talk to people to get to the core of a
situation. He was also quick to be helpful, going out of his way to
provide assistance where needed. He would identify things that were in
need of repair, meet with the owners to find out if they needed help,
and dive right in to do the work.

Previously from Gerv: “It's been eighteen years since I first entered
the world of Mozilla, on a program of constructing reduced layout test
cases for early Gecko builds in order to earn a dino plushie (I got
two!). Both I and the project have come a long way since then, but an
ever-present companion has been my cancer, with which I was diagnosed in
2001.”

Eighteen years is a remarkable length of time to fight against incurable
illness, and we are proud for the fighting Gerv managed to do throughout
those years to advance Mozilla's mission.

Over the years of Gerv’s tenure with Mozilla, he worked on public
policy, certificate authority (CA) root program, community governance,
MPL, licensing, usability, security, and Bugzilla. He attended every
CA/Browser Forum face-to-face meeting that he could, and the CA/Browser
Forum extended the attached commendation to him.

It has been an honor to work with Gerv, and it is with very fond
memories that we say goodbye to our wonderful friend and colleague, Gerv
Markham.

Fond Farewell,

Kathleen Wilson, Wayne Thayer, JC Jones, and Chris Riley (among many more)


PS: Here is the text from the CA/Browser Forum Commendation that is
mentioned above.
~~
The CA/Browser Forum and its members gratefully extend to Gervase
Markham their heartfelt commendation and appreciation
For his extraordinary leadership and skill as a founding member of the
Forum in 2005 and as a Mozilla representative and a leading Forum
participant from 2005�C2018, and
For his superb work in promoting higher standards for Certification
Authorities, and
For his ceaseless efforts to improve security for users on the internet, and
For sharing his deep knowledge of TLS and PKI with his fellow Forum
members, and
For his constant innovation and improvement to the Mozilla processes
applicable to CAs around the world, and
For his skills during Forum meetings and teleconferences so that all
could participate on an equal basis and members’ time was well spent, and
For his ability to bridge differences of opinion among members to reach
solutions that could be supported by all, and
For his tact and diplomacy in helping Certification Authorities and
Browsers meet their mutual goals, and
For his patience, wit, sincerity, honesty, pleasant demeanor, and
everlasting good cheer, and
For his superior guidance, advice, and management style.
-- For these and many other accomplishments we hereby affirm our deep
appreciation, commendation, and congratulations to Gerv, and sincerely
extend our best wishes to him and his family. --
Dated this 22nd day of March, 2018.
ADOPTED UNANIMOUSLY BY THE MEMBERS OF THE CA / BROWSER FORUM
~~
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
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

Termination of the certificates business of Startcom

[谭晓生 via dev-security-policy]

Dear all,

This is the Chairman of StartCom's board, Xiaosheng Tan. StartCom has 
experienced a very difficult time in our re-inclusion process. Due to some 
comments and decisions made by the Mozilla community, which are followed by 
some other browsers, StartCom’s board made a difficult but final decision after 
careful consideration. We will initiate the termination procedure of the 
StartCom business. The liquidation procedure will begin and follow our CPS and 
internal procedures. We´ll set January 1st 2018 as the termination date and 
will stop issuing certificates therefrom. We will maintain our CRL and OCSP 
service for two more years from January 1st 2018. The three pairs of StartCom 
key Roots will be eliminated after that time.

On behalf of the StartCom’s board, I would like to thank Mozilla Community, 
especially Gervase, for their positive influence on StartCom. Thanks for your 
explicit decision making, so that we could know what to do in the next step and 
no more detour. We really appreciate that.
Also, Qihoo 360, even as the largest security company in China, is extremely 
impressed by Cure53’s high efficient work.Thanks for Cure53’s top level 
security audit, which made us realize that we still have room for improvement.
There is no doubt that Inigo made an excellent work since we decided to let him 
do the CEO job. His great experience helped StartCom save a lot of time and 
money. Also, I would like to thank all the StartCom staff for their excellent 
work during this tough time.

Yes, of course we will still contribute to Community and focus on security 
research. During the last ten years, the 360 security research teams have 
discovered hundreds of vulnerabilities in the major software companies and 
earned many acknowledgments in the world. Qihoo 360 and the PKI community share 
the same goal, which is making the internet a better place.

Thank you.

Best regards,
Xiaosheng Tan



--
Xiaosheng Tan Chief Security Officer
Beijing Qihoo Technology Co.,Ltd (Qihoo 360)
Mobile: +86 13911122339, +86 13311122339
Email: tanxiaosh...@360.cn
Web: www.360.cn
Address: Bldg 2, 6 Haoyuan, JiuXianQiao Rd, ChaoYang Dist, Beijing, 100015


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: wosign and letsencrypt.cn / letsencrypt.com.cn

[谭晓生]

It is ICP license you talked about, you can find some information here:
https://support.cloudflare.com/hc/en-us/articles/209714777-ICP-FAQ

It is almost impossible to register a .cn or .com.cn domain in China for a 
foreign company which do not have a legal entity in China, legally.
The websites will be blocked for access by the ISP/Telco if the websites were 
hosted in China but do not have valid ICP licenses or even the IPs have not 
been registered to the government. if it is not that hard before, but it has 
more and more regulatory polices.

For Letsencrypt, if you want to own the .cn or .com.cn domain legally, think of 
to set a legal entity in China.

Thanks，
Xiaosheng Tan



在 2016/12/20 上午10:54，“dev-security-policy 代表 Samuel 
Pinder” 写入:

As far as I know, transferring by entering the name and address of the
person to transfer to would work via your registrar. But then CNNIC
will want to see a photo of a passport showing the name of the person
in full within a certain deadline, otherwise the domain would be
suspended. A registrar gathers this from the intended registrant and
they send it to CNNIC on your behalf, you don't send it directly to
CNNIC. Of course there is distinction between a person and a company,
if you're transferring to a company, you'll need business documents
showing registration details.
See this FAQ: https://cnnic.com.cn/IS/CNym/cnymyhfaq/#8_1
One more thing to be aware of not listed in the FAQ there: CNNIC will
want to know if you will be using the domain within China, as that
requires an ACP licence for any website hosted on port 80, 8080, or
443. Choosing "no" would mean the domain would resolve, but any
website on it would be inaccessible within China and would only work
abroad, since ACP licences *apparently* are only available to Chinese
companies. What this effectively means for Let's Encrypt, you'd have
the domain name to protect it, but wouldn't be able to use it within
China unless you had an actual presence there and acquired an ACP
licence. I registered a .cn domain some time ago, so just thought I'd
share my knowledge. Good luck, and sorry it kinda goes outside the
scope of this thread.
Sam


On Tue, Dec 20, 2016 at 2:28 AM, Richard Wang  wrote:
> I got the email from Josh, this is my reply:
>
> Hi Josh,
>
> Glad to receive your formal request email.
>
> Yes, it is hard to register a domain for foreigner, I also don't know how 
to transfer to you. What I can do now is to resolute it to your website.
>
> As I said we can transfer to you at any time.
>
>
> Best Regards,
>
> Richard
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] 
On
> Behalf Of j...@letsencrypt.org
> Sent: Monday, December 19, 2016 12:36 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: wosign and letsencrypt.cn / letsencrypt.com.cn
>
> We had some trouble figuring out how to purchase a Chinese domain name 
before
> we launched, so we didn't purchase it then. We've never talked to wosign 
about
> this before, and we haven't seen the domain used for anything confusing so
> far. This is our first interaction about it and we're happy to hear that
> Richard would like to help us out by transferring the domains.
>
> Thanks Richard, I'll be in touch.
>
> On Sunday, December 18, 2016 at 7:45:16 PM UTC-6, Richard Wang wrote:
>> I wish everyone can talk about this case friendly and equally.
>>
>> It is very common that everyone can register any domain based on the 
first
>> come and first service rule.
>>
>> We know Let's Encrypt is released after the public announcement, but two 
day
>> later, its .cn domain is still not registered, I think maybe it is 
caused by
>> the strict registration rule in China, so I registered it for protection
>> that not registered by Cornbug.
>>
>> We don’t use those domains for any WoSign's services that we provide
>> similar service: https://pki.click/index_En.htm (SSL Wizard, 
StartEncrypt)
>>
>> Now, if Mozilla or Let’s Encrypt contact me officially and request to
>> transfer the two domains to them, no any problem, we can transfer to them
>> for FREE!
>>
>> But please notice that this arrangement is for friendship, not for others
>> ..
>>
>>
>> Best Regards,
>>
>> Richard
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/de

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[谭晓生]

Agree with Gerv & Tony,
More patience should be given if they want to improve.

And I don’t think “I posted on the solidot (Chinese Slashdot) about this. The 
majority comments want the application rejected. “is enough to be the reason to 
reject the request.
For many Chinese companies, they do need to learn how to work with global 
community, they might even have language issues to use English as the working 
language, for Guang Dong CA case, I can see they are willing to work with the 
community and we should encourage them to do more.

Thanks，
Xiaosheng Tan



在 2016/11/15 下午9:08，“dev-security-policy 代表 
Tony” 写入:

在 2016年11月15日星期二 UTC+8下午5:53:19，Gervase Markham写道：
> On 15/11/16 08:39, Percy wrote:
> > I posted on the solidot (Chinese Slashdot) about this. The majority
> > comments want the application rejected.
> > 
https://translate.google.com/translate?hl=en&sl=zh-CN&tl=en&u=http%3A%2F%2Fwww.solidot.org%2Fstory%3Fsid%3D50368
> 
> That fact, by itself, is not useful information. It would help if you
> were to summarise why people feel the application should be rejected,
> and how those reasons map to Mozilla's policy requirements.
> 
> Gerv

Agreed with Gerv, the reasons for rejection/improvements should be listed 
very clearly in this case, considering the positive actions taken by CA as it 
will publish the full new version of CP/CPS in English and implement version 
control on EN CP/CPS.  

It's common that Chinese company only maintains one master file policy 
which is in Chinese based on experience.  But if they can do one version 
control on EN policies, even from now on, it should be deemed as a good 
improvement.  

Also,  guidance for coaching the CA to enhance the internal controls for 
the future is needed.  More patience shall be given.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
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

Re: Apple's response to the WoSign incidents

[谭晓生]

We looking for the new CEO of Wosign actively and talking with several 
candidates, as the current situation as you know, it is a little bit difficult 
to make the candidates accept the offer, but it will be done soon, please be 
patient a little bit.

Thanks，
Xiaosheng Tan



在 2016/11/14 上午7:25，“dev-security-policy 代表 Richard 
Wang” 写入:

I said many times that I am the Acting CEO of Wo sign now till the new CEO 
arrives.

Even I am not the CEO instead of an employee, I think I can response the 
email about WoSign that just tell everyone the fact, not representing the 
company making any new decision.

Please check my previous replied emails.

Best Regards,

Richard

> On 14 Nov 2016, at 04:46, Percy  wrote:
> 
>> On Saturday, October 1, 2016 at 2:02:25 AM UTC-7, 
certificate-au...@group.apple.com wrote:
>> Blocking Trust for WoSign CA Free SSL Certificate G2
>> 
>> Certificate Authority WoSign experienced multiple control failures in 
their certificate issuance processes for the WoSign CA Free SSL Certificate G2 
intermediate CA. Although no WoSign root is in the list of Apple trusted roots, 
this intermediate CA used cross-signed certificate relationships with StartCom 
and Comodo to establish trust on Apple products.
>> 
>> In light of these findings, we are taking action to protect users in an 
upcoming security update.  Apple products will no longer trust the WoSign CA 
Free SSL Certificate G2 intermediate CA.
>> 
>> To avoid disruption to existing WoSign certificate holders and to allow 
their transition to trusted roots, Apple products will trust individual 
existing certificates issued from this intermediate CA and published to public 
Certificate Transparency log servers by 2016-09-19. They will continue to be 
trusted until they expire, are revoked, or are untrusted at Apple’s discretion.
>> 
>> As the investigation progresses, we will take further action on 
WoSign/StartCom trust anchors in Apple products as needed to protect users.
>> 
>> Regards,
>> 
>> Apple Root Certificate Program
> 
> Richard,
> As the management reshuffling is part of WoSign/StartCom's response, may 
I ask under what capacity are you still representing WoSign on this forum?
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> 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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[谭晓生]

Nothing compelled by the gov to trust the self-issued certificates.

It is because some very large website like 12306.cn(the only one online entry 
to buy rail way tickets in China) and some government websites, they still 
using self-issued certificates, even we tried to offer free trusted 
certificates to them, they rejected.
If a local browser try to block the access to these websites, user will force 
the browser to trust the self-issued certificates and complain, for the 
behavior training to end users, it is also an issue, user will used to trust 
the certificates which have a warning message by browsers, even there is a MITM 
attack, they still could not identify it.

That’s the dilemma we have:
Block the access to self-issued certificates, user will ignore and force trust 
the certificated, bad behavior training, user might change to competitor’s 
product.
Do not block the access, there are possibility to do the MITM attack, the 
community complains.

We already worked on a solution for a while and will release a report soon, 
hopefully to find a tradeoff between user experience and security.

Thanks，
Xiaosheng Tan


发件人: Percy 
日期: 2016年10月30日 星期日 下午4:01
至: 晓生 谭 
抄送: "mozilla-dev-security-pol...@lists.mozilla.org" 

主题: Re: StartCom & Qihoo Incidents

As we observed the large scale MITM against iCloud, Outlook, Google and Github 
carried out on the backbone router with self-signed certs, and that the 
browsers are explicitly loads self-signed certs, I think it's clear that 
browsers in China are compelled by the gov to enable insecure cryptography by 
default.

Percy 
Alpha(PGP<https://pgp.mit.edu/pks/lookup?op=vindex&search=0xF30D100F7FE124AE>)


On Sat, Oct 29, 2016 at 11:36 PM, 谭晓生 
mailto:tanxiaosh...@360.cn>> wrote:
Is there anybody thought about why it happens in China? Why the local browser 
did not block the self-issued certificates?

Thanks，
Xiaosheng Tan



在 2016/10/30 下午1:17，“Percy”mailto:percyal...@gmail.com>> 
写入:

On Saturday, October 29, 2016 at 5:54:10 PM UTC-7, Matt Palmer wrote:
> On Sat, Oct 29, 2016 at 02:59:07PM -0700, Percy wrote:
> > Perhaps not. However, Qihoo 360's behavior calls the trustworthiness of 
the
> > entire company into question. And such trust, in my view, should be
> > evaluated when WoSign/StartCom submit their re-inclusion requests in the
> > future.
>
> You can make that argument when WoSign/StartCom's reinclusion discussions
> take place on this list.  Now is not the appropriate time for that.
>
> - Matt
WoSign/StartCom's re-inclusion request might be a year from now. In the 
meanwhile, those 400 million users will be exposed to MITM. That's why I'm 
bringing it up now, rather than one year later.
___
dev-security-policy mailing list

dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
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

Re: StartCom & Qihoo Incidents

[谭晓生]

Is there anybody thought about why it happens in China? Why the local browser 
did not block the self-issued certificates?

Thanks，
Xiaosheng Tan



在 2016/10/30 下午1:17，“Percy” 写入:

On Saturday, October 29, 2016 at 5:54:10 PM UTC-7, Matt Palmer wrote:
> On Sat, Oct 29, 2016 at 02:59:07PM -0700, Percy wrote:
> > Perhaps not. However, Qihoo 360's behavior calls the trustworthiness of 
the
> > entire company into question. And such trust, in my view, should be
> > evaluated when WoSign/StartCom submit their re-inclusion requests in the
> > future.
> 
> You can make that argument when WoSign/StartCom's reinclusion discussions
> take place on this list.  Now is not the appropriate time for that.
> 
> - Matt

WoSign/StartCom's re-inclusion request might be a year from now. In the 
meanwhile, those 400 million users will be exposed to MITM. That's why I'm 
bringing it up now, rather than one year later. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
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

Re: StartCom remediation plan

[谭晓生]

Dear Gerv,

We’ll rewrite all the code with different programing language or buy 3rd party 
components (for example: PKI), Wosign team using .Net, but my team never use 
.Net, they are good at C/C++ and PHP, Python.

Thanks，
Xiaosheng Tan



在 2016/10/14 下午11:01，“dev-security-policy 代表 Gervase 
Markham” 写入:

Hi Inigo,

On 14/10/16 09:16, Inigo Barreira wrote:
> In this link,
> https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf,
> you´ll find the detailed remediation plan for StartCom as was notified 
last
> week. 

Thanks for this. Is this a correct summary of the situation as regards
the origin of the codebases?

Website/Ordering System

Before: WoSign-authored, but not the same as the one WoSign uses
After:  Same WoSign-authored code, audited and improved by Qihoo R&D

CMS

Before: WoSign-authored, but not the same as the one WoSign uses
After:  Same WoSign-authored code, audited and improved by Qihoo R&D

PKI

Before: WoSign-authored, same code that WoSign uses
After:  StartCom-authored, improved by Qihoo R&D (short term)
Third-party solution (medium term)

OCSP/CRL

Before: WoSign-authored, same code that WoSign uses
After:  Same WoSign-authored code, audited and improved by Qihoo R&D


From my perspective, the "technical separation" part is more than just
"not using the same servers WoSign uses" or "not running the same code
that WoSign runs". One of the things we have lost confidence in is the
coding of the WoSign development team, and therefore any piece of code
remaining which they wrote is suspect - no matter whether it is
StartCom-specific or also run by WoSign.

Given that, it is concerning that after your plan is executed, 3 of the
4 key systems will still be running WoSign-authored codebases, even if
they have been audited and improved to some degree by Qihoo R&D. For
each system where that is true, I think that Mozilla may wish to require
a full external security audit, which would both be expensive and
time-consuming (and may lead to a great deal of remediation required).

Was consideration given to switching back to the old StartCom codebase,
or buying in a third party solution, for the website, the CMS or the
OCSP/CRL function?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
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

Re: StartCom & Qihoo Incidents

[谭晓生]

Are there any words saying “award to Qihoo to recognize their long time support 
for censorship”? 
It is an official thanks letter from The Ministry of Public Security of the 
People’s Republic of China, the equivalent organization with FBI of U.S, it 
thanks for my team and myself to join the information security work the 3rd 
Sept military review affair! I can tell you that my team and myself joined the 
information security work for G20 meeting just finished last month, I might got 
a thanks letter soon, is there anything wrong to do that? 

If anybody care about this, please ask somebody to translate this letter for 
you, I do not have time to waste here on somebody lied.

For the malware accuses, Yahoo acquired 3721 in 2003, do you think Yahoo 
acquired a malware company? Is there any anti-virus software killed 3721’s 
software? 

Thanks，
Xiaosheng Tan



在 2016/10/13 下午5:26，“dev-security-policy 代表 
solar” 写入:

Some more information. 

3721 helper, the most notorious malware in china was created by Hongyi zhou 
and his company 3721 in 1998. According to Mr. Tan's bio, he was the 
development director of 3721. So I believe he directly participated in and led 
the development of the malware.

There is another evidence of Qihoo cooperating with chinese government to 
censor the internet. Last year, the Ministry of Public Security (the 
stakeholder of GFW) give an award to Qihoo to recognize their long time support 
for censorship especially during the event of the 70th anniversary of the 
victory of World War II. The official paper of the award 
(http://www.canyu.org/n102771c6.aspx) was listed on Qihoo website. But it was 
soon removed before widely exposed in public. Moreover, the chinese name(谭晓生) 
of Mr. Tan Xiaosheng was mentioned in the official paper.

I do NOT trust the person who developed malware, and I also do NOT trust 
the CA involved in censorship.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
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

Re: StartCom & Qihoo Incidents

[谭晓生]

The information on Baidu Baike is not correct, I tried to correct it, but 
failed, I don’t know why.
I’m the Vice President of Qihoo 360 from end of 2009, installed as Chief 
Privacy Officer from 15th March 2012 as well, titled as Chief Security Officer 
of Qihoo 360 from Feb 2016, I never been the CTO of Qihoo 360.
I’m the school mate of Mr.Hongyi Zhou, same grade, but not in the same class, 
both in Computer Science and Engineering Dept of Xi’an Jiaotong University from 
1988 to 1992, I worked for Mr.Zhou from 2003 to 2005, then 2009 till now.
I’m here on behalf of myself, and answer some question about Qihoo 360 under 
the authority of my responsibility: Chief Security Officer, I should take care 
of the information security related issues.
Is there anybody think any information in the cyber space is truth? It is funny.

Thanks，
Xiaosheng Tan

在 2016/10/13 下午4:22，“dev-security-policy 代表 
solar” 写入:

Mr. Xiaosheng Tan

According to the page of your personal details 
(http://baike.baidu.com/view/4571996.htm) in Baidu BaiKe. Currently you are the 
CTO and VP of Qihuoo. And you have a long recorder working and even studying 
with Hongyi Zhou, the CEO and the owner of Qihoo who was entitled as "the 
father of Chinese malware" by netizen.

So, do you represent your company to explain the issues? or Hongyi Zhou? or 
only yourself?

On Thursday, October 13, 2016 at 10:58:34 AM UTC+8, 谭晓生 wrote:
> Yuwei, 
> I don’t know who you are, but I can tell you and the community, Qihoo 360 
never been involved in * Fire Wall project, if you did some investigation 
to the message that accused Qihoo 360 joined the project “Search Engine Content 
Security Management System”, you should know the project had been done on Feb 
2005, before Qihoo 360 was founded on Aug 2005, and the project is neither part 
of the * fire wall project nor a project done by Qihoo 360, actually it is 
part of the efforts to help Yahoo’s search engine could work in China, I was 
the tech head of Yahoo!China ‘s tech team, director of engineering and soon the 
CTO of Yahoo!China, I know what happened at that time.
>  
> Thanks，
> Xiaosheng Tan
> 
> 
> 
> 在 2016/10/13 上午5:22，“dev-security-policy 代表 Han 
Yuwei” 写入:
> 
> 在 2016年10月13日星期四 UTC+8上午3:12:08，Ryan Sleevi写道：
> > As Gerv suggested this was the official call for incidents with 
respect to StartCom, it seems appropriate to start a new thread.
> > 
> > It would seem that, in evaluating the relationship with WoSign and 
Qihoo, we naturally reach three possible conclusions:
> > 1) StartCom is treated as an independent entity
> > 2) StartCom is treated as a subsidiary of Qihoo
> > 3) StartCom is treated as a subsidiary of WoSign
> > 
> > We know there are serious incidents with WoSign that, collectively, 
encourage the community to distrust future certificates. However, there hasn't 
been a similar investigation into the trustworthiness of StartCom as an 
independent entity or as an entity operated by Qihoo. It would seem that 
germane to the discussion is how trustworthy the claims are - from either 
StartCom or Qihoo - and how that affects trust.
> > 
> > Incidents with StartCom:
> > A) Duplicate Serials. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
> > We know that StartCom had issues issuing duplicate serials, in 
violation of RFC 5280. We know that they did not prioritize resolution, and 
when attempting resolution, did so incompletely, as the issue still resurfaced.
> > 
> > C) Improper OCSP responder. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
> > We know that StartCom continues to have issue with their OCSP 
responder after they issue certificates. Presumably, this is a CDN distribution 
delay, but we can't be sure, especially considering Incident A was with the 
underlying systems. As a consequence of this, users with StartCom certificates 
are disproportionately disadvantaged from enabling OCSP stapling, which many 
browser programs support (and is perhaps the only viable path towards a 
complete revocation solution).
> > 
> > E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 
/ https://bugzilla.mozilla.org/show_bug.cgi?id=994478
> > We know StartCom had a notoriously poor response to HeartBleed. 
Eddy first dismissed the significance, and then when proven wrong, still 
continued to charge $25 USD for revocation. Ostensibly, this is a violation of 
the Baseline Requirements, in that CAs are required to revoke certificates 
suspected of Key Compromise. However, despite the BRs effective date of 2012, 
Mozilla was not a

Re: StartCom & Qihoo Incidents

[谭晓生]

There could be multiple books to tell the story of Qihoo 360 and Mr.Hongyi 
Zhou, Qihoo 360 fighted with Baidu, Alibaba & Tencent, the three largest 
internet companies of China in the past 10 years, there were a lot of law suits 
there, win and lose together, the ecosystem of China internet is a little bit 
special with others of the world, it is not my focus to discuss that here.
After 11 years, Qihoo 360 is the largest internet security company of China, 
the products are widely adopted by China internet users, it is not something 
could be instructed by the government, we must did something right.

Thanks，
Xiaosheng Tan

在 2016/10/13 上午10:35，“dev-security-policy 代表 
shangh...@gmail.com” 写入:

在 2016年10月13日星期四 UTC+8上午6:24:50，Percy写道：
> The Chinese wikipedia has well documented controversies surrounding Qihoo 
360. Unfortunately, it's not translated into the English Wikipedia. So please 
go to 
https://zh.wikipedia.org/wiki/%E5%A5%87%E8%99%8E360#.E5.95.86.E4.B8.9A.E7.9F.9B.E7.9B.BE.E4.B8.8E.E4.BA.89.E8.AE.AE.E4.BA.8B.E4.BB.B6
 and use Google Translate.

金山公司发布“360涉嫌偷窃用户隐私”的文章，并通过金山电池医生的弹窗散布相关信息

This is true, Search upload.360safe.com.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
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

Re: StartCom & Qihoo Incidents

[谭晓生]

Things went interesting, the webpage is about the 19 honored internet security 
researcher by China government, some of them are professors of university, like 
Professor Xiaoyun Wang who contributed a lot on cryptology(MD5 &SHA-1), Min 
Yang, Haixin Duan, Jianwei Liu, Xingshu Chen……, and the fellow of China Academy 
of Engineering, Mr.Changxiang Shen, there is also officers of the 
Administration of public security, are they treated as “Bad Guys” in this 
community? 

Mr.Wenbin Zheng, the GM of Core Security BU of Qihoo 360, is one of the 19 
honored peoples there, he is the top experienced engineer on Microsoft Windows 
Driver development, focus on DEFENDING the virus/Trojan attack for Microsoft 
Windows, the XP Shield made by his team provide additional protect to XP users, 
effectively.

Maybe we should consider technology, product/service and politics separately, 
somebody may not be funs of some government, but if we mixed the technology, 
product/service and politics together, it might make the world even worse.

Thanks，
Xiaosheng Tan


在 2016/10/13 下午12:42，“dev-security-policy 代表 
yliva...@gmail.com” 写入:

Would this be enough? 
http://www.cac.gov.cn/2016-09/19/c_1119583763.htm

On Thursday, October 13, 2016 at 10:58:34 AM UTC+8, 谭晓生 wrote:
> Yuwei, 
> I don’t know who you are, but I can tell you and the community, Qihoo 360 
never been involved in * Fire Wall project, if you did some investigation 
to the message that accused Qihoo 360 joined the project “Search Engine Content 
Security Management System”, you should know the project had been done on Feb 
2005, before Qihoo 360 was founded on Aug 2005, and the project is neither part 
of the * fire wall project nor a project done by Qihoo 360, actually it is 
part of the efforts to help Yahoo’s search engine could work in China, I was 
the tech head of Yahoo!China ‘s tech team, director of engineering and soon the 
CTO of Yahoo!China, I know what happened at that time.
>  
> Thanks，
> Xiaosheng Tan
> 
> 
> 
> 在 2016/10/13 上午5:22，“dev-security-policy 代表 Han 
Yuwei” 写入:
> 
> 在 2016年10月13日星期四 UTC+8上午3:12:08，Ryan Sleevi写道：
> > As Gerv suggested this was the official call for incidents with 
respect to StartCom, it seems appropriate to start a new thread.
> > 
> > It would seem that, in evaluating the relationship with WoSign and 
Qihoo, we naturally reach three possible conclusions:
> > 1) StartCom is treated as an independent entity
> > 2) StartCom is treated as a subsidiary of Qihoo
> > 3) StartCom is treated as a subsidiary of WoSign
> > 
> > We know there are serious incidents with WoSign that, collectively, 
encourage the community to distrust future certificates. However, there hasn't 
been a similar investigation into the trustworthiness of StartCom as an 
independent entity or as an entity operated by Qihoo. It would seem that 
germane to the discussion is how trustworthy the claims are - from either 
StartCom or Qihoo - and how that affects trust.
> > 
> > Incidents with StartCom:
> > A) Duplicate Serials. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
> > We know that StartCom had issues issuing duplicate serials, in 
violation of RFC 5280. We know that they did not prioritize resolution, and 
when attempting resolution, did so incompletely, as the issue still resurfaced.
> > 
> > C) Improper OCSP responder. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
> > We know that StartCom continues to have issue with their OCSP 
responder after they issue certificates. Presumably, this is a CDN distribution 
delay, but we can't be sure, especially considering Incident A was with the 
underlying systems. As a consequence of this, users with StartCom certificates 
are disproportionately disadvantaged from enabling OCSP stapling, which many 
browser programs support (and is perhaps the only viable path towards a 
complete revocation solution).
> > 
> > E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 
/ https://bugzilla.mozilla.org/show_bug.cgi?id=994478
> > We know StartCom had a notoriously poor response to HeartBleed. 
Eddy first dismissed the significance, and then when proven wrong, still 
continued to charge $25 USD for revocation. Ostensibly, this is a violation of 
the Baseline Requirements, in that CAs are required to revoke certificates 
suspected of Key Compromise. However, despite the BRs effective date of 2012, 
Mozilla was not aggressively imposing compliance then (... or now, to be fair).
> > 
> > G) StartCom BR violations - IV 
https://bugzilla.mozi

Re: StartCom & Qihoo Incidents

[谭晓生]

Yuwei, 
I don’t know who you are, but I can tell you and the community, Qihoo 360 never 
been involved in * Fire Wall project, if you did some investigation to the 
message that accused Qihoo 360 joined the project “Search Engine Content 
Security Management System”, you should know the project had been done on Feb 
2005, before Qihoo 360 was founded on Aug 2005, and the project is neither part 
of the * fire wall project nor a project done by Qihoo 360, actually it is 
part of the efforts to help Yahoo’s search engine could work in China, I was 
the tech head of Yahoo!China ‘s tech team, director of engineering and soon the 
CTO of Yahoo!China, I know what happened at that time.
 
Thanks，
Xiaosheng Tan



在 2016/10/13 上午5:22，“dev-security-policy 代表 Han 
Yuwei” 写入:

在 2016年10月13日星期四 UTC+8上午3:12:08，Ryan Sleevi写道：
> As Gerv suggested this was the official call for incidents with respect 
to StartCom, it seems appropriate to start a new thread.
> 
> It would seem that, in evaluating the relationship with WoSign and Qihoo, 
we naturally reach three possible conclusions:
> 1) StartCom is treated as an independent entity
> 2) StartCom is treated as a subsidiary of Qihoo
> 3) StartCom is treated as a subsidiary of WoSign
> 
> We know there are serious incidents with WoSign that, collectively, 
encourage the community to distrust future certificates. However, there hasn't 
been a similar investigation into the trustworthiness of StartCom as an 
independent entity or as an entity operated by Qihoo. It would seem that 
germane to the discussion is how trustworthy the claims are - from either 
StartCom or Qihoo - and how that affects trust.
> 
> Incidents with StartCom:
> A) Duplicate Serials. https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
> We know that StartCom had issues issuing duplicate serials, in violation 
of RFC 5280. We know that they did not prioritize resolution, and when 
attempting resolution, did so incompletely, as the issue still resurfaced.
> 
> C) Improper OCSP responder. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
> We know that StartCom continues to have issue with their OCSP responder 
after they issue certificates. Presumably, this is a CDN distribution delay, 
but we can't be sure, especially considering Incident A was with the underlying 
systems. As a consequence of this, users with StartCom certificates are 
disproportionately disadvantaged from enabling OCSP stapling, which many 
browser programs support (and is perhaps the only viable path towards a 
complete revocation solution).
> 
> E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 / 
https://bugzilla.mozilla.org/show_bug.cgi?id=994478
> We know StartCom had a notoriously poor response to HeartBleed. Eddy 
first dismissed the significance, and then when proven wrong, still continued 
to charge $25 USD for revocation. Ostensibly, this is a violation of the 
Baseline Requirements, in that CAs are required to revoke certificates 
suspected of Key Compromise. However, despite the BRs effective date of 2012, 
Mozilla was not aggressively imposing compliance then (... or now, to be fair).
> 
> G) StartCom BR violations - IV 
https://bugzilla.mozilla.org/show_bug.cgi?id=1266942
> StartCom was materially violating its CP/CPS and the Baseline 
Requirements with respect to certain types of validation. No explanation for 
the root cause provided.
> 
> I) StartCom BR violations (2) - Key Sizes 
https://bugzilla.mozilla.org/show_bug.cgi?id=1015767
> StartCom was issuing certificates less than 2048 bits.
> 
> K) StartCom impersonating mozilla.com. 
https://bugzilla.mozilla.org/show_bug.cgi?id=471702
> StartCom's (former) CEO Eddy Nigg obtained a key and certificate for 
www.mozilla.com and placed it on an Internet-facing server.
> 
> M) StartCom BR violations (3) - Key exponents 
https://bugzilla.mozilla.org/show_bug.cgi?id=1212655
> StartCom was not enforcing the BRs with respect to RSA public exponents.
> 
> O) StartCom BR violations (4) - Curve violations 
https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269183
> StartCom was not enforcing the BRs with respect to EC curve algorithms.
> 
> 
> 
> In addition to discussion of StartCom issues, it seems relevant to future 
trust to evaluate issues with Qihoo. Many in the Mozilla community may not have 
direct interactions with Qihoo, but they have obtained some notoriety in 
security circles.
> 
> Q.A) Qihoo masking their browser as a critical Windows security update to 
IE users.
> http://wmos.info/archives/7717 / 
http://www.theregister.co.uk/2013/02/01/qihoo_government_warning_fraud/
> Qihoo displayed a misleading security update for Windows users that 
instead installed their browser.
> 
> Q.C) Qihoo browser actively enable

Re: WoSign: updated report and discussion

[谭晓生]

The HSM is stored offline, in the Vault of Qihoo 360’s head quarter, a little 
bit surprised by this question, I don’t know if there other CAs put their Root 
Certificates online?
If anybody have evident to say “Wosign have the private key of StartCom”, 
please show us here.

Thanks，
Xiaosheng Tan


在 2016/10/13 上午6:49，“dev-security-policy 代表 
Percy” 写入:

On Monday, October 10, 2016 at 2:16:53 PM UTC-7, Matt Palmer wrote:
> On Mon, Oct 10, 2016 at 10:33:15AM -0700, Nick Lamb wrote:
> > Would anybody here _seriously_ be shocked to read next month that a 
black
> > hat group is auctioning some StartCom private keys ?  On the evidence
> > available we have to assume that the keys underpinning both WoSign and
> > StartCom may turn out to be compromised,
> 
> Say what-now?  I don't recall anything that suggested private key
> *compromise*.  The need to roll the keys, from what I can see, is because
> the existing chains have done "things" that are shady, and we can never be
> sure there isn't more shady things lurking in the shadows.  Hence, we
> distrust the keys entirely to prevent any of the old shady from leaping 
out
> in a year's time and laying waste to the landscape once again.
> 
> - Matt

" PKI – signing service 
>Code: Same code with WoSign’s one. 
>Server: Shared Server. 
>Location: The primary one is hosted in Qihoo 360 head quarter’s data 
center in Beijing since Dec 2015, there is a backup server in Wosign’s office 
in Shenzhen. 
>Business Process: Same 
"
As Jakob said, WoSign might have StartCom's private key. Xiaosheng Tan, 
perhaps you can clarify what the backup server process and whether HSM is 
"backed up" as well. 



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
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

Re: WoSign: updated report and discussion

[谭晓生]

Process to apply a SSL certificate of StartCom:
Step 1. StartCom customer sign-in his/her account on official website of 
StartCom;
Step 2. Customer do the domain validation via “Validations Wizard”;
Step 3. PKI validation system send the verification code to domain name whois 
admin email, the subscriber pastes the verification to the validation page;
Step 4. If the domain validated successfully, subscriber using “Certificates 
Wizard” to choose the validated domain and post CSR to CMS for pending process;
Step 5. If the domain name is not in the “Manual Review list” and subscriber 
apply for a free SSL certificate, the order will be sent to the PKI server to 
issue the Certificate automatically, go to Step 8;
Step 6. If the domain name is in the “Manual Review List” or subscriber apply 
for OV and EV certificate, the order will be sent to CMS for manual process;
Step 7. CMS (Certificate Management System) is the internal order process 
system to review the order, do the identify validation, approve the order to 
PKI for pending issuance;
Step 8. The PKI signing server will get the serial number from serial number 
generator;
Step 9: PKI use the right intermediate CA key to sign the certificate, and 
return the issued certificate to CMS;
Step 10. CMS push the certificate to ordering system, and send email to user to 
retrieve the certificate from the official website.

The Official website & Ordering System, CMS and PKI system are involved in the 
process, the process is different with Wosign’s one.
 
CRL/OCSP distribution
1.  Once the certificate is issued, the certificate serial number and other 
related info will post to OCSP source server for CDN distribution;
2.  PKI signing the CRL at fixed period and send it to CRL source server 
for CDN distribution.

Thanks，
Xiaosheng Tan



在 2016/10/11 上午12:10，“Gervase Markham” 写入:

On 10/10/16 16:47, 谭晓生 wrote:
> Yes, the certificate issuance process is performed by each of these
> five components, except, TSA is used for code issuance and PDF
> issuance, not related with SSL certificates issuance.

Right :-) But can you explain what each component does specifically? E.g.:

1) The user visits the website (component 1) and uploads a CSR.
2) ...
3) ...

Then it would be clear what particular steps are currently fulfilled by
code from StartCom, what by code from WoSign, and so on.

Gerv



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign: updated report and discussion

[谭晓生]

Dear Gervase,

Yes, the certificate issuance process is performed by each of these five 
components, except, TSA is used for code issuance and PDF issuance, not related 
with SSL certificates issuance.

Thanks，
Xiaosheng Tan



在 2016/10/10 下午7:11，“Gervase Markham” 写入:

Hi Xiaosheng.

On 09/10/16 14:54, 谭晓生 wrote:
> There are 5 components of StartCom’s business supporting software:

It might be useful if you were to explain what function in the
certificate issuance process is performed by each of these five components.

> 3. PKI – signing service
>Code: Same code with WoSign’s one.
>Server: Shared Server.
>Location: The primary one is hosted in Qihoo 360 head quarter’s data 
center in Beijing since Dec 2015, there is a backup server in Wosign’s office 
in Shenzhen.
>Business Process: Same

Presumably the fact that this code is shared with WoSign explains why
the StartCom serial numbers changed to be "WoSign-style" in December 2015.

> 5.TSA
>Code: Same code with Wosign’s one.
>Server: Dedicate server, no sharing.
>Location: StartCom TSA: http://tsa.startssl.com is located in Qihoo 
360 Los Angeles IDC, WoSign TSA: http://timestamp.wosign.com is hosted in Qihoo 
360 China IDC.
>Business Process: Same

Is this server involved in SSL certificate issuance at all?

Gerv



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign: updated report and discussion

[谭晓生]

I also said that the official website, ordering system, certificate management 
system are different and independent, which is the major cause of the bugs from 
technical perspective, that’s why Wosign suffered the incidents of bugs but 
StartCom haven’t.
The validation team, customer care team and tech support team are also 
independent, that is important for the quality control for the business, that’s 
also the important reason that StartCom did well except the 2 backdated 
certificates that instructed by Richard Wang directly.
StartCom as a CA for 17 years, contributed more or less to the industry and 
community, we do hired an in-proper person to manage the company and it have 
been fixed, fortunately, the ordering process, CMS process still keep the same 
with the original one of StartCom, we are changing the software soon, the time 
table will be released in this week.
Please give a chance to StartCom.

Thanks，
Xiaosheng Tan



在 2016/10/10 上午6:43，“dev-security-policy 代表 
Percy” 写入:

Tan said,  for StartCom and WoSign’s infrastructure, the PKI servers 
were/are shared, the CRL/OCSP, TSA code were cloned and the StartCom and WoSign 
shared the software development team. 

Also some management team are shared I assume since Richard Wang approved 
Tyro's backdated cert from StartCom.

As we saw most problems discovered are either due to software 
development(issue F,H,L,N,V) or management (issue S,P,R). And those team were 
shared between WoSign and StartCom at the time of the incidents. Consequently, 
at the time of the incidents, they're the same entity with regards to those 
issues. So I agree with the opinion that " If their 
operations are, in the future, functionally separated, then they can be 
considered for reinclusion separately.  However, for the purposes of what 
to 
do about them over *past* actions, when they were a single operational 
entity, their actions should be considered as such. "
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
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

Re: WoSign: updated report and discussion

[谭晓生]

Dear All,
This is the information that would be released by Inigo in the coming week, 
Percy asked me to answer the question, so, it is here:
 
Business Supporting Software:
There are 5 components of StartCom’s business supporting software:
1. Official Website + Ordering system
Code: Independent code, totally different with WoSign’s one.
Server: Dedicate server, no sharing.
Location: Hosted in Qihoo 360 Los Angeles, U.S China Telecom America IDC, 
WoSign’s one is hosted in China.
Business Process/Logic: Different with WoSign’s business process/logic, keeping 
the same business process/logic with the old system before the acquisition.
UI of Web: Different with WoSign’s, Revised version of StartCom’s original 
version. Developed by WoSign RD team.
 
2. CMS (Certificate Management System)
Code: Independent code, totally different with WoSign’s one.
Server: Dedicate server, no sharing.
Location: The primary server is hosted in Qihoo 360 head quarter’s data center 
in Beijing, there is a backup server in WoSign’s office in Shenzhen.
Business Process/Logic: Different with WoSign’s business process/logic, keeping 
the same business process/logic with the old system before the acquisition.
 
3. PKI – signing service
   Code: Same code with WoSign’s one.
   Server: Shared Server.
   Location: The primary one is hosted in Qihoo 360 head quarter’s data center 
in Beijing since Dec 2015, there is a backup server in Wosign’s office in 
Shenzhen.
   Business Process: Same
 
4. CRL/OCSP
   Code: Same code with WoSign’s one.
   Server: Dedicate server, no sharing.
   Location:  StartCom and WoSign CRL/OCSP source server is located in Qihoo 
360 USA IDC, the backup source server is hosted in Qihoo 360 head quarter’s 
data center in Beijing.
   Cache Service: by Akamai for oversea visitors, Qihoo 360 CDN for China 
visitors
   Business Process: Same
 
5.TSA
   Code: Same code with Wosign’s one.
   Server: Dedicate server, no sharing.
   Location: StartCom TSA: http://tsa.startssl.com is located in Qihoo 360 Los 
Angeles IDC, WoSign TSA: http://timestamp.wosign.com is hosted in Qihoo 360 
China IDC.
   Business Process: Same
 
So, For StartCom and WoSign’s infrastructure, only the PKI servers were/are 
shared, the CRL/OCSP, TSA code were cloned but hosted in different IDC, nothing 
were/are shared on Official Website, Ordering System and CMS.
 
Data Center:
For Qihoo 360 Los Angeles IDC, it is a co-location with China Telecom North 
America company, located at 600 W 7TH ST Suite 570, LOS ANGELES CA 90017, 
governed by U.S Law.
 
Employee:
For employees, the StartCom and WoSign shared the software development team 
which paid by WoSign, but with independent validation team, customer care team 
and tech support team which were/are paid by StartCom China, StartCom U.K and 
StartCom IL, StartCom’s teams were/are English speaking employees, WoSign’s 
were/are Chinese speaking employees.

More information will be available in the SC report which will be released by 
Inigo soon.

Thanks，
Xiaosheng Tan, Chief Security Officer of Qihoo 360



在 2016/10/9 上午7:02，“dev-security-policy 代表 
Percy” 写入:

His writing style is very similar to StartCom's website which is produced 
in China. As we're examining the infrastructure of the two companies, could 
Mozilla ask Qihoo 360 to disclose the current personnel and technical 
infrastructure shared between WoSign and StartCom. 
WoSign has denied that they shared those infrastructures but we know WoSign 
lied. So I want to ask Qihoo 360 the same question and see whether Qihoo has a 
different answer.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
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

Re: WoSign and StartCom: next steps

[谭晓生]

So far 360 is just an investor of Wosign, but we think we need to do something 
because of what happened.
I’d like to have suggestions from Gev to see if Richard Wang to join the 
meeting is a better proposal.

Thanks，
Xiaosheng Tan


在 16/9/30 上午10:03，“dev-security-policy 代表 Peter 
Kurrasch” 写入:

So if WoSign will not be present to discuss possible sanctions against 
WoSign, what are we to infer from that? Is Qihoo 360 acting in a capacity that 
is more than just an investor in WoSign? 

I'm trying not to get too far ahead of things, but this seems to be a very 
curious turn of events.


  Original Message  
From: Gervase Markham
Sent: Thursday, September 29, 2016 10:41 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: WoSign and StartCom: next steps

Hi everyone,

Following the publication of the recent investigative report,
representatives of Qihoo 360 and StartCom have requested a face-to-face
meeting with Mozilla. We have accepted, and that meeting will take place
next Tuesday in London.

After that, we expect to see a public response and proposal for
remediation from them, which will be discussed here before Mozilla makes
a final decision on the action we will take.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[谭晓生]

Dear Peter,
In terms of investments, the answer is that we do not have on going 
negotiations on investments/acquisitions with any CAs.
In terms of partnership, as a security company, we are open to work with CAs, 
we can share some threat intelligence with CAs, for example, the stolen/abused 
digital certificates, and, as there are state standards for digital 
certificates of China, 360‘s browser could support the SM2/SM4 algorithm, we 
can work with CAs to issue the digital certificates that follow the China’s 
local standards/regulations.
 
Thanks,
Xiaosheng

在 16/9/21 上午1:00，“Peter Bowen” 写入:

On Tue, Sep 20, 2016 at 8:41 AM, 谭晓生  wrote:
> 2) Does Qihoo 360, a Qihoo 360 subsidiary, a Qihoo 360 VIE, or a Qihoo
> 360 VIE subsidiary, or a combination of those own or control a
> majority of shares in WoSign?
> [Xiaosheng]: Yes, the combination of those own 84% of shares in Wosign.

To avoid anything coming up later, do any combination of these have
interest in any other CAs?



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[谭晓生]

Yes, you are correct, we also invested in Opera, but just a smaller share 
holders, not a majority one.

Thanks，
Xiaosheng Tan
Sent from 360 Q5 Mobile Phone

发件人： Kurt Roeckx 
发送时间： 2016年9月20日 23:45
收件人： mozilla-dev-security-pol...@lists.mozilla.org
主题： Re: Incidents involving the CA WoSign

On 2016-09-20 17:31, 谭晓生 wrote:
> Dear Gerv and all,
>
> Qihoo 360 is a company valued at USD$9.99B as it finished the privatization 
> on July 15th 2016, we have invested in more than 200 companies across the 
> world, Wosign is just a very small one and we even do not have any people 
> sent to this company after the investment, the major businesses of Qihoo 360 
> are security software for consumer, we are the largest player of anti-virus 
> software in China, No.2 search engine in China and one of the top gaming 
> platform in China, No.1 PC browser in China, the total revenue is about 
> USD$1.6B last year, that’s might help to understand that why the layers don’t 
> think Wosign is a "significant subsidiary".

I don't know much about the CAB rules, but from what I understand of
that is that Qihoo 360 has both a browser and a CA.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
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

Re: Incidents involving the CA WoSign

[谭晓生]

While you are here, I hope you can answer a couple of questions.

1) Are the first three shareholders listed in the attached file the
same companies as the "Qihoo 360 Software (Beijing) Co., Ltd.",
"Beijing Qifutong
Technology Co., Ltd.", and "Beijing Yuan Tu Technology Co., Ltd."
entities listed in Qihoo 360 SEC reports as VIEs or subsidiaries of
VIEs?
[Xiaosheng]: Yes, they are.

2) Does Qihoo 360, a Qihoo 360 subsidiary, a Qihoo 360 VIE, or a Qihoo
360 VIE subsidiary, or a combination of those own or control a
majority of shares in WoSign?
[Xiaosheng]: Yes, the combination of those own 84% of shares in Wosign.

Thanks,
Peter


>
> Thanks,
> Xiaosheng
>
> Xiaosheng Tan, Chief Security Officer
> Qihoo 360
> E-Mail: tanxiaosh...@360.cn
> Web: www.360.cn 
> Address: Bldg 2, 6 Haoyuan, Jiuxianqiao Rd, Chaoyang Dist, Beijing, China 
100015
>
>
> 在 16/9/20 下午2:05，“dev-security-policy 代表 
Percy” 写入:
>
> On Monday, September 19, 2016, Richard Wang  
wrote:
>
> > Thanks for your pointing out one of the very important evidence for 
the
> > transaction is NOT completed till yesterday that we released the 
news after
> > it is finished at the first phase. We just finished the UK company
> > investment.
> >
> > For Qihoo 360, I don't know anything and I don’t have the right to 
do any
> > comment. Sorry.
>
> Considering that StartCom is hosted by Qihoo 360
> 
https://pierrekim.github.io/blog/2016-02-16-why-i-stopped-using-startssl-because-of-qihoo-360.html
> and
> that you're the sole director of StartCom, it's hard for me to 
believe that
> you "don't know anything" about Qihoo 360.
>
> >
> > Best Regards,
> >
> > Richard
> >
> > -Original Message-
> > From: Peter Bowen [mailto:pzbo...@gmail.com ]
> > Sent: Tuesday, September 20, 2016 10:18 AM
> > To: Richard Wang >
> > Cc: Nick Lamb >;
> > mozilla-dev-security-pol...@lists.mozilla.org 
> > Subject: Re: Incidents involving the CA WoSign
> >
> > Richard,
> >
> > As someone pointed out on Twitter this morning, it seems that the 
PSC
> > notification for Startcom UK was filed recently:
> > https://s3-eu-west-1.amazonaws.com/document-api-images-prod/docs/
> > UdxHYAlFj6U9DNs6VBJdnIDv4IQAWd4YKYomMERO_2o/application-pdf
> >  Were you unaware of this filing?
> >
> > Additionally, companies that register to trade on the New York Stock
> > Exchange have to file reports with the US Security and Exchange
> > Commission.  Qihoo 360 filed a report that included a list of their
> > variable interest entities and Qihoo's percent of economic interest 
in each
> > (https://www.sec.gov/Archives/edgar/data/1508913/
> > 000114420413022823/v341745_20f.htm
> > page F-10).  It also describes all the ways in which Qihoo 360 
controls
> > these entities, including assuring that Qihoo has decision making 
authority
> > over the entities.
> >
> > I agree that Mozilla does not require reporting that multiple Root 
CAs are
> > Affiliates.  Perhaps it should.  However, as you know, the 
CA/Browser Forum
> > does require such.  So I don't think it would be a stretch for 
Mozilla to
> > do so.  It is something that should probably be added to the 2.3 
policy
> > discussion.
> >
> > Thanks,
> > Peter
> >
> >
> > On Mon, Sep 19, 2016 at 6:51 PM, Richard Wang  > > wrote:
> > > Thanks for your detail info.
> > > No worry about this, all companies must be complied with local 
law.
> > >
> > > But I really don't care who is my company's shareholder's 
shareholder's
> > shareholder, you need to find out this by yourself if you care.
> > >
> > > If you think Mozilla must require this, please add to the Mozilla 
policy
> > that require all CA disclose its nine generation including all 
subordinate
> > companies and all parent companies.
> > >
> > >
> > > Best Regards,
> > >
> > > Richard
> > >
> > > -Original Message-
> > > From: dev-security-policy
> > > [mailto:dev-security-policy-bounces+richard 
> > =wosign.com@lists.mozilla.o
> > > rg] On Behalf Of Nick Lamb
> > > Sent: Tuesday, September 20, 2016 9:06 AM
> > > To: mozilla-dev-security-pol...@lists.mozilla.org 
> > > Subject: Re: Incidents involving the CA WoSign
> > >
> > > On Tuesday, 20 September 2016 01:25:59 UTC+1, Richard Wang  wrote:
> > >>

Re: Incidents involving the CA WoSign

[谭晓生]

Dear Gerv and all,

Qihoo 360 is a company valued at USD$9.99B as it finished the privatization on 
July 15th 2016, we have invested in more than 200 companies across the world, 
Wosign is just a very small one and we even do not have any people sent to this 
company after the investment, the major businesses of Qihoo 360 are security 
software for consumer, we are the largest player of anti-virus software in 
China, No.2 search engine in China and one of the top gaming platform in China, 
No.1 PC browser in China, the total revenue is about USD$1.6B last year, that’s 
might help to understand that why the layers don’t think Wosign is a 
"significant subsidiary".
 
Thanks,
Xiaosheng
 
Xiaosheng Tan, Chief Security Officer
Qihoo 360
E-Mail: tanxiaosh...@360.cn
Web: www.360.cn <http://www.360.cn/>
Address: Bldg 2, 6 Haoyuan, Jiuxianqiao Rd, Chaoyang Dist, Beijing, China 100015
 

在 16/9/20 下午5:30，“Gervase Markham” 写入:

Hello Xiaosheng,

Welcome to our discussion forum :-) It may help you to know that
participants in this forum come from a wide range of backgrounds and
companies, and the only ones who represent Mozilla are the ones listed here:
http://wiki.mozilla.org/CA:Policy_Participants
as doing so.

On 20/09/16 08:23, 谭晓生 wrote:
> I’m Xiaosheng Tan, the Chief Security Officer of Qihoo 360, on the
> inquiry of the disclosure of Wosign deal, we are not obligated to
> disclose it under the SEC regulation, here is the reply from our
> internal lawyers:

To be totally clear: Mozilla is not suggesting that StartCom, WoSign or
Qihoo 360 have done anything illegal. The questions we are asking about
disclosure relate to Mozilla's policies on the topic (and perhaps to the
CAB Forum voting rules), not to the SEC rules.

Having said that, if the company structure is as we understand it to be,
I am very surprised that your lawyers do not think that WoSign is a
"significant subsidiary" of Qihoo 360 under SEC rules. But that is a
matter for you and the SEC, not for us :-)

Gerv


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[谭晓生]

Dear All,

I’m Xiaosheng Tan, the Chief Security Officer of Qihoo 360, on the inquiry of 
the disclosure of Wosign deal, we are not obligated to disclose it under the 
SEC regulation, here is the reply from our internal lawyers:

“While we were a public company listed on NYSE, we did not disclose WoSign as 
our subsidiaries as our reporting obligation only requires us to disclose our 
“significant subsidiaries” in SEC filings. The definition of “significant 
subsidiaries” is enclosed below. Since WoSign is not our significant subsidiary 
according to this definition, we are not legally required to disclose it in our 
SEC filings. In general, our reporting obligations follow a “materiality” 
standard under the United States Securities Exchange Act of 1934 and the NYSE 
Listed Company Manuel.
 
Regulation S-X § 210.1-02
 
Significant subsidiary. The term significant subsidiary means a subsidiary, 
including its subsidiaries, which meets any of the following conditions:
 
(1) The registrant's and its other subsidiaries' investments in and advances to 
the subsidiary exceed 10 percent of the total assets of the registrant and its 
subsidiaries consolidated as of the end of the most recently completed fiscal 
year (for a proposed combination between entities under common control, this 
condition is also met when the number of common shares exchanged or to be 
exchanged by the registrant exceeds 10 percent of its total common shares 
outstanding at the date the combination is initiated); or
 
(2) The registrant's and its other subsidiaries' proportionate share of the 
total assets (after intercompany eliminations) of the subsidiary exceeds 10 
percent of the total assets of the registrants and its subsidiaries 
consolidated as of the end of the most recently completed fiscal year; or
 
(3) The registrant's and its other subsidiaries' equity in the income from 
continuing operations before income taxes, extraordinary items and cumulative 
effect of a change in accounting principle of the subsidiary exclusive of 
amounts attributable to any noncontrolling interests exceeds 10 percent of such 
income of the registrant and its subsidiaries consolidated for the most 
recently completed fiscal year.
“
Even Richard is the CEO of Wosign, he is not authorized to do any comments to 
Qihoo 360 legally, thanks for the understanding.

Thanks,
Xiaosheng
 
Xiaosheng Tan, Chief Security Officer
Qihoo 360
E-Mail: tanxiaosh...@360.cn
Web: www.360.cn 
Address: Bldg 2, 6 Haoyuan, Jiuxianqiao Rd, Chaoyang Dist, Beijing, China 100015
 

在 16/9/20 下午2:05，“dev-security-policy 代表 
Percy” 写入:

On Monday, September 19, 2016, Richard Wang  wrote:

> Thanks for your pointing out one of the very important evidence for the
> transaction is NOT completed till yesterday that we released the news 
after
> it is finished at the first phase. We just finished the UK company
> investment.
>
> For Qihoo 360, I don't know anything and I don’t have the right to do any
> comment. Sorry.

Considering that StartCom is hosted by Qihoo 360

https://pierrekim.github.io/blog/2016-02-16-why-i-stopped-using-startssl-because-of-qihoo-360.html
and
that you're the sole director of StartCom, it's hard for me to believe that
you "don't know anything" about Qihoo 360.

>
> Best Regards,
>
> Richard
>
> -Original Message-
> From: Peter Bowen [mailto:pzbo...@gmail.com ]
> Sent: Tuesday, September 20, 2016 10:18 AM
> To: Richard Wang >
> Cc: Nick Lamb >;
> mozilla-dev-security-pol...@lists.mozilla.org 
> Subject: Re: Incidents involving the CA WoSign
>
> Richard,
>
> As someone pointed out on Twitter this morning, it seems that the PSC
> notification for Startcom UK was filed recently:
> https://s3-eu-west-1.amazonaws.com/document-api-images-prod/docs/
> UdxHYAlFj6U9DNs6VBJdnIDv4IQAWd4YKYomMERO_2o/application-pdf
>  Were you unaware of this filing?
>
> Additionally, companies that register to trade on the New York Stock
> Exchange have to file reports with the US Security and Exchange
> Commission.  Qihoo 360 filed a report that included a list of their
> variable interest entities and Qihoo's percent of economic interest in 
each
> (https://www.sec.gov/Archives/edgar/data/1508913/
> 000114420413022823/v341745_20f.htm
> page F-10).  It also describes all the ways in which Qihoo 360 controls
> these entities, including assuring that Qihoo has decision making 
authority
> over the entities.
>
> I agree that Mozilla does not require reporting that multiple Root CAs are
> Affiliates.  Perhaps it should.  However, as you know, the CA/Browser 
Forum
> does require such.  So I don't think it would be a stretch for Mozilla to
> do so.  It is something that should probably be added to the 2.3 policy
> discussion.
>
> Thanks,
> Peter