Re: Google Trust Services Root Inclusion Request

[Richard Wang via dev-security-policy]

It is unfair that somebody attacked me in the WoSign sanction discussion, but 
no body say any word for this! Why? Due to Ryan is famous person and I am 
nobody?


Best Regards,

Richard Wang

On Sep 27, 2018, at 18:24, James Burton mailto:j...@0.me.uk>> 
wrote:

Richard,

Your conduct is totally unacceptable and won’t be tolerated. You must read the 
forum rules regarding etiquette.

Also I suggest you apologise to Ryan.

James



On Thu, 27 Sep 2018 at 10:33, Rob Stradling via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Richard,

You might like to familiarize yourself with the Mozilla Forum Etiquette
Ground Rules:
https://www.mozilla.org/en-US/about/forums/etiquette/

Note this in particular:
"Be civil.
No personal attacks. Do not feel compelled to defend your honor in
public. Posts containing personal attacks may be removed from the news
server."

On 27/09/2018 07:59, Richard Wang via dev-security-policy wrote:
> Sorry, I don't agree with this point. Ryan Sleevi is the Mozilla Module Peer 
> that gave too many pressures to the M.D.S.P community to misleading the 
> Community and to let Mozilla make the decision that Google want.
>
> There are two facts to support my opinion:
>
> (1) For StartCom sanction, Mozilla agreed in Oct 2nd 2016 London meeting that 
> if we separate StartCom completely from WoSign, then Mozilla don't sanction 
> StartCom that still trust StartCom root. But Google as peer of Mozilla Module 
> don't agree this, and Ryan even found many very very old problems of StartCom 
> to be a "fact" that must be distrusted. Google changed the Mozilla decision!
>
> (2) For Symantec sanction, everyone can see the argues in M.D.S.P discussion 
> from Ryan Sleevi that Google changed the Mozilla initial decision, this also 
> is the fact.
>
> So, we can see Ryan not just a Mozilla Module Peer, he represents Google 
> browser that affect Mozilla to make the right decision.
>
> Ryan, don't feel too good about yourself. Peoples patiently look at your long 
> emails at M.D.S.P and listen to your bala bala speaking at the CABF meeting, 
> this is because you represent Google Chrome, and Google Chrome seriously 
> affects Mozilla that have the power to kill any CAs. If you leave Google, you 
> will be nothing, no one will care about your existence, and no one will care 
> what you say. So, please don't declare that you don't represent Google before 
> you speak next time, nonsense!
>
> Your myopic has brought global Internet security to the ditch. Chrome display 
> "Secure" for a website just it has SSL(https). Many fake banking websites and 
> fake PayPal websites have Lets Encrypt certificates, and Google Chrome say it 
> is "Secure", this completely misleads global Internet users, resulting in 
> many users are deceived and lost property. Encryption is not equal to secure. 
> Secure means not only encryption, but also need to tell user the website's 
> true identity. Does a fake bank website encryption mean anything? nothing and 
> more worse.
>
> Ryan, 别自我感觉太好，别人耐心看你在M.D.S.P的长篇大论和听你在CABF meeting上说过没完 
> ，是因为你代表谷歌浏览器，而谷歌浏览器严重影响Mozilla对所有CA有生杀大权。如果你离开谷歌，你将什么也不是，没有人会理会你的存在，也没有人会在意你说的话。所以下次不要在发言之前就声明不代表谷歌，废话哦！
>
> 你的短视把全球互联网安全带到了沟里，认为有SSL证书(https)就安全，许多假冒银行网站、假冒PayPal 网站都有Lets 
> Encrypt证书，谷歌浏览器显示为安全，完全误导了全球互联网用户，导致许多用户上当受骗和财产损失。已加密并不等于安全，安全不仅意味着需要加密，而且还需要告知用户此网站的真实身份，一个假冒银行网站加密有任何意义吗？没有并且更糟糕。
>
>
> Best Regards,
>
> Richard Wang
>
>  Original Message 
> From: Ryan Sleevi via dev-security-policy
> Received: Thursday, 27 September 2018 00:53
> To: Jeremy Rowley
> Cc: Ryan Sleevi ; mozilla-dev-security-policy
> Subject: Re: Google Trust Services Root Inclusion Request
>
>
> On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley 
> mailto:jeremy.row...@digicert.com>>
> wrote:
>
>> I also should also emphasize that I’m speaking as Jeremy Rowley, not as
>> DigiCert.
>>
>>
>>
>> Note that I didn’t say Google controlled the policy. However, as a module
>> peer, Google does have significant influence over the policy and what CAs
>> are trusted by Mozilla. Although everyone can participate in Mozilla
>> discussions publicly, it’s a fallacy to state that a general participant
>> has similar sway or authority to a module peer. That’s the whole point of
>> having a separate class for peers compared to us general public.  With
>> Google acting as a CA and module peer, you now have one CA heavily
>> influencing who its competitors are, how its competitors operate, and what
>> its competitors can do.  Although I personally find that you never misuse
>> your power as a module peer, I can see how Jake has concerns that Google
>> (as a CA) has ver

RE: Re: Google Trust Services Root Inclusion Request

[Richard Wang via dev-security-policy]

Sorry, I don't agree with this point. Ryan Sleevi is the Mozilla Module Peer 
that gave too many pressures to the M.D.S.P community to misleading the 
Community and to let Mozilla make the decision that Google want.

There are two facts to support my opinion:

(1) For StartCom sanction, Mozilla agreed in Oct 2nd 2016 London meeting that 
if we separate StartCom completely from WoSign, then Mozilla don't sanction 
StartCom that still trust StartCom root. But Google as peer of Mozilla Module 
don't agree this, and Ryan even found many very very old problems of StartCom 
to be a "fact" that must be distrusted. Google changed the Mozilla decision!

(2) For Symantec sanction, everyone can see the argues in M.D.S.P discussion 
from Ryan Sleevi that Google changed the Mozilla initial decision, this also is 
the fact.

So, we can see Ryan not just a Mozilla Module Peer, he represents Google 
browser that affect Mozilla to make the right decision.

Ryan, don't feel too good about yourself. Peoples patiently look at your long 
emails at M.D.S.P and listen to your bala bala speaking at the CABF meeting, 
this is because you represent Google Chrome, and Google Chrome seriously 
affects Mozilla that have the power to kill any CAs. If you leave Google, you 
will be nothing, no one will care about your existence, and no one will care 
what you say. So, please don't declare that you don't represent Google before 
you speak next time, nonsense!

Your myopic has brought global Internet security to the ditch. Chrome display 
"Secure" for a website just it has SSL(https). Many fake banking websites and 
fake PayPal websites have Lets Encrypt certificates, and Google Chrome say it 
is "Secure", this completely misleads global Internet users, resulting in many 
users are deceived and lost property. Encryption is not equal to secure. Secure 
means not only encryption, but also need to tell user the website's true 
identity. Does a fake bank website encryption mean anything? nothing and more 
worse.

Ryan, 别自我感觉太好，别人耐心看你在M.D.S.P的长篇大论和听你在CABF meeting上说过没完 
，是因为你代表谷歌浏览器，而谷歌浏览器严重影响Mozilla对所有CA有生杀大权。如果你离开谷歌，你将什么也不是，没有人会理会你的存在，也没有人会在意你说的话。所以下次不要在发言之前就声明不代表谷歌，废话哦！

你的短视把全球互联网安全带到了沟里，认为有SSL证书(https)就安全，许多假冒银行网站、假冒PayPal 网站都有Lets 
Encrypt证书，谷歌浏览器显示为安全，完全误导了全球互联网用户，导致许多用户上当受骗和财产损失。已加密并不等于安全，安全不仅意味着需要加密，而且还需要告知用户此网站的真实身份，一个假冒银行网站加密有任何意义吗？没有并且更糟糕。


Best Regards,

Richard Wang

 Original Message 
From: Ryan Sleevi via dev-security-policy 
Received: Thursday, 27 September 2018 00:53
To: Jeremy Rowley 
Cc: Ryan Sleevi ; mozilla-dev-security-policy 
Subject: Re: Google Trust Services Root Inclusion Request


On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley 
wrote:

> I also should also emphasize that I’m speaking as Jeremy Rowley, not as
> DigiCert.
>
>
>
> Note that I didn’t say Google controlled the policy. However, as a module
> peer, Google does have significant influence over the policy and what CAs
> are trusted by Mozilla. Although everyone can participate in Mozilla
> discussions publicly, it’s a fallacy to state that a general participant
> has similar sway or authority to a module peer. That’s the whole point of
> having a separate class for peers compared to us general public.  With
> Google acting as a CA and module peer, you now have one CA heavily
> influencing who its competitors are, how its competitors operate, and what
> its competitors can do.  Although I personally find that you never misuse
> your power as a module peer, I can see how Jake has concerns that Google
> (as a CA) has very heavy influence over the platform that has historically
> been the CA watchdog (Mozilla).
>

Jeremy, I think this again deserves calling out, because this is
misrepresenting what module peership does, as well as the CA relationship.

I linked you to the definition of Module Ownership, which highlights and
emphasizes that the module peer is simply a recognized helper. To the
extent there is any influence, it is through the public discussions here.
If your concern is that the title confers some special advantage, that's to
misread what module peer is. If your concern is that the participation -
which provides solid technical arguments as well as the policy alternatives
- is influential, then what you're arguing against is public participation.

You're presenting these as factual, and that's misleading, so I'd like to
highlight what is actually entailed.


> The circumstances are different between the scenarios you describe with
> respect to the other browsers, as is market share.  If Microsoft wants to
> change CAs (and they already use multiple), they can without impacting
> public perception. If Apple wants to use another CA, they can without
> people commenting how odd it is that Apple doesn’t use the Apple CA. With
> Google controlling the CA and the Google browser, all incentive to
> eliminate any misbehaving Goog

RE: Re: Re: Google Trust Services Root Inclusion Request

[Richard Wang via dev-security-policy]

Hi Ryan,

Thanks for your point out the link "https://wiki.mozilla.org/CA:WoSign_Issues'. 
 I think I need to say more words about  "misleading" and "lie".

I like to expose some FACTs to show the public, to let public know who is 
misleading and lie.

For the initiate WoSign issues email in M.D.S.P in Aug 24, 2016 -- Issue 0 
(a.k.a. Issue L: Any Port (Jan - Apr 2015), Mozilla wrote:
"This problem was reported to Google, and thence to WoSign and resolved.
Mozilla only became aware of it recently.”

The FACT is Google Ryan Sleevi sent email to Richard Wang at April 4th 2015 to 
point out the problems (see below original email), NOT WoSign reported to 
Google, this is the first misleading and lie.

The second "lie" is Ryan Sleevi is the Mozilla Module Peer, this mean Mozilla 
know this case, why someone say “Mozilla only became aware of it 
recently."(August 24, 2016)? This is second misleading and lie.
-
 Original Message 
From: Ryan Sleevi 
Received: Saturday, 04 April 2015 09:25
To: Richard Wang
Subject: WoSign Irregularities

Hi Richard, 

It's come to our attention that WoSign may be issuing certificates that are not 
conforming to your CPS and not conforming to the Baseline Requirements.

While we're still investigating the nature and scope, I was hoping you could 
take the opportunity and ensure that the certificates you're issuing are 
consistent with the Baseline Requirements and consistent to your CPS.

Among other things, I've noted irregularities in:
- Subject Information
- Extensions
- Certificate Policies
- Issuer Alternative Name

Could you please examine your certificates and let me know of any 
irregularities that you have detected and what steps have been taken (per 
Section 8.2 of your CPS)

Also, can you please provide your most recent audit? The most recent BR audit 
available was for the period of 1 January 2013 through 31 December 2013, 
completed on 28 March 2014. I see you've already completed Seals 1843 
(Principles & Practices) and 1842 (EV). When do you expect an audit for the 
period of 1 January 2014 through 31 December 2014 to be made available?
-------


Best Regards,

Richard Wang


 Original Message 
From: Ryan Sleevi via dev-security-policy 
Received: Thursday, 27 September 2018 00:44
To: Richard Wang 
Cc: Ryan Sleevi ; mozilla-dev-security-policy ; Jeremy Rowley 
Subject: Re: Re: Google Trust Services Root Inclusion Request


Hi Richard,

A few corrections:

On Wed, Sep 26, 2018 at 11:36 AM Richard Wang via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Ryan mentioned WoSign/StartCom and 360, so I like to say some words.
>
> First, I think your idea is not a proper metaphor because 360 browser
> can't compare to Google browser, Google browser have absolutely strong
> market share to say YES/NO to all CAs, but I am sure not to Google CA.
>

That wasn't the comparison. I was more highlighting how you actively
mislead (lied?) to the community about the relationship between the
entities, by trying to argue as separate entities. While Google Trust
Services is a separate legal entity, which is about ensuring there is a
firewall between these organizations, my concern about bringing it up was
because of how you actively mislead the community.


> Third, your comparison of Apple and Microsoft is also not correct, they
> use its own CA system for their own system use only, not for public, not to
> be a global public CA like Google.
>

I'm afraid this also misunderstands things. Microsoft does issue
certificates for end-users using its services (like Google). To the point
of the discussion, however, it was about the assumption and implication
that you cannot distrust an entity that operates a large web presence and
also a CA, or that browsers would play special favors to the CAs of their
properties, whether in-house or external. Both of these apply to all
browsers - arguably, even Mozilla (which uses certs from DigiCert as well,
either through the Amazon-branded sub-CA that DigiCert operates or directly
through DigiCert)


> Ryan, thank you for still remembering WoSign.
>

I think it will be very hard for the community to ever forget
https://wiki.mozilla.org/CA:WoSign_Issues
___
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: Re: Google Trust Services Root Inclusion Request

[Richard Wang via dev-security-policy]

Ryan mentioned WoSign/StartCom and 360, so I like to say some words.

First, I think your idea is not a proper metaphor because 360 browser can't 
compare to Google browser, Google browser have absolutely strong market share 
to say YES/NO to all CAs, but I am sure not to Google CA.

Second, I think Google to be a global public CA is a wrong decision, this is 
the same situation that one person is the athlete and the judge, how to 
guarantee the fair? This two business have conflict of interest.

Third, your comparison of Apple and Microsoft is also not correct, they use its 
own CA system for their own system use only, not for public, not to be a global 
public CA like Google.

So, I think accepting Google root to Mozilla trust store don't benefit for 
anyone except Google only, not for the Internet security community, not for the 
CA industry and not for end users.   

Ryan, thank you for still remembering WoSign. 

Best Regards,

Richard Wang

 Original message 
From: Ryan Sleevi via dev-security-policy 
Received: 2018-09-26 14:48:28
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org 
Subject: Re: Google Trust Services Root Inclusion Request


(While covered in https://wiki.mozilla.org/CA/Policy_Participants , I'm
going to emphasize that this response is in a personal capacity)

On Wed, Sep 26, 2018 at 12:10 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Jake's concern is legit if you believe certain assumptions. Criticizing his
> rationale doesn't seem correct, especially since Google does indeed have a
> root store. Although not traditional, Google runs a store of blacklisted
> CAs
> (see Symantec), which is every bit as effective as controlling CA
> compliance
> and operation as the inclusion process.
>

To be clear: Google does indeed operate root stores on a host of devices,
including Android and ChromeOS, not to mention Google Cloud functionality.


> FACT: As a browser, Google already interprets the CA/Browser requirements
> in
> many ways via, intentionally or not.  The Google's policies, and how Google
> implements Chrome are all closely watched by CAs and help dictate how we
> interpret the various requirements.
>


> This fact combined with the assumption that Google will never distrust
> itself jumps to a conclusion that Google will only interpreting the BRs in
> Google CA's best interests. Why wouldn't they? Google is a for profit
> company. Self-promotion is kind-of in the description.
>

The problem with this assumption, or at least what logically follows, is
that every Browser would behave the same, beneficient towards the CA(s)
they use for services. For example, Microsoft operates a root program, yet
is also trusted by Mozilla through the subordinate CAs provided through the
Baltimore Cybertrust hierarchy, which is owned by... DigiCert. Similarly,
Apple operates a root program, yet is also trusted by Mozilla through
subordinate CAs provided through the GeoTrust hierarchy, which is owned
by... DigiCert.

Google operates a root program, yet is also trusted by Mozilla through...
the acquisition of key material (from GlobalSign) and the operation of
independent roots.

If we accept this assumption as sound, then it seems the argument is that
DigiCert can also never be distrusted, and interpretations will always be
to the benefit of DigiCert, because to distrust DigiCert or take sanction
would be to disrupt 'critical' services like Azure or iTunes.

Alternatively, one could argue/make assumptions that by virtue of Google
previously having operated a subordinate under the GeoTrust hierarchy
(DigiCert, formerly Symantec), that they've demonstrated it's possible to
operate as subordinate or root. They demonstrably took steps regarding the
Symantec hierarchy, even as it was the basis for trust of Google services.
In that model, if Google CA were to take actions detrimental to the
ecosystem, Google may interpret the BRs in the Internet trust and
stabilities best interests, distrust the Google CA, and force Google to
transition to an alternative solution precisely to avoid the alternative.

The problem here is these are all assumptions that rest on ignoring
pertinent details.


> FACT: Google is a module peer in Mozilla NSS, which means Google has
> significant influence over BR interpretation, the penalties related to CA
> mis-issuance, and the requirements a CA has for operating within the space.
> This gives one CA a lot of influence over how Mozilla treats the other
> CAs.
> The change in paradigm means a reasonable person (like Jake) could be
> concerned with potential obfuscation of problems, a loss of policy
> enforcement, and various other nefarious acts. I think most of us Mozilla
> users see Mozilla as a watch-dog of the Internet so this combination of
> Browser-CA-module peer reasonably causes unease.
>

Un

RE: Remove old WoSign root certs from NSS

[Richard Wang via dev-security-policy]

Please stop to misleading the audience, the first news has link that refer to 
second news.

We have provided best service for our customer more than 10 years that we are 
continue as always, to provide high quality pre-sale and after-sales service 
for our customers.

Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Percy via dev-security-policy
Sent: Wednesday, August 30, 2017 3:54 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Remove old WoSign root certs from NSS

On Sunday, August 27, 2017 at 10:59:48 PM UTC-7, Richard Wang wrote:
> We released replacement notice in Chinese in our website:
> https://www.wosign.com/news/announcement-about-Microsoft-Action-20170809.htm 
> https://www.wosign.com/news/announcement-about-Google-Action-20170710.htm 
> https://www.wosign.com/news/announcement_about_Mozilla_Action_20161024.htm
> 
> And we have sent broadcast email to our customer, but some customers still 
> don't replace its certificate due to many kind of reasons that this must be 
> cooperated by customers.
> 
> 
> Best Regards,
> 
> Richard

I have to point out that of all the above 3 post, only one, namely 
https://www.wosign.com/news/announcement-about-Google-Action-20170710.htm 
mentions anything about replacing the certs. 
___
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: Remove old WoSign root certs from NSS

[Richard Wang via dev-security-policy]

We released replacement notice in Chinese in our website:
https://www.wosign.com/news/announcement-about-Microsoft-Action-20170809.htm
https://www.wosign.com/news/announcement-about-Google-Action-20170710.htm
https://www.wosign.com/news/announcement_about_Mozilla_Action_20161024.htm

And we have sent broadcast email to our customer, but some customers still 
don't replace its certificate due to many kind of reasons that this must be 
cooperated by customers.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Percy via dev-security-policy
Sent: Monday, August 28, 2017 11:34 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Remove old WoSign root certs from NSS

On Friday, August 25, 2017 at 4:42:29 PM UTC-7, Kathleen Wilson wrote:
> On Friday, August 4, 2017 at 12:01:15 AM UTC-7, Percy wrote:
> > I suggest that Mozilla can post an announcement now about the
> > complete removal of WoSign/StartCom to alert website developers. I
> > suspect that a moderate amount of Chinese websites are still using
> > WoSign certs chained to the old roots. Google posted about this
> > complete removal here
> > https://security.googleblog.com/2017/07/final-removal-of-trust-in-wo
> > sign-and.html
> >
> > And since WoSign has the most presence in China, I suggest Mozilla can 
> > instruct Mozilla China to post such announcement in Chinese as well.
>
>
> Here's a DRAFT for such an announcement, that I could post to Mozilla's 
> Security Blog [1].
>
> ~~ DRAFT ~~
>
> Title: Removing Disabled WoSign and StartCom Certificates from Firefox
> 58
>
> In October 2016, Mozilla announced[2] that, as of Firefox 51, we would stop 
> validating new certificates chaining to the below list of root certificates 
> owned by the companies WoSign and StartCom.
>
> The announcement also indicated our intent to eventually completely remove 
> these root certificates from Mozilla’s Root Store[3], so that we would no 
> longer validate certificates issued even before that date by those roots. 
> That time has now arrived. We plan to release the relevant changes[4] to 
> Network Security Services (NSS)[5] in November, and then the changes will be 
> picked up in Firefox 58[6], due for release in January 2018. Sites using 
> certificates chaining up to any of the following root certificates need to 
> migrate to another root certificate.
>
> This announcement applies to the root certificates with the following names:
>
> CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN CN=Certification
> Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN
> CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited,
> C=CN CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
> CN=StartCom Certification Authority, OU=Secure Digital Certificate
> Signing, O=StartCom Ltd., C=IL CN=StartCom Certification Authority G2,
> OU=null, O=StartCom Ltd., C=IL
>
> Mozilla Security Team
> ~~
>
> As always, I will appreciate your constructive feedback.
>
> Thanks,
> Kathleen
>
> [1] https://blog.mozilla.org/security/
> [2]
> https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-an
> d-startcom-certificates/
> [3] https://wiki.mozilla.org/CA
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1387260
> https://bugzilla.mozilla.org/show_bug.cgi?id=1392849
> [5] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS
> [6] https://wiki.mozilla.org/RapidRelease/Calendar

Such an announcement will be great. And Chinese translation posted on Mozilla 
China will be greatly appreciated too.

A Chinese announcement is rather appreciated because some very large companies, 
for example, OFO which received $450M in funding and currently valued at 1B [1] 
is still using WoSign certs [2]; Fapiao, which deals with receipts for 
Starbucks in China, was using the old WoSign cert[3] until two weeks ago. It 
only changed the cert after customer complaints for months. Those are by far 
not isolated cases.


[1]https://en.wikipedia.org/wiki/Ofo_(bike_sharing)
[2]https://common.ofo.so/
[3]https://crt.sh/?q=fapiao.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: Microsoft to remove WoSign and StartCom certificates in Windows 10

[Richard Wang via dev-security-policy]

Notice to WoSign customers:

This announcement is for WoSign old roots:

1) CN=CA 沃通根证书, O=WoSign CA Limited, C=CN
2) CN=Certification Authority of WoSign, O=WoSign CA Limited, C=CN
3) CN=Certification Authority of WoSign G2, O=WoSign CA Limited, C=CN
4) CN=CA WoSign ECC Root, O=WoSign CA Limited, C=CN

This distrust action is no any relationship with the current trusted Managed 
Sub CA issued certificates, this distrust action doesn't affect all SSL 
certificates issued by the Managed Sub CA after Nov 21, 2016. WoSign have 
stopped to sell SSL certificate to customers from the above old roots that 
Microsoft plan to distrust since Oct 20, 2016.

敬告沃通用户：

微软宣布的是9月26日后不信任WoSign老根证书签发的证书，并不是指目前WoSign销售的SSL证书。目前销售的SSL证书都是从其他信任CA根证书签发的证书，不受任何影响。


Best Regards,

WoSign CA Limited



-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Percy via dev-security-policy
Sent: Wednesday, August 9, 2017 2:03 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Microsoft to remove WoSign and StartCom certificates in Windows 10

https://blogs.technet.microsoft.com/mmpc/2017/08/08/microsoft-to-remove-wosign-and-startcom-certificates-in-windows-10/

Microsoft has concluded that the Chinese Certificate Authorities (CAs) WoSign 
and StartCom have failed to maintain the standards required by our Trusted Root 
Program. Observed unacceptable security practices include back-dating SHA-1 
certificates, mis-issuances of certificates, accidental certificate revocation, 
duplicate certificate serial numbers, and multiple CAB Forum Baseline 
Requirements (BR) violations.

Thus, Microsoft will begin the natural deprecation of WoSign and StartCom 
certificates by setting a “NotBefore” date of 26 September 2017. This means all 
existing certificates will continue to function until they self-expire. Windows 
10 will not trust any new certificates from these CAs after September 2017.

Microsoft values the global Certificate Authority community and only makes 
these decisions after careful consideration as to what is best for the security 
of our users.
___
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 cross-signs disclosed by Certinomis

[Richard Wang via dev-security-policy]

For adding Richard Wang back to StartCom UK director is for the completion 
separation, this is a temporally adding as director for signing bank document 
to change the bank signer person from Richard Wang to New CEO Inigo. It will be 
removed soon once the bank signer change is done.

Mr. Jon Luk (Alliotts) is the accountant of StartCom UK that he processed this 
change, anyone can contact him to verify this change intention.

For StartCom, Richard Wang is 100% no any relationship after the separation, 
Qihoo 360 100% get rid of Richard Wang in StartCom case.

BTW, StartCom UK is the 100% shareholder of StartCom Spain.

Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Itzhak Daniel via dev-security-policy
Sent: Tuesday, August 8, 2017 5:36 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis

On Monday, August 7, 2017 at 11:03:27 PM UTC+3, Jakob Bohm wrote: 
> 7. At Quihoo: Actually get rid of Richard Wang, not just change his
>title from CEO to COO.

I didn't map the new hierarchy of the "Spanish" StartCom CA ("StartCom CA Spain 
Sociedad Limitada"), having trouble registering to the Spanish company house 
and pull documents (I pulled from 3rd party, but they're garbage [1] [2]). I 
did mange to see that Mr. Barreira is the Directory but nothing on the share 
holders or parent company.

I took a quick look at StartCom UK (as the information there is free) and 
noticed Mr. Wang became a director again [3]... I wonder who is "StartCom CA 
Spain Sociedad Limitada" parent/share holder, maybe a disclosure?

___
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 new system passed Cure 53 system security audit

[Richard Wang via dev-security-policy]

Hi Peter,

Thanks for your guesses.
Buy no those issues in our system.


Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Friday, July 14, 2017 8:55 AM
To: Richard Wang <rich...@wosign.com>
Cc: r...@sleevi.com; Jonathan Rudenberg <jonat...@titanous.com>; 
mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: WoSign new system passed Cure 53 system security audit

Richard,

I can only guess what Ryan is talking about as the report wasn't sent to this 
group, but it is possible that the system described could not meet the Baseline 
Requirements, as the BRs do require certain system designs.  For example, two 
requirements are:

"Require that each individual in a Trusted Role use a unique credential created 
by or assigned to that person in order to authenticate to Certificate Systems" 
and "Enforce multi-factor authentication for administrator access to Issuing 
Systems and Certificate Management Systems"

If the system does not do these things, then it "cannot meet the BRs, you would 
have to change that system to meet the BR" (quoting Ryan).

Please keep in mind that these are only guesses; there are numerous other 
things that could be the report that could lead to the same conclusion.

Thanks,
Peter

On Thu, Jul 13, 2017 at 5:04 PM, Richard Wang via dev-security-policy 
<dev-security-policy@lists.mozilla.org> wrote:
> Hi Ryan,
>
> Thanks for your detail info.
>
> But I still CAN NOT understand why you say and confirm that the new system 
> cannot and does not comply with BR before we start to use it.
>
> We will do the BR audit soon.
>
> Best Regards,
>
> Richard
>
> On 14 Jul 2017, at 00:50, Ryan Sleevi 
> <r...@sleevi.com<mailto:r...@sleevi.com>> wrote:
>
> You will fail #4. Because your system, as designed, cannot and does not 
> comply with the Baseline Requirements.
>
> As such, you will then
> (4.1) Update new system, developing new code and new integrations
> (4.2) Engage the auditor to come back on side
> (4.3) Hope you get it right this time
> (4.4) Generate a new root
> (4.5) Do the PITRA audit and hopefully pass
> (4.6) Hope that the security audit from #1 still applies to #4.1 [but
> because the changes needed are large, it's hard to imagine]
> (5) Apply for the new root inclusion
>
> The system you had security audited in #1 cannot pass #4. That's why working 
> with an auditor to do a readiness assessment in conjunction with or before 
> the security assessment can help ensure you can meet the BRs, and then ensure 
> you can meet them securely.
>
> On Thu, Jul 13, 2017 at 11:04 AM, Richard Wang 
> <rich...@wosign.com<mailto:rich...@wosign.com>> wrote:
> Hi Ryan,
>
> I really don't understand where the new system can't meet the BR, we don't 
> use the new system to issue one certificate, how it violate the BR?
>
> Our step is:
> (1) develop a new secure system in the new infrastructure, then do the
> new system security audit, pass the security audit;
> (2) engage a WebTrust auditor onsite to generate the new root in the
> new system;
> (3) use the new audited system to issue certificate;
> (4) do the PITRA audit and WebTrust audit;
> (5) apply the new root inclusion.
>  While we start to apply the new root application, we will follow the
> requirements here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1311824
> to demonstrate we meet the 6 requirements.
>
> We will discard the old system and facilitates, so the right order should be 
> have-new-system first, then audit the new system, then apply the new root 
> inclusion. We can not use the old system to do the BR audit.
>
> Please advise, thanks.
>
>
> Best Regards,
>
> Richard
>
> On 13 Jul 2017, at 21:53, Ryan Sleevi 
> <r...@sleevi.com<mailto:r...@sleevi.com>> wrote:
>
> Richard,
>
> That's great, but the system that passed the full security audit cannot meet 
> the BRs, you would have to change that system to meet the BRs, and then that 
> new system would no longer be what was audited.
>
> I would encourage you to address the items in the order that Mozilla posed 
> them - such as first systematically identifying and addressing the flaws 
> you've found, and then working with a qualified auditor to demonstrate both 
> remediation and that the resulting system is BR compliant. And then perform 
> the security audit. This helps ensure your end result is most aligned with 
> the desired state - and provides the public the necessary assurances that 
> WoSign, and their management, understand what's required of a publicly 
> trusted CA.
>
> On Wed, Jul 12, 2017 at 10:24 PM, Richard Wang 
> <rich...@wosi

Re: WoSign new system passed Cure 53 system security audit

[Richard Wang via dev-security-policy]

Hi Ryan,

Thanks for your detail info.

But I still CAN NOT understand why you say and confirm that the new system 
cannot and does not comply with BR before we start to use it.

We will do the BR audit soon.

Best Regards,

Richard

On 14 Jul 2017, at 00:50, Ryan Sleevi <r...@sleevi.com<mailto:r...@sleevi.com>> 
wrote:

You will fail #4. Because your system, as designed, cannot and does not comply 
with the Baseline Requirements.

As such, you will then
(4.1) Update new system, developing new code and new integrations
(4.2) Engage the auditor to come back on side
(4.3) Hope you get it right this time
(4.4) Generate a new root
(4.5) Do the PITRA audit and hopefully pass
(4.6) Hope that the security audit from #1 still applies to #4.1 [but because 
the changes needed are large, it's hard to imagine]
(5) Apply for the new root inclusion

The system you had security audited in #1 cannot pass #4. That's why working 
with an auditor to do a readiness assessment in conjunction with or before the 
security assessment can help ensure you can meet the BRs, and then ensure you 
can meet them securely.

On Thu, Jul 13, 2017 at 11:04 AM, Richard Wang 
<rich...@wosign.com<mailto:rich...@wosign.com>> wrote:
Hi Ryan,

I really don't understand where the new system can't meet the BR, we don't use 
the new system to issue one certificate, how it violate the BR?

Our step is:
(1) develop a new secure system in the new infrastructure, then do the new 
system security audit, pass the security audit;
(2) engage a WebTrust auditor onsite to generate the new root in the new system;
(3) use the new audited system to issue certificate;
(4) do the PITRA audit and WebTrust audit;
(5) apply the new root inclusion.
 While we start to apply the new root application, we will follow the 
requirements here: https://bugzilla.mozilla.org/show_bug.cgi?id=1311824
to demonstrate we meet the 6 requirements.

We will discard the old system and facilitates, so the right order should be 
have-new-system first, then audit the new system, then apply the new root 
inclusion. We can not use the old system to do the BR audit.

Please advise, thanks.


Best Regards,

Richard

On 13 Jul 2017, at 21:53, Ryan Sleevi <r...@sleevi.com<mailto:r...@sleevi.com>> 
wrote:

Richard,

That's great, but the system that passed the full security audit cannot meet 
the BRs, you would have to change that system to meet the BRs, and then that 
new system would no longer be what was audited.

I would encourage you to address the items in the order that Mozilla posed them 
- such as first systematically identifying and addressing the flaws you've 
found, and then working with a qualified auditor to demonstrate both 
remediation and that the resulting system is BR compliant. And then perform the 
security audit. This helps ensure your end result is most aligned with the 
desired state - and provides the public the necessary assurances that WoSign, 
and their management, understand what's required of a publicly trusted CA.

On Wed, Jul 12, 2017 at 10:24 PM, Richard Wang 
<rich...@wosign.com<mailto:rich...@wosign.com>> wrote:
Hi Ryan,

We got confirmation from Cure 53 that new system passed the full security 
audit. Please contact Cure 53 directly to verify this, thanks.

We don't start the BR audit now.

Best Regards,

Richard

On 12 Jul 2017, at 22:09, Ryan Sleevi <r...@sleevi.com<mailto:r...@sleevi.com>> 
wrote:



On Tue, Jul 11, 2017 at 8:18 PM, Richard Wang 
<rich...@wosign.com<mailto:rich...@wosign.com>> wrote:
Hi all,

Your reported BR issues is from StartCom, not WoSign, we don't use the new 
system to issue any certificate now since the new root is not generated.
PLEASE DO NOT mix it, thanks.

Best Regards,

Richard

No, the BR non-compliance is demonstrated from the report provided to browsers 
- that is, the full report associated with this thread.

That is, as currently implemented, the infrastructure for the new roots would 
not be able to receive an unqualified audit. Further system work is necessary, 
and that work is significant enough that it will affect the conclusions from 
the report.


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

Re: WoSign new system passed Cure 53 system security audit

[Richard Wang via dev-security-policy]

Hi Ryan,

I really don't understand where the new system can't meet the BR, we don't use 
the new system to issue one certificate, how it violate the BR?

Our step is:
(1) develop a new secure system in the new infrastructure, then do the new 
system security audit, pass the security audit;
(2) engage a WebTrust auditor onsite to generate the new root in the new system;
(3) use the new audited system to issue certificate;
(4) do the PITRA audit and WebTrust audit;
(5) apply the new root inclusion.
 While we start to apply the new root application, we will follow the 
requirements here: https://bugzilla.mozilla.org/show_bug.cgi?id=1311824
to demonstrate we meet the 6 requirements.

We will discard the old system and facilitates, so the right order should be 
have-new-system first, then audit the new system, then apply the new root 
inclusion. We can not use the old system to do the BR audit.

Please advise, thanks.


Best Regards,

Richard

On 13 Jul 2017, at 21:53, Ryan Sleevi <r...@sleevi.com<mailto:r...@sleevi.com>> 
wrote:

Richard,

That's great, but the system that passed the full security audit cannot meet 
the BRs, you would have to change that system to meet the BRs, and then that 
new system would no longer be what was audited.

I would encourage you to address the items in the order that Mozilla posed them 
- such as first systematically identifying and addressing the flaws you've 
found, and then working with a qualified auditor to demonstrate both 
remediation and that the resulting system is BR compliant. And then perform the 
security audit. This helps ensure your end result is most aligned with the 
desired state - and provides the public the necessary assurances that WoSign, 
and their management, understand what's required of a publicly trusted CA.

On Wed, Jul 12, 2017 at 10:24 PM, Richard Wang 
<rich...@wosign.com<mailto:rich...@wosign.com>> wrote:
Hi Ryan,

We got confirmation from Cure 53 that new system passed the full security 
audit. Please contact Cure 53 directly to verify this, thanks.

We don't start the BR audit now.

Best Regards,

Richard

On 12 Jul 2017, at 22:09, Ryan Sleevi <r...@sleevi.com<mailto:r...@sleevi.com>> 
wrote:



On Tue, Jul 11, 2017 at 8:18 PM, Richard Wang 
<rich...@wosign.com<mailto:rich...@wosign.com>> wrote:
Hi all,

Your reported BR issues is from StartCom, not WoSign, we don't use the new 
system to issue any certificate now since the new root is not generated.
PLEASE DO NOT mix it, thanks.

Best Regards,

Richard

No, the BR non-compliance is demonstrated from the report provided to browsers 
- that is, the full report associated with this thread.

That is, as currently implemented, the infrastructure for the new roots would 
not be able to receive an unqualified audit. Further system work is necessary, 
and that work is significant enough that it will affect the conclusions from 
the report.

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

Re: WoSign new system passed Cure 53 system security audit

[Richard Wang via dev-security-policy]

Hi Ryan,

We got confirmation from Cure 53 that new system passed the full security 
audit. Please contact Cure 53 directly to verify this, thanks.

We don't start the BR audit now.

Best Regards,

Richard

On 12 Jul 2017, at 22:09, Ryan Sleevi <r...@sleevi.com<mailto:r...@sleevi.com>> 
wrote:



On Tue, Jul 11, 2017 at 8:18 PM, Richard Wang 
<rich...@wosign.com<mailto:rich...@wosign.com>> wrote:
Hi all,

Your reported BR issues is from StartCom, not WoSign, we don't use the new 
system to issue any certificate now since the new root is not generated.
PLEASE DO NOT mix it, thanks.

Best Regards,

Richard

No, the BR non-compliance is demonstrated from the report provided to browsers 
- that is, the full report associated with this thread.

That is, as currently implemented, the infrastructure for the new roots would 
not be able to receive an unqualified audit. Further system work is necessary, 
and that work is significant enough that it will affect the conclusions from 
the report.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign new system passed Cure 53 system security audit

[Richard Wang via dev-security-policy]

Hi all,

Your reported BR issues is from StartCom, not WoSign, we don't use the new 
system to issue any certificate now since the new root is not generated.
PLEASE DO NOT mix it, thanks.

Best Regards,

Richard

> On 11 Jul 2017, at 23:34, Ryan Sleevi via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> On Tue, Jul 11, 2017 at 11:16 AM, Jonathan Rudenberg via
> dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> 
>> 
>>> On Jul 11, 2017, at 06:53, okaphone.elektronika--- via
>> dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
>>> 
>>>> On Monday, 10 July 2017 08:55:38 UTC+2, Richard Wang  wrote:
>>>> 
>>>> Please note this email topic is just for releasing the news that WoSign
>> new system passed the security audit, just for demonstration that we
>> finished item 5:
>>>> " 5. Provide auditor[3] attestation that a full security audit of the
>> CA’s issuing infrastructure has been successfully completed. "
>>>> " [3] The auditor must be an external company, and approved by Mozilla.
>> "
>>> 
>>> It also seems a bit strange to report item 5 "successfully completed"
>> before we hear anything about the other items. How about starting with item
>> 1? What are your plans voor fixing the problems?
>> 
>> It’s worth noting that the problems have not stopped yet. There are a
>> bunch of certificates issued over the past few months that do not comply
>> with the Baseline Requirements issued from the new "StartCom BR SSL ICA”,
>> for example:
>> 
>> https://crt.sh/?opt=cablint=8BDFE4A526BFB35C8A417B10F4D0AB
>> E9E1D60D28A412539D5BC71C19B46FEF21
>> https://crt.sh/?opt=cablint=124AAD38DAAC6B694D65F45226AB51
>> 52FC46D229CBC203E0814D175F39977FF3
>> https://crt.sh/?opt=cablint=9B78C78B32F4AC717B3DEFDABDACC4
>> FEFA61BFD17782B83F75ADD82241147721
>> https://crt.sh/?opt=cablint=AAB0B5A08F106639A5C9D720CD37FD
>> B30E7F337AEBAF9407FD854B5726303F7B
>> https://crt.sh/?opt=cablint=9DCE6A924CE837328D379CE9B7CDF4
>> A2BA8A0E8EC01018B9DE736EBC64442361
>> https://crt.sh/?opt=cablint=62A9A9FDCDC04A043CF2CB1A5EAFE3
>> 3CF9ED8796245DE4BD5250267ADEFF005A
>> https://crt.sh/?opt=cablint=6A72FA5DCC253D2EE07921898B9A9B
>> B263FD1D20FE61B1F52F939C0C1C0DCFEE
>> https://crt.sh/?opt=cablint=238E2E96665748D2A05BAAEEC8BAE6
>> AFE7B7EF4B1ADA4908354C855C385ECD81
>> https://crt.sh/?opt=cablint=C11C00EB0E14EEB30567D749FFD304
>> 45E0B490D1DCA7B7E082FD1CB0A40A71C0
>> https://crt.sh/?opt=cablint=4DEF4CFD21A969E8349E4428FDEC73
>> 767C01DE6127843312511B71029F4E3836
> 
> 
> It's worth noting that, on the basis of the security audit report full
> details shared by WoSign, the system that was security audited does not
> comply with the Baseline Requirements, nor, as designed, can it. The system
> would need to undergo non-trivial effort to comply with the Baseline
> Requirements.
> ___
> 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 new system passed Cure 53 system security audit

[Richard Wang via dev-security-policy]

I think you found the source: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1311824

Please note this email topic is just for releasing the news that WoSign new 
system passed the security audit, just for demonstration that we finished item 
5:
 " 5. Provide auditor[3] attestation that a full security audit of the CA’s 
issuing infrastructure has been successfully completed. "
" [3] The auditor must be an external company, and approved by Mozilla. "

NOT for the new root inclusion application.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Itzhak Daniel via dev-security-policy
Sent: Monday, July 10, 2017 2:39 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: WoSign new system passed Cure 53 system security audit

On Monday, July 10, 2017 at 9:00:04 AM UTC+3, Richard Wang wrote:
>  " 5. Provide auditor[3] attestation that a full security audit of the CA’s 
> issuing infrastructure has been successfully completed. "
> " [3] The auditor must be an external company, and approved by Mozilla. "

What is the source?

According to this thread [1]:
"1. Provide a list of changes that the CA plans to implement to ensure that 
there are no future violations of Mozilla Policy and the Baseline Requirements."

One of these changes is to remove the person responsible for:
1. Releasing unsecured and not fully tested software that allowed issuing 
certificates for Github without proper checks.
2. Back-dating SHA1 certificates.
3. Secretly purchasing another CA without disclosing it to Mozilla.
4. Actively lying and misleading about 2 and 3.

To my understanding, from reading the "Remediation Plan", one of the 
requirements made for WoSign by itself/parent company, is to remove the person 
responsible for most of the issue caused them to lose the trust bit.

I'm not in *any* position to tell who shell manage the daily operations of 
WoSign, but it gives a strong indication that nothing had really changed.

Links:
1. 
https://groups.google.com/d/msg/mozilla.dev.security.policy/BV5XyFJLnQM/_DwiB1PDGQAJ
___
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 new system passed Cure 53 system security audit

[Richard Wang via dev-security-policy]

Please note that the Mozilla requirement is:

 " 5. Provide auditor[3] attestation that a full security audit of the CA’s 
issuing infrastructure has been successfully completed. "
" [3] The auditor must be an external company, and approved by Mozilla. "

That WoSign did it very well -- PASS the full security audit.

And Richard Wang leading the RD team have done a good job for the new system 
development and passed the security audit.

Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Percy via dev-security-policy
Sent: Monday, July 10, 2017 12:41 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: WoSign new system passed Cure 53 system security audit

So it seems that Richard Wang still has the final executive decisions regarding 
security in daily operations. Basically WoSign simply changed the title of the 
position from CEO to COO and bypassed Mozilla's requirement?

On Sunday, July 9, 2017 at 7:26:28 PM UTC-7, Richard Wang wrote:
> The important thing is by the board of directors, the Company Legal 
> Representative is changed to Mr. Shi Xiaohong, VP of 360.
>
>
> The daily operation thing is by COO.
>
> Best Regards,
>
>
> Richard
>
>
>
> From: Eric Mill [mailto:e...@konklone.com]
> Sent: Monday, July 10, 2017 10:12 AM
> To: Richard Wang <rich...@wosign.com>
> Cc: Itzhak Daniel <itk98...@gmail.com>; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: WoSign new system passed Cure 53 system security audit
>
>
>
> So who acts as the CEO for WoSign when final executive decisions need to be 
> made?
>
>
>
>
>
> On Sun, Jul 9, 2017 at 9:41 PM, Richard Wang via dev-security-policy 
> <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
>  wrote:
>
>Mr Wang is the COO now according to Mr. Tan's public announcement on March 
> CAB Forum meeting.
>
>CEO is still N/A, if anyone is interesting in the CEO position, please 
> send your Resume to Mr. Tan.
>
>
>Best Regards,
>
>Richard
>
>
>-Original Message-
>From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard<mailto:dev-security-policy-bounces%2Brichard>=wosign@lists.mozilla.org<mailto:wosign@lists.mozilla.org>]
>  On Behalf Of Itzhak Daniel via dev-security-policy
>Sent: Monday, July 10, 2017 4:57 AM
>To: 
> mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
>Subject: Re: WoSign new system passed Cure 53 system security audit
>
>Mr. Wang is mentioned on the end of the document, what is Richard Wang 
> current official responsibility of Mr. Wang at WoSign?
>
>According to the incident report, release on October 2016 [1], Mr. Wang 
> was suppose to be relieved of his duties as CEO, this is mentioned in 3 
> separate paragraphs (P.17,P.25,P.26).
>
>Links:
>1. https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf
>
>___
>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<mailto:dev-security-policy@lists.mozilla.org>
>https://lists.mozilla.org/listinfo/dev-security-policy
>
>
>
>
>
>
>
>--
>
>konklone.com<https://konklone.com> | 
> @konklone<https://twitter.com/konklone>

___
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 new system passed Cure 53 system security audit

[Richard Wang via dev-security-policy]

The important thing is by the board of directors, the Company Legal 
Representative is changed to Mr. Shi Xiaohong, VP of 360.



The daily operation thing is by COO.





Best Regards,



Richard



From: Eric Mill [mailto:e...@konklone.com]
Sent: Monday, July 10, 2017 10:12 AM
To: Richard Wang <rich...@wosign.com>
Cc: Itzhak Daniel <itk98...@gmail.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: WoSign new system passed Cure 53 system security audit



So who acts as the CEO for WoSign when final executive decisions need to be 
made?





On Sun, Jul 9, 2017 at 9:41 PM, Richard Wang via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

   Mr Wang is the COO now according to Mr. Tan's public announcement on March 
CAB Forum meeting.

   CEO is still N/A, if anyone is interesting in the CEO position, please send 
your Resume to Mr. Tan.


   Best Regards,

   Richard


   -Original Message-
   From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard<mailto:dev-security-policy-bounces%2Brichard>=wosign@lists.mozilla.org<mailto:wosign@lists.mozilla.org>]
 On Behalf Of Itzhak Daniel via dev-security-policy
   Sent: Monday, July 10, 2017 4:57 AM
   To: 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
   Subject: Re: WoSign new system passed Cure 53 system security audit

   Mr. Wang is mentioned on the end of the document, what is Richard Wang 
current official responsibility of Mr. Wang at WoSign?

   According to the incident report, release on October 2016 [1], Mr. Wang was 
suppose to be relieved of his duties as CEO, this is mentioned in 3 separate 
paragraphs (P.17,P.25,P.26).

   Links:
   1. https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf

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







   --

   konklone.com<https://konklone.com> | @konklone<https://twitter.com/konklone>

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

RE: WoSign new system passed Cure 53 system security audit

[Richard Wang via dev-security-policy]

Mr Wang is the COO now according to Mr. Tan's public announcement on March CAB 
Forum meeting.

CEO is still N/A, if anyone is interesting in the CEO position, please send 
your Resume to Mr. Tan.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Itzhak Daniel via dev-security-policy
Sent: Monday, July 10, 2017 4:57 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: WoSign new system passed Cure 53 system security audit

Mr. Wang is mentioned on the end of the document, what is Richard Wang current 
official responsibility of Mr. Wang at WoSign?

According to the incident report, release on October 2016 [1], Mr. Wang was 
suppose to be relieved of his duties as CEO, this is mentioned in 3 separate 
paragraphs (P.17,P.25,P.26).

Links:
1. https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf

___
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: Symantec Conclusions and Next Steps

[Richard Wang via dev-security-policy]

Hi Ryan,



For your question “Do you believe that, during the discussions about how to 
respond to WoSign's issues, the scope of impact was underestimated?”, the 
answer is YES.



After Oct 21 2016, WoSign stopped to issue SSL certificates from WoSign root 
(to be exactly, maybe few in October, but all replaced), we know our customers 
don’t accept the problem of interoperability and compatibility failures, so we 
cooperated with other Trusted CAs to sell their certificates to our customers 
since Nov 21 2016, to replace the affected SSL certificates and code signing 
certificates for our charged customers for FREE, to renew and order 
certificates for current customers and new customers to keep our business 
continuity till we have our own new trusted roots.



WoSign appreciated Mozilla’s decision: trust the certificates that issued 
before Oct 20 2016, and similarly rule for Apple and Microsoft, and we also 
promised to our customers for this, this decision don’t bring any troubles to 
our issued certificate customers, very good.



But Google start to distrust WoSign certificates unless the site is in the 
Alexa Top 1M site list since Chrome 57, this bring many problems to us and to 
our customers, to provide best service to our customers, we provide FREE 
replacement for our charged customers that we must pay the cost to the Partner 
(Trusted CA). Till now, we replaced 596 certificates for our customers for 
free, and there are 97 orders ask for refund instead of replacement. This 
Google decision’s problem is some big websites used a domain that not listed in 
Alexa 1M suffered disruption, for example, Qihoo 360’s search site and online 
gaming sites used a domain in CDN for pictures that not listed in Top 1M, there 
are more than 500M users suffered the untrusted warning and 360 need to replace 
the certificates for thousands of servers.



The problem also come from the WoSign Root CA pinned for some payment gateway 
from online payment service providers and from some online banking APPs, even 
we replaced the certificate for them for free, they need to update the 
gateway/API software to accept the new trusted root, and need to update the 
bank APP to recognize the new certificate and new root, this is terrible that 
all those customers curse us and very angry.



For affected 2417 Code Signing certificates, there are many customers signed 
the code, but distrusted by Microsoft that customers ask for full refund and 
need to buy the new code signing cert from other CA that need to sign the 
software again that installed in billions system, this is also a disaster to 
customers and its software users.

We can’t image the result in the future for “In subsequent Chrome releases, 
these exceptions will be reduced and ultimately removed, culminating in the 
full distrust of WoSign”, this means all WoSign issued SSL certificates in the 
last three years need to be replaced, including the 2845 valid certificates for 
Microsoft Azure and Office 365 that Microsoft Sumedh said “any outage of an 
Azure service that lasts more than a few minutes gets escalated to our 
executives.”

The total valid SSL certificates is 173,886, and the charged valid certificates 
is 10,368 that we need to pay money to other CA for free replacement (if US$100 
per certificate, the total cost is over US$ One Million!), I think this is not 
only money problem, but it also will bring huge work to us and to our customers 
to replace the certificate. This is the next BIG disaster if Chrome distrust 
all WoSign certificates that issued before Oct. 20 2016.



So, I wish Google can reconsider the plan that change to distrust all WoSign 
issued free SSL certificates, but keep to trust the charged one (DV SSL/IV 
SSL/OV SSL/EV SSL) that don’t have any mis-issuance problem, those charged 
certificates is used for many big eCommerce websites, many government websites, 
many bank systems, many securities systems, many cloud service providers like 
Azure that used by the world biggest companies. Thanks.



So, this is why I said some words for Symantec to let browsers to consider the 
distrust result seriously. The Web Ecosystem players not just browsers, but 
also the CAs, and also the website owners (certificate subscribers), we all 
have the responsibility for the global Internet security, but we need to 
balance all related party’s benefit and negotiate an acceptable solution for 
any problem that happened.

Thanks.



Best Regards,



Richard



From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Thursday, April 27, 2017 8:38 PM
To: Richard Wang <rich...@wosign.com>
Cc: Steve Medin <steve_me...@symantec.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec Conclusions and Next Steps



Hi Richard,



On Thu, Apr 27, 2017 at 6:13 AM, Richard Wang via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

   I like to share the exp

RE: Symantec Conclusions and Next Steps

[Richard Wang via dev-security-policy]

I like to share the experience we suffered from distrust, it is disastrous for 
CA and its customers to replace the certificate that exceed your imagination 
that we are still working for this since October 2016 that nearly six months 
now.

Due to the quantity of Symantec customers is more than WoSign and most 
companies are bigger than WoSign's customers, I am sure that the 
interoperability and compatibility failures could bring big problem to 
Symantec, to Symantec customers and the Browser users.

I think Symantec's proposal is good and will benefit its customers that it will 
not make the world mess.

Thanks.

Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Steve Medin via dev-security-policy
Sent: Thursday, April 27, 2017 8:48 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Symantec Conclusions and Next Steps


Feedback from our Enterprise Customers 

In addition to our review of public commentary on these issues, we have also 
sought input and feedback from Symantec customers on the compatibility and 
interoperability impact of the significant changes that could result from the 
implementation of Google’s proposal. These customers include many of the 
largest financial services, critical infrastructure, retail and healthcare 
organizations in the world, as well as many government agencies. This cohort is 
an important constituency that we believe has been under-represented to date in 
the public commentary that has been posted to the Google and Mozilla boards 
since large organizations rarely authorize employees to engage in such public 
discussions, particularly in an area related to security. We first solicited 
feedback to understand the disruption that a browser-initiated trust change, 
like the one proposed by Google, would cause organizations that opt to replace 
their existing SSL/TLS certificates in order to maintain interoperability with 
all browsers. We learned that these organizations’ publicly facing web 
applications, while extensive, only represent a fraction of their dependency on 
publicly trusted Symantec roots. Many large organizations have complex, and 
potentially undocumented and little-known dependencies on their certificate 
infrastructure. Examples of complex dependencies on Symantec public roots that 
our customers have shared or we have identified include:

- Embedded devices that are pinned to certificates issued by a Symantec public 
root to communicate to resources over the Internet or Intranet. Replacing these 
certificates would result in immediate failures and the need to recode and 
reimage the firmware for these devices.
- Mobile applications that have pinned certificates. Replacing server 
certificates would require these applications to be recoded, recompiled and 
redistributed.
- Critical infrastructure organizations that use certificates issued off of 
Symantec roots to validate internal and external resources. In many cases the 
applications being used are pinned to Symantec certificates.
- Some large organizations use certificates chained to Symantec public roots 
for nearly all internal applications and communications. Many of these 
organizations are under regulatory requirements to encrypt even internal 
communications. 

Additionally, many of these organizations estimate that just the planning 
process to prepare to move to a new certificate authority could take many 
months and in some cases years because of unknown and undocumented 
dependencies. Moreover, few large enterprises that we’ve received feedback from 
have implemented the level of certificate lifecycle automation required to 
enable safe and cost-effective adoption of shorter validity certificates. We 
believe that it is important for the broader community to understand and give 
more weight to these compatibility and interoperability risks, particularly 
given the fact that many of these organizations are prohibited from commenting 
publicly on these topics. 

To give a perspective of scale, Symantec secures more than 80% of the world’s 
ecommerce transactions through its certificate infrastructure. Additionally, 
Symantec is the world’s largest provider of Organization Validation (OV) and 
Extended Validation (EV) certificates which are primarily used by large 
enterprises. Many of these certificates sit inside corporate and government 
networks and are an important part of the trust fabric of internal 
communications.

In short, our assessment based on customer feedback is that the 
interoperability and compatibility failures that could result from a 
large-scale certificate replacement or invalidation event would be significant 
and unpredictable.

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

RE: Criticism of Google Re: Google Trust Services roots

[Richard Wang via dev-security-policy]

Qihoo 360 CSO Mr. Tan updated this in the recent CAB Forum meeting in USA : CEO 
of WoSign is NA, Richard Wang is the COO. 


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of urijah--- via dev-security-policy
Sent: Friday, March 31, 2017 2:07 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Criticism of Google Re: Google Trust Services roots

> and we don't think our brand is "tarnishing", we are working hard to try to 
> regain the trust and confidence in this community.

Wasn't a prerequisite for that process your stepping down as CEO of WoSign?



On Thursday, March 30, 2017 at 9:49:25 PM UTC-4, Richard Wang wrote:
> To be transparent, WoSign are NOT "acquiring the HARICA root" that we NEVER 
> contact HARICA, and we don't think our brand is "tarnishing", we are working 
> hard to try to regain the trust and confidence in this community.
> 
> 
> Best Regards,
> 
> Richard
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign.com@lists.mozilla.o
> rg] On Behalf Of Peter Kurrasch via dev-security-policy
> Sent: Thursday, March 30, 2017 9:02 PM
> To: Gervase Markham via dev-security-policy <g...@mozilla.org>; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Criticism of Google Re: Google Trust Services roots
> 
> By "not new", are you referring to Google being the second(?) instance where 
> a company has purchased an individual root cert from another company? It's 
> fair enough to say that Google isn't the first but I'm not aware of any 
> commentary or airing of opposing viewpoints as to the suitability of this 
> practice going forward.
> 
> Has Mozilla received any notification that other companies ‎intend to acquire 
> individual roots from another CA? I wouldn't ask Mozilla to violate any 
> non-disclosures but surely it's possible to let the community know if we 
> should expect more of this? Ryan H. implied as much in a previous post but I 
> wasn't sure where he was coming from on that.
> 
> Also, does Mozilla have any policies (requirements?) regarding individual 
> root acquisition? For example, how frequently should roots be allowed to 
> change hands? What would Mozilla's response be if WoSign were to say that 
> because of the tarnishing of their own brand they are acquiring the HARICA 
> root? What if Vladimir Putin were to make such a purchase? Any requirements 
> on companies notifying the public when the acquisition takes place?
> 
> Perhaps this is putting too much of a burden on Mozilla as a somewhat 
> protector of the global PKI but I'm not sure who else is in a better position 
> for that role?
> 
> 
>   Original Message
> From: Gervase Markham via dev-security-policy
> Sent: Thursday, March 30, 2017 1:06 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Reply To: Gervase Markham
> Subject: Re: Criticism of Google Re: Google Trust Services roots
> 
> On 29/03/17 20:46, Peter Kurrasch wrote:
> > It's not inconsequential for Google to say: "From now on, nobody can 
> > trust what you see in the root certificate, even if some of it 
> > appears in the browser UI. The only way you can actually establish 
> > trust is to do frequent, possibly complicated research." It doesn't 
> > seem right that Google be allowed to unilaterally impose that change 
> > on the global PKI without any discussion from the security community.
> 
> As others in this thread have pointed out, this is not a new thing. I 
> wouldn't say that Google is "imposing" this need.
> 
> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Criticism of Google Re: Google Trust Services roots

[Richard Wang via dev-security-policy]

To be transparent, WoSign are NOT "acquiring the HARICA root" that we NEVER 
contact HARICA, and we don't think our brand is "tarnishing", we are working 
hard to try to regain the trust and confidence in this community.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Peter Kurrasch via dev-security-policy
Sent: Thursday, March 30, 2017 9:02 PM
To: Gervase Markham via dev-security-policy ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Criticism of Google Re: Google Trust Services roots

By "not new", are you referring to Google being the second(?) instance where a 
company has purchased an individual root cert from another company? It's fair 
enough to say that Google isn't the first but I'm not aware of any commentary 
or airing of opposing viewpoints as to the suitability of this practice going 
forward.

Has Mozilla received any notification that other companies ‎intend to acquire 
individual roots from another CA? I wouldn't ask Mozilla to violate any 
non-disclosures but surely it's possible to let the community know if we should 
expect more of this? Ryan H. implied as much in a previous post but I wasn't 
sure where he was coming from on that.

Also, does Mozilla have any policies (requirements?) regarding individual root 
acquisition? For example, how frequently should roots be allowed to change 
hands? What would Mozilla's response be if WoSign were to say that because of 
the tarnishing of their own brand they are acquiring the HARICA root? What if 
Vladimir Putin were to make such a purchase? Any requirements on companies 
notifying the public when the acquisition takes place?

Perhaps this is putting too much of a burden on Mozilla as a somewhat protector 
of the global PKI but I'm not sure who else is in a better position for that 
role?


  Original Message
From: Gervase Markham via dev-security-policy
Sent: Thursday, March 30, 2017 1:06 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: Criticism of Google Re: Google Trust Services roots

On 29/03/17 20:46, Peter Kurrasch wrote:
> It's not inconsequential for Google to say: "From now on, nobody can
> trust what you see in the root certificate, even if some of it appears
> in the browser UI. The only way you can actually establish trust is to
> do frequent, possibly complicated research." It doesn't seem right
> that Google be allowed to unilaterally impose that change on the
> global PKI without any discussion from the security community.

As others in this thread have pointed out, this is not a new thing. I wouldn't 
say that Google is "imposing" this need.

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: Google Trust Services roots

[Richard Wang via dev-security-policy]

Good demo, thanks.

I checked that you are using Startfield EV OID in Startfield name root and in 
Amazon name root, means you are using the transferred root's EV OID. But I 
checked your CPS that don't state this point, please advise, thanks.


Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Friday, March 10, 2017 2:16 PM
To: Richard Wang <rich...@wosign.com>
Cc: Ryan Sleevi <r...@sleevi.com>; Gervase Markham <g...@mozilla.org>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Google Trust Services roots

On Wed, Mar 8, 2017 at 10:14 PM, Richard Wang <rich...@wosign.com> wrote:
> Why we setup one EV OID for all roots is that we use the same policy
> for all EV SSL certificate no matter it is issued by which root. The
> policy OID is unique ID
>
> If Google use the GlobalSign EV OID, and GlobalSign also use this EV OID, 
> this means two companies use the same policy?
>
> It is better to do a test: Google issue a EV SSL certificate from this 
> acquired root using the GlobalSign EV OID, then check every browser's UI 
> display info, to check if that info will confuse the browser users.

Richard,

I'll make this easier:

Go to https://good.sca1a.amazontrust.com/ and 
https://good.sca0a.amazontrust.com/  in Safari and Microsoft IE/Edge.
Tell me which CA issued the certificates for those sites.  (Note that we don't 
send SCTs on those sites right now, so they aren't treated as EV in Chrome, and 
we are still pending for EV in Mozilla)

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

Re: Google Trust Services roots

[Richard Wang via dev-security-policy]

Clear, thanks.

Best Regards,

Richard

> On 9 Mar 2017, at 22:05, Gervase Markham via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
>> On 09/03/17 12:38, Richard Wang wrote:
>> As my understanding, if WoSign buy an trusted EV enabled root key
>> with EV OID today, then we can issue WoSign EV SSL cert using this EV
>> OID tomorrow, the browser will display EV green bar. Right? 
> 
> Technically, you are correct - such certs would produce the EV UI.
> However, if you didn't have an EV audit which covered the root, your
> root would quickly get kicked out of the root programs.
> 
> 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: Google Trust Services roots

[Richard Wang via dev-security-policy]

As my understanding, if WoSign buy an trusted EV enabled root key with EV OID 
today, then we can issue WoSign EV SSL cert using this EV OID tomorrow, the 
browser will display EV green bar. Right? 
If right, we like this policy, thanks.

Best Regards,

Richard

> On 9 Mar 2017, at 19:51, Gervase Markham <g...@mozilla.org> wrote:
> 
>> On 09/03/17 02:15, Richard Wang wrote:
>> So the policy can make clear that the root key transfer can't
>> transfer the EV OID, the receiver must use its own EV policy OID for
>> its EV SSL, the receiver can't use the transferor's EV OID.
> 
> We could indeed write this into the policy, but it would have the effect
> of stopping the receiver of the root from issuing EV certs until the
> updated root store with the new policy OID mapping was in all Firefoxes.
> Given that OIDs are just opaque identifiers, it seems unnecessary to
> require this.
> 
> What security or other problem is caused if e.g. Google were to use an
> EV OID originally used by (or still used by) GlobalSign, assuming the
> two companies agreed that was OK?
> 
> Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Google Trust Services roots

[Richard Wang via dev-security-policy]

Why we setup one EV OID for all roots is that we use the same policy for all EV 
SSL certificate no matter it is issued by which root. The policy OID is unique 
ID 

If Google use the GlobalSign EV OID, and GlobalSign also use this EV OID, this 
means two companies use the same policy? 

It is better to do a test: Google issue a EV SSL certificate from this acquired 
root using the GlobalSign EV OID, then check every browser's UI display info, 
to check if that info will confuse the browser users.


Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Thursday, March 9, 2017 1:11 PM
To: Richard Wang <rich...@wosign.com>
Cc: Ryan Sleevi <r...@sleevi.com>; Gervase Markham <g...@mozilla.org>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Google Trust Services roots

Richard,

I'm afraid a few things are confused here.

First, a single CA Operator may have multiple roots in the browser trust list.  
Each root may list one or more certificate policies that map to the EV policy.  
Multiple roots that follow the same policy may use the same policy IDs and 
different roots from the same operator may use different policies.

For example, I see the following in the Microsoft trust list:

CN=CA 沃通根证书,O=WoSign CA Limited,C=CN
CN=Class 1 Primary CA,O=Certplus,C=FR
CN=Certification Authority of WoSign,O=WoSign CA Limited,C=CN CN=CA WoSign ECC 
Root,O=WoSign CA Limited,C=CN CN=Certification Authority of WoSign G2,O=WoSign 
CA Limited,C=CN each of these has one EV mapped policy: 1.3.6.1.4.1.36305.2

CN=AffirmTrust Commercial,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.1 mapped to EV
CN=AffirmTrust Networking,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.2 mapped to EV
CN=AffirmTrust Premium,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.3 mapped to EV
CN=AffirmTrust Premium ECC,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.4 mapped to EV
All of these are from the same company but each has their own policy identifier.

The information on "Identified by " in Microsoft's browsers comes 
from the "Friendly Name" field in the trust list. For example the friendly name 
of CN=Class 1 Primary CA,O=Certplus,C=FR is "WoSign 1999".

For something like the AffirmTrust example, they could easily sell one root 
along with the exclusive right to use that root's EV OID without impacting 
their other OIDs.

Does that make sense?

Thanks,
Peter

On Wed, Mar 8, 2017 at 8:44 PM, Richard Wang via dev-security-policy 
<dev-security-policy@lists.mozilla.org> wrote:
> I don’t think so, please check this page: 
> https://cabforum.org/object-registry/ that listed most CA’s EV OID, and all 
> browsers ask for the CA’s own EV OID when applying inclusion and EV enabled. 
> So, as I understand that the browser display EV green bar and display the 
> “Identified by CA name” is based on this CA’s EV OID.
>
>
>
> I don’t think Symantec have the reason to use GlobalSign EV OID in its EV SSL 
> certificate, why Symantec don’t use his own EV OID? If Symantec issued a EV 
> SSL using GlobalSign's EV OID, I think IE browser will display this EV SSL is 
> identified by GlobalSign, not by Symantec.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Google Trust Services roots

[Richard Wang via dev-security-policy]

I don’t think so, please check this page: https://cabforum.org/object-registry/ 
that listed most CA’s EV OID, and all browsers ask for the CA’s own EV OID when 
applying inclusion and EV enabled. So, as I understand that the browser display 
EV green bar and display the “Identified by CA name” is based on this CA’s EV 
OID.



I don’t think Symantec have the reason to use GlobalSign EV OID in its EV SSL 
certificate, why Symantec don’t use his own EV OID? If Symantec issued a EV SSL 
using GlobalSign's EV OID, I think IE browser will display this EV SSL is 
identified by GlobalSign, not by Symantec.





Best Regards,



Richard



From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Thursday, March 9, 2017 12:21 PM
To: Gervase Markham <g...@mozilla.org>; Richard Wang <rich...@wosign.com>; Ryan 
Sleevi <r...@sleevi.com>; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Google Trust Services roots



Well, you still said the same thing, and I understood what you said, but not 
why you said it or why you believe it. That's why I was asking for new details.



Certificate Policy OIDs don't say who the certificate belongs to or who issued 
the certificate. They describe the policies relative to how the certificate was 
issued and validated. This is much clearer if you read the relevant ETSI TS/EN 
series of docs related to Certificate Policies.



To your point about identifying the issuer, I may be misunderstanding your 
point, but it sounds like you're just confused about how browsers work. 
Browsers don't look up the EV OID to determine who the issuer is, so if you're 
concerned that would present a problem, it doesn't.



Instead, browsers look for *any* EV enabled OID in the leaf certificate, then 
attempt to build/verify that a chain can be built to one or more root 
certificates "enabled" for that OID. If they can, the leaf is called EV, and 
the browser determines who issued it by looking at the root.



So if Symantec were to issue such a certificate using GlobalSign's EV OID, and 
Symantec's root was enabled for that OID, and it validated according to RFC5280 
for that OID, then the certificate would appear as a Symantec-issued (because 
Symantec root) EV cert.



Of course, I have oversimplified this for you - the actual UI browsers tend to 
take is not from the root, but from the issuing intermediate, or metadata 
external to the root, so it's also not an issue for the root to say Symantec, 
ValiCert, Equifax, Norton, or something else - because that's ignored when 
better data is available, and it always is, if the CA is responsive to root 
program requirements.





On Wed, Mar 8, 2017 at 10:31 PM Richard Wang 
<rich...@wosign.com<mailto:rich...@wosign.com>> wrote:

   Maybe I don’t say it clearly.



   The EV SSL have two policy OID, one is the CABF EV OID, another one is the 
CA's EV OID, right?

   Check the EV SSL for www.symantec.com<http://www.symantec.com>, the CABF EV 
OID is 2.23.140.1.1, and the Symantec EV OID is 2.16.840.1.113733.1.7.23.6

   And check www.gloabalsign.com<http://www.gloabalsign.com> EV SSL that no 
CABF EV OID, GlobalSign EV OID is 1.3.6.1.4.1.4146.1.1



   What I mean is the GlobalSign EV OID 1.3.6.1.4.1.4146.1.1 is belong to 
GlobalSign that the browser can identity the EV SSL Issuer is GlobalSign, so 
Google can’t use this EV OID for its own EV SSL, Google must use its own EV OID 
for its EV SSL.



   So, no EV OID transfer issue for root key transfer.





   Best Regards,



   Richard



   From: Ryan Sleevi [mailto:r...@sleevi.com<mailto:r...@sleevi.com>]
   Sent: Thursday, March 9, 2017 11:14 AM
   To: Gervase Markham <g...@mozilla.org<mailto:g...@mozilla.org>>; Richard 
Wang <rich...@wosign.com<mailto:rich...@wosign.com>>; 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>


   Subject: Re: Google Trust Services roots



   Hi Richard,



   That's not how Certificate Policy OIDs work - either in the specifications 
or in the Baseline Requirements. I'm also not aware of any program requiring 
what you describe.



   Because of this, it's unclear to me, and I suspect many other readers, why 
you believe this is the case, or if you meant that it SHOULD be the case (for 
example, developing a new policy requirement), why you believe this.



   Perhaps you could share more details about your reasoning?



   On Wed, Mar 8, 2017 at 9:15 PM Richard Wang via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

  As I understand, the EV SSL have two policy OID, one is the CABF EV OID, 
another one is the CA's EV OID, so the root key transfer doesn't have the EV 
OID transfer case, CA can't transfer its own EV OID to other CA exception the 
CA is full acquired.

  So the policy can make clear that the root key transfer can't trans

RE: Google Trust Services roots

[Richard Wang via dev-security-policy]

Maybe I don’t say it clearly.



The EV SSL have two policy OID, one is the CABF EV OID, another one is the CA's 
EV OID, right?

Check the EV SSL for www.symantec.com<http://www.symantec.com>, the CABF EV OID 
is 2.23.140.1.1, and the Symantec EV OID is 2.16.840.1.113733.1.7.23.6

And check www.gloabalsign.com<http://www.gloabalsign.com> EV SSL that no CABF 
EV OID, GlobalSign EV OID is 1.3.6.1.4.1.4146.1.1



What I mean is the GlobalSign EV OID 1.3.6.1.4.1.4146.1.1 is belong to 
GlobalSign that the browser can identity the EV SSL Issuer is GlobalSign, so 
Google can’t use this EV OID for its own EV SSL, Google must use its own EV OID 
for its EV SSL.



So, no EV OID transfer issue for root key transfer.





Best Regards,



Richard



From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Thursday, March 9, 2017 11:14 AM
To: Gervase Markham <g...@mozilla.org>; Richard Wang <rich...@wosign.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Google Trust Services roots



Hi Richard,



That's not how Certificate Policy OIDs work - either in the specifications or 
in the Baseline Requirements. I'm also not aware of any program requiring what 
you describe.



Because of this, it's unclear to me, and I suspect many other readers, why you 
believe this is the case, or if you meant that it SHOULD be the case (for 
example, developing a new policy requirement), why you believe this.



Perhaps you could share more details about your reasoning?



On Wed, Mar 8, 2017 at 9:15 PM Richard Wang via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

   As I understand, the EV SSL have two policy OID, one is the CABF EV OID, 
another one is the CA's EV OID, so the root key transfer doesn't have the EV 
OID transfer case, CA can't transfer its own EV OID to other CA exception the 
CA is full acquired.

   So the policy can make clear that the root key transfer can't transfer the 
EV OID, the receiver must use its own EV policy OID for its EV SSL, the 
receiver can't use the transferor's EV OID.

   Best Regards,

   Richard

   -Original Message-
   From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard<mailto:dev-security-policy-bounces%2Brichard>=wosign@lists.mozilla.org<mailto:wosign@lists.mozilla.org>]
 On Behalf Of Gervase Markham via dev-security-policy
   Sent: Thursday, March 9, 2017 12:21 AM
   To: 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
   Subject: Re: Google Trust Services roots

   Having gained a good understanding of Peter and Ryan's positions, I think I 
am now in a position to evaluate Peter's helpful policy suggestions.

   Whether or not we decide to make updates, as Kathleen pronounced herself 
satisfied at the time with Google's presented documentation and migration plan, 
it would be unreasonable for us to retroactively censure Google for following 
that plan.

   On 09/02/17 22:55, Peter Bowen wrote:
   > Policy Suggestion A) When transferring a root that is EV enabled, it
   > should be clearly stated whether the recipient of the root is also
   > receiving the EV policy OID(s).

   I agree with this suggestion; we should update 
https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually incorporate it 
into the main policy when we fix
   https://github.com/mozilla/pkipolicy/issues/57 .


   ___
   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: Google Trust Services roots

[Richard Wang via dev-security-policy]

As I understand, the EV SSL have two policy OID, one is the CABF EV OID, 
another one is the CA's EV OID, so the root key transfer doesn't have the EV 
OID transfer case, CA can't transfer its own EV OID to other CA exception the 
CA is full acquired.

So the policy can make clear that the root key transfer can't transfer the EV 
OID, the receiver must use its own EV policy OID for its EV SSL, the receiver 
can't use the transferor's EV OID.

Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Gervase Markham via dev-security-policy
Sent: Thursday, March 9, 2017 12:21 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Google Trust Services roots

Having gained a good understanding of Peter and Ryan's positions, I think I am 
now in a position to evaluate Peter's helpful policy suggestions.

Whether or not we decide to make updates, as Kathleen pronounced herself 
satisfied at the time with Google's presented documentation and migration plan, 
it would be unreasonable for us to retroactively censure Google for following 
that plan.

On 09/02/17 22:55, Peter Bowen wrote:
> Policy Suggestion A) When transferring a root that is EV enabled, it
> should be clearly stated whether the recipient of the root is also
> receiving the EV policy OID(s).

I agree with this suggestion; we should update 
https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually incorporate it 
into the main policy when we fix
https://github.com/mozilla/pkipolicy/issues/57 .


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

Re: 360 team hacks Chrome

[Richard Wang via dev-security-policy]

Sorry, I posted an old news that I just saw it.
Please ignore it.

Best Regards,

Richard

> On 6 Mar 2017, at 21:45, Richard Wang via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> Pwn2Own 2016: Chinese Researcher Hacks Google Chrome within 11 minutes
> http://www.prnewswire.com/news-releases/pwn2own-2016-chinese-researcher-hacks-google-chrome-within-11-minutes-300237705.html
> 
> 
> 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/dev-security-policy

360 team hacks Chrome

[Richard Wang via dev-security-policy]

Pwn2Own 2016: Chinese Researcher Hacks Google Chrome within 11 minutes
http://www.prnewswire.com/news-releases/pwn2own-2016-chinese-researcher-hacks-google-chrome-within-11-minutes-300237705.html


Best Regards,

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

RE: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Richard Wang via dev-security-policy]

Do you think this site is an authentic site from Microsoft?
If it is a fake site, then CA should revoke the issued certificate.

Best Regards,

Richard

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On
Behalf Of Matt Palmer via dev-security-policy
Sent: Friday, February 24, 2017 10:35 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Let's Encrypt appears to issue a certificate for a domain that
doesn't exist

On Fri, Feb 24, 2017 at 01:12:38AM +, Richard Wang via
dev-security-policy wrote:
> I am sure this site: https://www.microsoftonline.us.com/ is a phishing
site and a fake office 365 site that I wish LE can revoke this cert.

Why?  It works just fine over HTTP, too.

- Matt

___
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: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Richard Wang via dev-security-policy]

I am sure this site: https://www.microsoftonline.us.com/ is a phishing site and 
a fade office 365 site that I wish LE can revoke this cert.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Gervase Markham via dev-security-policy
Sent: Friday, February 24, 2017 2:13 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Let's Encrypt appears to issue a certificate for a domain that 
doesn't exist

On 22/02/17 17:08, Richard Wang wrote:
> I think "apple-id-2.com" is a high risk domain that must be blocked to issue 
> DV SSL to those domains.

I don't represent Let's Encrypt, but their policy on such things is relevant to 
this discussion, and it is here:
https://letsencrypt.org/2015/10/29/phishing-and-malware.html

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: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Richard Wang via dev-security-policy]

I don't agree this.
If "apple", "google", "Microsoft" is not a high risk domain, then I don’t know 
which domain is high risk domain, maybe only "github".

Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Thursday, February 23, 2017 11:53 AM
To: Richard Wang <rich...@wosign.com>
Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org; Tony 
Zhaocheng Tan <t...@tonytan.io>; Gervase Markham <g...@mozilla.org>
Subject: Re: Let's Encrypt appears to issue a certificate for a domain that 
doesn't exist

On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang via dev-security-policy 
<dev-security-policy@lists.mozilla.org> wrote:
> As I understand, the BR 4.2.1 required this:
>
> “The CA SHALL develop, maintain, and implement documented procedures that 
> identify and require additional verification activity for High Risk 
> Certificate Requests prior to the Certificate’s approval, as reasonably 
> necessary to ensure that such requests are properly verified under these 
> Requirements.”
>
> Please clarify this request, thanks.

Richard,

That sentence does not say that domain names including "apple", "google", or 
any other string are High Risk Certificate Requests
(HRCR).   I could define HRCR as being those that contain domain names
that contain mixed script characters as defined in UTS #39 section 5.1. 
"apple-id-2.com" is not mixed script so it is not a HRCR based on this 
definition.

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

RE: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Richard Wang via dev-security-policy]

Hi Ryan,



As I understand, the BR 4.2.1 required this:

“The CA SHALL develop, maintain, and implement documented procedures that 
identify and require additional verification activity for High Risk Certificate 
Requests prior to the Certificate’s approval, as reasonably necessary to ensure 
that such requests are properly verified under these Requirements.”



Please clarify this request, thanks.





Best Regards,



Richard



From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Thursday, February 23, 2017 11:21 AM
To: Richard Wang <rich...@wosign.com>
Cc: Gervase Markham <g...@mozilla.org>; Tony Zhaocheng Tan <t...@tonytan.io>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Let's Encrypt appears to issue a certificate for a domain that 
doesn't exist



Hi Richard,



There's no policies in the Baseline Requirements or Mozilla Requirements that 
normalize or define high risk domain, which I believe your suggestion 
presupposes.



Perhaps you (or Qihoo 360, as the voting member of the Forum of the 
Qihoo/WoSign/StartCom collection) would consider proposing a Ballot to the 
Baseline Requirements to address this. Alternatively, perhaps you would have a 
concrete suggestion for Mozilla Root CA Inclusion Policy 2.5 that might be able 
to address this in a consistent and auditable way and in a manner consistent 
with Mozilla's policy goals regarding misissuance.



This is https://github.com/mozilla/pkipolicy/issues/1 for what it's worth, 
recently resolved in Policy 2.4



On Wed, Feb 22, 2017 at 5:08 PM, Richard Wang via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

   I think "apple-id-2.com<http://apple-id-2.com>" is a high risk domain that 
must be blocked to issue DV SSL to those domains.

   Here is the list of some high risk domains related to Microsoft and Google 
that Let's Encrypt issued DV SSL certificates to those domains:
   https://crt.sh/?id=77034583  for 
microsoftonline.us.com<http://microsoftonline.us.com>, a fake Office 365 login 
site
   https://crt.sh/?id=71789336  for 
mail.google-androids.ru<http://mail.google-androids.ru>
   https://crt.sh/?id=82075006  for marketgoogle.xyz<http://marketgoogle.xyz>
   https://crt.sh/?id=65208905  for google.ligboy.org<http://google.ligboy.org>


   Best Regards,

   Richard


   -Original Message-
   From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard<mailto:dev-security-policy-bounces%2Brichard>=wosign@lists.mozilla.org<mailto:wosign@lists.mozilla.org>]
 On Behalf Of Gervase Markham via dev-security-policy
   Sent: Thursday, February 23, 2017 8:30 AM
   To: Tony Zhaocheng Tan <t...@tonytan.io<mailto:t...@tonytan.io>>; 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
   Subject: Re: Let's Encrypt appears to issue a certificate for a domain that 
doesn't exist

   On 22/02/17 14:42, Tony Zhaocheng Tan wrote:
   > On 2017-01-03, Let's Encrypt issued a certificate for 
apple-id-2.com<http://apple-id-2.com>.
   > However, until today, the domain apple-id-2.com<http://apple-id-2.com> has 
apparently never
   > been registered. How was the certificate issued?

   On Hacker News, Josh Aas writes:

   "Head of Let's Encrypt here. Our team is looking into this and so far we 
don't see any evidence of mis-issuance in our logs. It looks like the domain in 
question, 'apple-id-2.com<http://apple-id-2.com>', was registered and DNS 
resolved for it successfully at time of issuance. Here is the valid 
authorization record including the resolved IP addresses for 
'apple-id-2.com<http://apple-id-2.com>':

   https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl...

   We can't be sure why the reporter was unable to find a WHOIS record, we can 
only confirm that validation properly succeeded at time of issuance.

   Update: Squarespace has confirmed that they did register the domain and then 
released it after getting a certificate from us."

   There is currently an entry in WHOIS, because some well-meaning but 
unhelpful person registered it today. I assume that if a domain is registered 
and then released, and then re-registered, the "Creation"
   date is of the re-registration, not the first ever registration.

   So unless someone can show it was unregistered at the time of issuance, I 
don't see an issue here.

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

RE: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Richard Wang via dev-security-policy]

I think "apple-id-2.com" is a high risk domain that must be blocked to issue DV 
SSL to those domains.

Here is the list of some high risk domains related to Microsoft and Google that 
Let's Encrypt issued DV SSL certificates to those domains:
https://crt.sh/?id=77034583  for microsoftonline.us.com, a fake Office 365 
login site   
https://crt.sh/?id=71789336  for mail.google-androids.ru
https://crt.sh/?id=82075006  for marketgoogle.xyz
https://crt.sh/?id=65208905  for google.ligboy.org


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Gervase Markham via dev-security-policy
Sent: Thursday, February 23, 2017 8:30 AM
To: Tony Zhaocheng Tan ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Let's Encrypt appears to issue a certificate for a domain that 
doesn't exist

On 22/02/17 14:42, Tony Zhaocheng Tan wrote:
> On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com.
> However, until today, the domain apple-id-2.com has apparently never 
> been registered. How was the certificate issued?

On Hacker News, Josh Aas writes:

"Head of Let's Encrypt here. Our team is looking into this and so far we don't 
see any evidence of mis-issuance in our logs. It looks like the domain in 
question, 'apple-id-2.com', was registered and DNS resolved for it successfully 
at time of issuance. Here is the valid authorization record including the 
resolved IP addresses for 'apple-id-2.com':

https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl...

We can't be sure why the reporter was unable to find a WHOIS record, we can 
only confirm that validation properly succeeded at time of issuance.

Update: Squarespace has confirmed that they did register the domain and then 
released it after getting a certificate from us."

There is currently an entry in WHOIS, because some well-meaning but unhelpful 
person registered it today. I assume that if a domain is registered and then 
released, and then re-registered, the "Creation"
date is of the re-registration, not the first ever registration.

So unless someone can show it was unregistered at the time of issuance, I don't 
see an issue here.

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: SHA-1 serverAuth cert issued by Trustis in November 2016

[Richard Wang via dev-security-policy]

Check the SSL Labs test: 
https://www.ssllabs.com/ssltest/analyze.html?d=hmrcset.trustis.com, rate F that 
even enabled SSL v2.


Best Regards,

Richard

On 16 Feb 2017, at 19:04, Nick Lamb via dev-security-policy 
>
 wrote:

On Wednesday, 15 February 2017 22:02:50 UTC, Rob Stradling  wrote:
This currently unrevoked cert has a SHA-1/RSA signature, the serverAuth
EKU and CN=hmrcset.trustis.com:
https://crt.sh/?id=50773741=cablint

It lacks the SAN extension, but that doesn't excuse it from the ban on
SHA-1!

At time of writing this certificate is installed on a web server, although I 
think only to re-direct visitors to the plain HTTP site. Whether the CA 
believed it would be used on a web server or not, that's what was done.

https://hmrcset.trustis.com/

It's not clear to me whether this is a brochure site, and thus can just be 
upgraded or if it's actually part of the described HMRC SET system itself. 
Either way it's on the web.
___
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: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

[Richard Wang via dev-security-policy]

I think Mozilla should have a very clear policy for:
(1)  If a company that not a public trusted CA acquired a trusted root key, 
what the company must do?
(2)  If a company is a public trusted CA that acquired a trusted root key, what 
the company must do?
(3) If a company is a public trusted CA, but distrusted by Mozilla, this 
company acquired a trusted root key, what the company must do?

Thanks.

Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Peter Bowen via dev-security-policy
Sent: Friday, February 10, 2017 1:10 PM
To: Gervase Markham 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Public disclosure of root ownership transfers (was: Re: Google 
Trust Services roots)

On Thu, Feb 9, 2017 at 7:41 AM, Gervase Markham via dev-security-policy 
 wrote:
> On 09/02/17 14:32, Gijs Kruitbosch wrote:
>> Would Mozilla's root program consider changing this requirement so 
>> that it *does* require public disclosure, or are there convincing 
>> reasons not to? At first glance, it seems like 'guiding' CAs towards 
>> additional transparency in the CA market/industry/... might be 
>> helpful to people outside Mozilla's root program itself.
>
> This would require CAs and companies to disclose major product plans 
> publicly well in advance of the time they would normally disclose them.
> I won't dig out the dates myself, or check the emails, but if you look 
> for the following dates from publicly-available information:
>
> A) The date Google took control of the GlobalSign roots
> B) The date Google publicly announced GTS
>
> you will see there's quite a big delta. If you assume Google told 
> Mozilla about event A) before it happened, then you can see the problem.

Google says they took control on 11 August 2016.

On 19 October 2016, Google publicly stated "Update on the Google PKI:
new roots were generated and web trust audits were performed, the report on 
this is forthcoming,"
(https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Google)

Google didn't file with Mozilla until 22 December 2016, and I suspect that was 
only because I happened to run across their staged website:
https://twitter.com/pzb/status/812103974220222465

I appreciate the business realities of pre-disclosure, but that is not the case 
here.  There is no excuse for having taken control of existing roots and not 
disclosing such once they disclosed that they are intending to become a root CA.

Thanks,
Peter
___
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: Google Trust Services roots

[Richard Wang via dev-security-policy]

I can't see this sentence
 " I highlight this because we (the community) see the occasional remark like 
this; most commonly, it's directed at organizations in particular countries, on 
the basis that we shouldn't trust "them" because they're in one of "those 
countries". However, the Mozilla policy is structured to provide objective 
criteria and assessments of that."
has any relationship with this topic, please advise, thanks.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Friday, February 10, 2017 12:43 PM
To: Jakob Bohm 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Google Trust Services roots

On Thu, Feb 9, 2017 at 3:39 PM, Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:
>
> Additional issue #2: The information at https://pki.goog/ about how to
> report misissuance directs visitors to a generic reporting page for
> code vulnerabilities, which (by their nature) tends to require
> reaction times measured in days/weeks rather than the 1 day maximum
> specified in Google's CPS.
>

(To be clear, I am responding only as an individual, neither as Mozilla peer or 
Google employee, although I recognize you will likely disregard my remarks 
regardless.)

In the past, such comments have generally been seen as offtopic/accusatory, 
because they are inherently absent of evidence of any malfeasance. Indeed, your 
very comment seems to suggest that Google is not adhering to its CP/CPS, but 
without evidence, and such implication comes not based on any action that 
Google has taken, but based on your view of what 'others' do or the 'class' of 
bugs.

I highlight this because we (the community) see the occasional remark like 
this; most commonly, it's directed at organizations in particular countries, on 
the basis that we shouldn't trust "them" because they're in one of "those 
countries". However, the Mozilla policy is structured to provide objective 
criteria and assessments of that.

In this case, I do not believe you are being accurate or fair to present it as 
an "issue"; you are implying that Google will not adhere to its CP/CPS, but 
without evidence. The nature of incident reporting via this method may indeed 
be risky, but it's neither forbidden nor intrinsically wrong. If you look at 
many members in the Mozilla program, you will see far less specificity as to a 
problem report and the acceptable means of reporting this.

So while it's useful for you to draw attention to this, it's without evidence 
or basis for you to suggest that this is an "issue", per se - that is, it 
seemingly in no way conflicts with Mozilla policy or industry practice.
___
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: Incident Report – Certificates issued without proper domain validation

[Richard Wang]

The nest.com certificate subject is:
CN = www.nest.com
O = Google Inc
L = Mountain View
S = California
C = US

This means this website owned by Google Inc. Right?


Best Regards,

Richard

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On
Behalf Of Yuhong Bao
Sent: Thursday, January 12, 2017 6:12 AM
To: Wayne Thayer ;
dev-security-policy@lists.mozilla.org; Ryan Sleevi 
Subject: Re: Incident Report - Certificates issued without proper domain
validation

I wonder if nest.com is now considered high-risk now. They recently switched
from GoDaddy to Google Internet Authority.

From: dev-security-policy
 on
behalf of Wayne Thayer 
Sent: Tuesday, January 10, 2017 7:02:28 PM
To: dev-security-policy@lists.mozilla.org
Subject: Incident Report - Certificates issued without proper domain
validation

Summary:
On Friday, January 6th, 2017, GoDaddy became aware of a bug affecting our
domain validation processing system. The bug that caused the issue was fixed
late Friday. At 10 PM PST on Monday, Jan 9th we completed our review to
determine the scope of the problem, and identified 8850 certificates that
were issued without proper domain validation as a result of the bug. The
impacted certificates will be revoked by 10 PM PST on Tuesday, Jan 10th, and
will also be logged to the Google Pilot CT log.
Detailed Description:
On Tuesday, Jan 3rd, 2017, one of our resellers (Microsoft) sent an email to
n...@godaddy.com and two GoDaddy employees. Due to
holiday vacations and the fact that the issue was not reported properly per
our CPS, we did not become aware of the issue until one of the employees
opened the email on Friday Jan 6th and promptly alerted management. The
issue was originally reported to Microsoft by one of their own customers and
was described as only affecting certificate requests when the DNS A record
of the domain was set to 127.0.0.1. An investigation was initiated
immediately and within a few hours we determined that the problem was
broader in scope. The root cause of the problem was fixed via a code change
at approximately 10 PM MST on Friday, Jan 6th.
On Saturday, January 7th, we determined that the bug was first introduced on
July 29th, 2016 as part of a routine code change intended to improve our
certificate issuance process. The bug is related to our use of practical
demonstration of control to validate authority to receive a certificate for
a given fully-qualified domain name. In the problematic case, we provide a
random code to a customer and ask them to place it in a specific location on
their website. Our system automatically checks for the presence of that code
via an HTTP and/or HTTPS request to the website. If the code is found, the
domain control check is completed successfully.  Prior to the bug, the
library used to query the website and check for the code was configured to
return a failure if the HTTP status code was not 200 (success). A
configuration change to the library caused it to return results even when
the HTTP status code was not 200. Since many web servers are configured to
include the URL of the req  uest in the body of a 404 (not found) response,
and the URL also contained the random code, any web server configured this
way caused domain control verification to complete successfully.
We are currently unaware of any malicious exploitation of this bug to
procure a certificate for a domain that was not authorized. The customer who
discovered the bug revoked the certificate they obtained, and subsequent
certificates issued as the result of requests used for testing by Microsoft
and GoDaddy have been revoked. Further, any certificate requests made for
domains we flag as high-risk were also subjected to manual review (rather
than being issued purely based on an invalid domain authorization).
We have re-verified domain control on every certificate issued using this
method of validation in the period from when the bug was introduced until it
was fixed. A list of 8850 potentially unverified certificates (representing
less than 2% of the total issued during the period) was compiled at 10 PM
PST on Monday Jan 9th. As mentioned above, potentially impacted certificates
will be revoked by 10 PM PST on Tuesday Jan 10th and logged to a Google CT
log. Additional code changes were deployed on Monday Jan 9th and Tuesday
10th to prevent the re-issuance of certificates using cached and potentially
unverified domain validation information. However, prior to identifying and
shutting down this path, an additional 101 certificates were reissued using
such cached and potentially unverified domain validation information,
resulting in an overall total of 8951 certificates that were issued without
proper domain validation as a result of the 

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

[Richard Wang]

In this case, no any CA named as letsencrypt similar name, and no any CA want
to impersonate, most CA program require the root CA have a unique friendly
name in the CA program.


Best Regards,

Richard

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On
Behalf Of Tom Delmas
Sent: Thursday, December 22, 2016 10:30 PM
To: Gervase Markham 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: wosign and letsencrypt.cn / letsencrypt.com.cn

Hi Gerv,

> It's never come up. But I think we would be reluctant to intervene;
Thank you for that answer. I understand it.

> there are other mechanisms for sorting out such disputes, and it's not
> our job to interpret or enforce trademark law or domain name dispute
> resolution law.

There are other mechanisms. But hard to use, especially between countries. As
a Firefox user, I expect that CA trusted by Firefox are clearly identifiable
and distinguishable from each others.

We need CA to avoid website impersonation. In order to achieve that, I feel
that "CA impersonation" must be avoided before all.

And the logical way to do it in my opinion is in the Mozilla CA Certificate
Policy.

Tom
___
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 letsencrypt.cn / letsencrypt.com.cn

[Richard Wang]

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/dev-security-policy

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

[Richard Wang]

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

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of tdel...@gmail.com
Sent: Saturday, December 17, 2016 1:34 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: wosign and letsencrypt.cn / letsencrypt.com.cn

It seams that wosign has registered the domains letsencrypt.cn and 
letsencrypt.com.cn in 2014 after the public announce of Let's Encrypt :

whois letsencrypt.cn
Domain Name: letsencrypt.cn
ROID: 20141120s10001s72911711-cn
Domain Status: clientTransferProhibited
Registrant ID: k35-n2041486_00
Registrant: 深圳市沃通电子商务服务有限公司
Registrant Contact Email: d...@wosign.com Sponsoring Registrar: 厦门三五互联科技股份有限公司
Name Server: ns3.dns-diy.com
Name Server: ns4.dns-diy.com
Registration Time: 2014-11-20 09:57:27
Expiration Time: 2017-11-20 09:57:27
DNSSEC: unsigned

whois letsencrypt.com.cn
Domain Name: letsencrypt.com.cn
ROID: 20141120s10011s84227837-cn
Domain Status: clientTransferProhibited
Registrant ID: k35-n2041486_00
Registrant: 深圳市沃通电子商务服务有限公司
Registrant Contact Email: d...@wosign.com Sponsoring Registrar: 厦门三五互联科技股份有限公司
Name Server: ns3.dns-diy.com
Name Server: ns4.dns-diy.com
Registration Time: 2014-11-20 09:57:28
Expiration Time: 2017-11-20 09:57:28

Let's Encrypt was announced publicly on November 18, 2014 ( 
http://www.crn.com/news/cloud/300074840/lets-encrypt-a-free-and-automated-certificate-authority-comes-out-of-stealth-mode.htm
 ). That domain appear to be registered two days after.

Certificate authorities are about trust. I don't feel comfortable about a CA 
registering a domain matching the name of another CA. What is the position of 
Mozilla about that?
Maybe Let's Encrypt or wosign have more information about these domains?

https://community.letsencrypt.org/t/letsencrypt-cn-and-letsencrypt-com-cn-was-registered-by-wosign/23786

Other relevant thread: Comodo Legal Phishing attack against ISRG?
https://groups.google.com/d/msg/mozilla.dev.security.policy/n-8kcrSuhjg/WKj-PAI2BgAJ
___
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: CA Public Key Material

[Richard Wang]

You are right, you have done the test same as my test, this don't mean you own 
our intermediate CA root key.

For CSR, yes, our system doesn't validate the CSR self-signature. We think it 
is better to validate it, so we will update our system to validate it soon.

For this test certificate revocation time, yes, it is same as the issuance time.
Our PKI system can let the Revocation Office to choose the revocation time: (1) 
same as the issuance time; (2) the current time. Option (1) is designed for 
invaliding the malware signing code signing certificate instantly if the 
malware signed with timestamp. If we revoke the malware signing code signing 
certificate using Option (2) (the current time), then the signed malware with 
timestamp is still valid even the certificate is revoked. Sure, we can use 
Option (1) to revoke SSL certificate like my test certificate to let nobody 
have the chance to use this test certificate.

Thank you.

Best Regards,

Richard

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On
Behalf Of Andrew Ayer
Sent: Friday, December 16, 2016 12:33 AM
To: Tavis Ormandy 
Cc: dev-security-policy@lists.mozilla.org
Subject: Re: CA Public Key Material

On Wed, 14 Dec 2016 18:46:31 -0800
Tavis Ormandy  wrote:

> Hello, while working on an unrelated problem, I happened to notice
> that this  leaf certificate for
> DNS:test.wgh.cn and DNS: test.ydn.cn has the same RSA public key as
> this trusted root  (and a few others).
>
> test.wgh.cn no longer resolves, but wgh.cn is the personal blog of a
> WoSign employee.

Do you know if test.wgh.cn ever resolved?

> Is it possible key material was accidentally used in a web server and
> removed from a HSM? Maybe there's another explanation, but if there
> was an accident, I assume the root would need to be revoked.

I was just able to obtain the below certificate
(https://crt.sh/?sha256=9d28d7861ef9a0750f7bb95ee9c765d2610fab41fdd7f2142986
d2e8f2a0c7da)
from StartCom for this public key.  StartCom evidently does not validate the
CSR self-signature, and I suspect WoSign didn't either, since they shared so
much code and infrastructure.  (StartCom appears to still share
infrastructure - the validation email for this certificate originated from a
Chinese IP address.)  Validating the CSR self-signature is not required by
the BRs or Mozilla policy.

This is probably more likely than the CA private key being used for a server
cert, although this is WoSign, so who knows?

Regards,
Andrew


___
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: In September 29, 2016, WoSign stop issuing free certificate, but I still successfully get it.

[Richard Wang]

Thanks for your advice.
As I said, we closed it completely in PKI side.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Percy
Sent: Tuesday, December 13, 2016 3:40 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: In September 29, 2016, WoSign stop issuing free certificate, but I 
still successfully get it.

If you made a promise to close it "due to some security consideration", then 
you don't have the right to just enable and disable it at will, or disable it 
at one channel but not another channel, which ultimately has the same security 
if WoSign is doing the validation.

On Sunday, December 11, 2016 at 12:27:46 AM UTC-8, Richard Wang wrote:
> As I said, we have the right to keep it or close it at any time.
>
>
> Best Regards,
>
> Richard
>
> > On 11 Dec 2016, at 12:47, Percy <percyal...@gmail.com> wrote:
> >
> >> On Saturday, December 10, 2016 at 8:29:29 PM UTC-8, Richard Wang wrote:
> >> Our promise is close the free SSL application in our own website: 
> >> buy.wosign.com.
> >>
> >> And now we closed it in our PKI side.
> >>
> >>
> >> Best Regards,
> >>
> >> Richard
> >>
> >>>> On 9 Dec 2016, at 04:17, Gervase Markham <g...@mozilla.org> wrote:
> >>>>
> >>>> On 05/12/16 13:41, Richard Wang wrote:
> >>>> We checked our system, this order is from one of the reseller. We
> >>>> have many resellers that used the API, we noticed all resellers
> >>>> to close the free SSL, but they need some time to update the system.
> >>>
> >>> More than two months?
> >>>
> >>> Has this reseller given a timeline by which they expect to have
> >>> ceased to use the API?
> >>>
> >>>> The
> >>>> most important thing is this certificate is issued by proper way
> >>>> that this subscriber finished the domain validation, so this is
> >>>> not a mis-issuance, not "deceiving".
> >>>
> >>> This is narrowly true, from a Mozilla perspective. Mozilla has not
> >>> required that WoSign stop issuing certificates. We have just said
> >>> that we no longer trust them. Of course, I don't know what
> >>> commitments WoSign has made to other root stores. And indeed,
> >>> no-one has suggested that this certificate is mis-issued from a domain 
> >>> validation perspective.
> >>>
> >>> There is an issue relating to the difference between WoSign's
> >>> public statement on their website that they have ceased free SSL
> >>> issuance, and the reality that they have not. We expect CAs who
> >>> make public statements about their actions to abide by those statements.
> >>>
> >>> Gerv
> > Sorry. You just said there is no deadline? Which is it?
> >
> > -
> >
> > Sorry, we don't have deadline.
> > And no plan to close it in PKI side, we keep the right to active it at any 
> > time, and we can issue this free SSL certificate for subscribers at any 
> > time if customers need it.
> >
> > ___
> > 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: In September 29, 2016, WoSign stop issuing free certificate, but I still successfully get it.

[Richard Wang]

As I said, we have the right to keep it or close it at any time.


Best Regards,

Richard

> On 11 Dec 2016, at 12:47, Percy <percyal...@gmail.com> wrote:
> 
>> On Saturday, December 10, 2016 at 8:29:29 PM UTC-8, Richard Wang wrote:
>> Our promise is close the free SSL application in our own website: 
>> buy.wosign.com.
>> 
>> And now we closed it in our PKI side.
>> 
>> 
>> Best Regards,
>> 
>> Richard
>> 
>>>> On 9 Dec 2016, at 04:17, Gervase Markham <g...@mozilla.org> wrote:
>>>> 
>>>> On 05/12/16 13:41, Richard Wang wrote:
>>>> We checked our system, this order is from one of the reseller. We
>>>> have many resellers that used the API, we noticed all resellers to
>>>> close the free SSL, but they need some time to update the system. 
>>> 
>>> More than two months?
>>> 
>>> Has this reseller given a timeline by which they expect to have ceased
>>> to use the API?
>>> 
>>>> The
>>>> most important thing is this certificate is issued by proper way that
>>>> this subscriber finished the domain validation, so this is not a
>>>> mis-issuance, not "deceiving".
>>> 
>>> This is narrowly true, from a Mozilla perspective. Mozilla has not
>>> required that WoSign stop issuing certificates. We have just said that
>>> we no longer trust them. Of course, I don't know what commitments WoSign
>>> has made to other root stores. And indeed, no-one has suggested that
>>> this certificate is mis-issued from a domain validation perspective.
>>> 
>>> There is an issue relating to the difference between WoSign's public
>>> statement on their website that they have ceased free SSL issuance, and
>>> the reality that they have not. We expect CAs who make public statements
>>> about their actions to abide by those statements.
>>> 
>>> Gerv
> Sorry. You just said there is no deadline? Which is it? 
> 
> -
> 
> Sorry, we don't have deadline. 
> And no plan to close it in PKI side, we keep the right to active it at any 
> time, and we can issue this free SSL certificate for subscribers at any time 
> if customers need it. 
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: In September 29, 2016, WoSign stop issuing free certificate, but I still successfully get it.

[Richard Wang]

Our promise is close the free SSL application in our own website: 
buy.wosign.com.

And now we closed it in our PKI side.


Best Regards,

Richard

> On 9 Dec 2016, at 04:17, Gervase Markham <g...@mozilla.org> wrote:
> 
>> On 05/12/16 13:41, Richard Wang wrote:
>> We checked our system, this order is from one of the reseller. We
>> have many resellers that used the API, we noticed all resellers to
>> close the free SSL, but they need some time to update the system. 
> 
> More than two months?
> 
> Has this reseller given a timeline by which they expect to have ceased
> to use the API?
> 
>> The
>> most important thing is this certificate is issued by proper way that
>> this subscriber finished the domain validation, so this is not a
>> mis-issuance, not "deceiving".
> 
> This is narrowly true, from a Mozilla perspective. Mozilla has not
> required that WoSign stop issuing certificates. We have just said that
> we no longer trust them. Of course, I don't know what commitments WoSign
> has made to other root stores. And indeed, no-one has suggested that
> this certificate is mis-issued from a domain validation perspective.
> 
> There is an issue relating to the difference between WoSign's public
> statement on their website that they have ceased free SSL issuance, and
> the reality that they have not. We expect CAs who make public statements
> about their actions to abide by those statements.
> 
> Gerv


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: In September 29, 2016, WoSign stop issuing free certificate, but I still successfully get it.

[Richard Wang]

As I said before, you finished the domain validation.
This is DV SSL that no need to do the manual validation.

Best Regards,

Richard

> On 10 Dec 2016, at 09:33, "zbw...@gmail.com"  wrote:
> 
> 在 2016年12月6日星期二 UTC+8上午6:50:04，Percy写道：
>> lslqtz,
>> How did you obtain this certificate from WoSign? Through the public website 
>> or some other means?
> 
> I get this certificate through the dealer's website, but the dealer and 
> WoSign API are not doing the verification, the final manual audit also passed.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: In September 29, 2016, WoSign stop issuing free certificate, but I still successfully get it.

[Richard Wang]

Sorry, we don't have deadline. 
And no plan to close it in PKI side, we keep the right to active it at any 
time, and we can issue this free SSL certificate for subscribers at any time if 
customers need it.

Best Regards,

Richard

> On 6 Dec 2016, at 07:49, Percy <percyal...@gmail.com> wrote:
> 
> When I was trying to inform Apple to put a time constrain on the intermediate 
> CA, you implied such constrain not necessary because no new certs will be 
> issued. Clearly, you know already that the users can still get certs from 
> reseller and potentially abuse it due to all the control failures 
> investigated by Mozilla. Otherwise, you could have closed the issuing certs 
> in the PKI, and no resellers would be able to issue new certs. 
> 
> Since new certs are still issued by WoSign, could you please give a timeline 
> on when such no new certs will be issued, via wosign, resellers, no any other 
> method? 
> 
>> On Monday, December 5, 2016 at 3:43:35 PM UTC-8, Richard Wang wrote:
>> We checked our system, this order is from one of the reseller. We have many 
>> resellers that used the API, we noticed all resellers to close the free SSL, 
>> but they need some time to update the system.
>> The most important thing is this certificate is issued by proper way that 
>> this subscriber finished the domain validation, so this is not a 
>> mis-issuance, not "deceiving".
>> 
>> Best Regards,
>> 
>> Richard
>> 
>>> On 6 Dec 2016, at 06:57, Percy <percyal...@gmail.com> wrote:
>>> 
>>> WoSign is actively deceiving this community again. 
>>> 
>>> In Nov. 13th, in the thread Apple's response to the WoSign incidents, I 
>>> stated that "CA 沃通免费SSL证书 G2", the intermediate CA of this certificate 
>>> should be time constrained by Apple. But Richard stated that "WoSign 
>>> stopped to issue free SSL certificate from those two intermediate CAs since 
>>> Sept 29. " 
>>> (https://groups.google.com/d/msg/mozilla.dev.security.policy/lWJ1zdUJPLI/z1sxa6WRCAAJ)
>>> 
>>> I'm asking WoSign please explain why on the public website and on this 
>>> forum, you stated no new certs will be issued under this very intermediate 
>>> CA, but now you said this is not a issue?
>>> ___
>>> 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: In September 29, 2016, WoSign stop issuing free certificate, but I still successfully get it.

[Richard Wang]

We checked our system, this order is from one of the reseller. We have many 
resellers that used the API, we noticed all resellers to close the free SSL, 
but they need some time to update the system.
The most important thing is this certificate is issued by proper way that this 
subscriber finished the domain validation, so this is not a mis-issuance, not 
"deceiving".

Best Regards,

Richard

> On 6 Dec 2016, at 06:57, Percy  wrote:
> 
> WoSign is actively deceiving this community again. 
> 
> In Nov. 13th, in the thread Apple's response to the WoSign incidents, I 
> stated that "CA 沃通免费SSL证书 G2", the intermediate CA of this certificate should 
> be time constrained by Apple. But Richard stated that "WoSign stopped to 
> issue free SSL certificate from those two intermediate CAs since Sept 29. " 
> (https://groups.google.com/d/msg/mozilla.dev.security.policy/lWJ1zdUJPLI/z1sxa6WRCAAJ)
> 
> I'm asking WoSign please explain why on the public website and on this forum, 
> you stated no new certs will be issued under this very intermediate CA, but 
> now you said this is not a issue?
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: WoSign has new roots?

[Richard Wang]

This is a common way for all CAs that issued many intermediate CAs for its 
resellers.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Ryan Sleevi
Sent: Wednesday, November 23, 2016 7:35 AM
To: Patrick Figel 
Cc: Tobias Sachs ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: WoSign has new roots?

On Tue, Nov 22, 2016 at 3:30 PM, Patrick Figel  wrote:
> I'm a bit unclear on whether WoSign could be acting as a Registration 
> Authority for certificates issued under that intermediate and what the 
> auditing and disclose requirements for that would be - maybe someone 
> more familiar with the BRs can comment. WoSign acting as a RA prior to 
> finishing the re-application process would be troubling given their previous 
> failures in that area.

Whether or not it's intentional, as practiced by auditors today, it's an open 
field with vastly inconsistent standards or expectations as to whether they are 
scoped in the audit.
___
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 has new roots?

[Richard Wang]

Hi all,

This is the OEM certificate from Certum, Certum own and control everything with 
its own validation, you can check the test site: https://ovpretest.wosign.com 
that its CPS/CRL/OCSP/OID all belong to Certum.

I don't think WoSign can't be a reseller of other CA.

Thanks. 


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Patrick Figel
Sent: Wednesday, November 23, 2016 7:30 AM
To: Tobias Sachs 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: WoSign has new roots?

On Tue, Nov 22, 2016 at 10:56 PM, Tobias Sachs  wrote:
> Am Dienstag, 22. November 2016 21:37:08 UTC+1 schrieb Lewis Resmond:
>> Hello,
>>
>> I just noticed following announcement by WoSign:
>>
>> https://www.wosign.com/english/News/certificate_pre.htm
>>
>> If I understand correctly, they now have new root certificates which chain 
>> up to Certum, which is in the root storage.
>>
>> What does that mean in particular? Are the previously taken sanctions now 
>> useless?
>
> According to this comment [1] I think yes. But this means also that the new 
> ca is now the target. You can find the cert mentioned there here [2] and the 
> intermediate here [3] which is not in the CT logs...

The intermediate certificates were disclosed in Mozilla's CA database[1] and 
are currently filed under "CP/CPS Same As Parent" and "Audits Same As Parent".

I assume that this means Certum holds the keys for these intermediates and 
WoSign is essentially acting as a reseller. I don't think that's something 
Mozilla can or should object to.

I'm a bit unclear on whether WoSign could be acting as a Registration Authority 
for certificates issued under that intermediate and what the auditing and 
disclose requirements for that would be - maybe someone more familiar with the 
BRs can comment. WoSign acting as a RA prior to finishing the re-application 
process would be troubling given their previous failures in that area.

[1]: https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCerts
___
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

[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

Re: Apple's response to the WoSign incidents

[Richard Wang]

WoSign stopped to issue free SSL certificate from those two intermediate CAs 
since Sept 29.


Best Regards,

Richard

> On 13 Nov 2016, at 17:07, Percy  wrote:
> 
> I just found out that Apple doesn't limit "CA 沃通免费SSL证书 G2" intermediate CA 
> even though Apple limited "WoSign CA Free SSL Certificate G2" intermediate 
> CA. An example of site signed by"CA 沃通免费SSL证书 G2" intermediate CA  is 
> https://www.chelenet.com/
> 
> Those two intermediate certs are treated by WoSign the same way and the 
> translation of  "CA 沃通免费SSL证书 G2" is "WoSign CA Free SSL Certificate G2". 
> Users can select whether the end cert is signed by "CA 沃通免费SSL证书 G2" or 
> "WoSign CA Free SSL Certificate G2". All control measures are the same and 
> the only difference is the language for marketing reasons. 
> 
> Hence, because Apple has chose to blocked "WoSign CA Free SSL Certificate 
> G2", it makes sense to apply the same sanction on "CA 沃通免费SSL证书 G2", as 
> they're in all senses the same.
> ___
> 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: Remediation Plan for WoSign and StartCom

[Richard Wang]

For Q1:  This is a OEM SSL from other trusted CA;
For Q2:  We stopped the free SSL certificate after Apple announcement, it is 
announced in our free SSL website;
For Q3:  I am the Acting CEO now till the new CEO arrives.


Best Regards,

Richard

From: Eric Mill [mailto:e...@konklone.com]
Sent: Monday, October 24, 2016 12:05 PM
To: Richard Wang <rich...@wosign.com>
Cc: Kathleen Wilson <kwil...@mozilla.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Remediation Plan for WoSign and StartCom

Hi Richard,

A few questions -

1) Your post says "There will be new SSL certificates issued by a new WoSign 
intermediate CA which is signed by the one of global trusted root CA, it 
supports all the browsers (including Firefox). This will be done within one 
months."

How will this WoSign intermediate CA be different from the 4 affected roots? 
Will it use the same WoSign issuance infrastructure used by the 4 roots that 
Mozilla has decided to distrust?

2) Your announcement to customers only discusses Mozilla's action. Are you 
planning to inform customers of how Apple's decision to distrust WoSign's roots 
will affect WoSign operations?

3) A previous Qihoo 360 document said that you are being removed as WoSign CEO. 
Are you still authorized by Qihoo 360 to make announcements like this?

-- Eric

On Sun, Oct 23, 2016 at 10:46 PM, Richard Wang 
<rich...@wosign.com<mailto:rich...@wosign.com>> wrote:
Hi Kathleen,

WoSign released the news today since I just came back from USA CABF meeting.

http://www.wosign.com/news/announcement_about_Mozilla_Action_20161024.htm (in 
Chinese)

https://www.wosign.com/english/News/announcement_about_Mozilla_Action_20161024.htm
  (in English)



Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard<mailto:dev-security-policy-bounces%2Brichard>=wosign@lists.mozilla.org<mailto:wosign@lists.mozilla.org>]
 On Behalf Of Kathleen Wilson
Sent: Friday, October 21, 2016 10:43 AM
To: 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: Remediation Plan for WoSign and StartCom

On Thursday, October 20, 2016 at 6:59:08 PM UTC-7, Percy wrote:
> Kathleen,
> As most users affected by this decision are Chinese, will you be able to make 
> the blog post available in Chinese on the security blog as well? You can ask 
> the Chinese firefox community or me to translate.
>
> As I stated earlier, there are almost no news of the distrust of 
> WoSign/StartCom on the Chinese Internet and WoSign/StartCom has not posted 
> anything related to this. I believe it's paramount to prepare Chinese website 
> owners for the phasing out of the affected roots.

Noted. I will look into how to get it translated into Chinese and how to make 
that version available as well.

Thanks,
Kathleen

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



--
konklone.com<https://konklone.com> | @konklone<https://twitter.com/konklone>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Remediation Plan for WoSign and StartCom

[Richard Wang]

Hi Kathleen,

WoSign released the news today since I just came back from USA CABF meeting.

http://www.wosign.com/news/announcement_about_Mozilla_Action_20161024.htm (in 
Chinese)

https://www.wosign.com/english/News/announcement_about_Mozilla_Action_20161024.htm
  (in English)



Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Kathleen Wilson
Sent: Friday, October 21, 2016 10:43 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Remediation Plan for WoSign and StartCom

On Thursday, October 20, 2016 at 6:59:08 PM UTC-7, Percy wrote:
> Kathleen,
> As most users affected by this decision are Chinese, will you be able to make 
> the blog post available in Chinese on the security blog as well? You can ask 
> the Chinese firefox community or me to translate. 
> 
> As I stated earlier, there are almost no news of the distrust of 
> WoSign/StartCom on the Chinese Internet and WoSign/StartCom has not posted 
> anything related to this. I believe it's paramount to prepare Chinese website 
> owners for the phasing out of the affected roots.

Noted. I will look into how to get it translated into Chinese and how to make 
that version available as well.

Thanks,
Kathleen

___
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

[Richard Wang]

Hi Gerv,

This is the updated incident report: 
https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf .


Thanks. 


Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Gervase Markham
Sent: Wednesday, October 5, 2016 12:25 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: WoSign and StartCom: next steps

On 29/09/16 16:40, Gervase Markham wrote:
> 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.

This meeting happened today; thank you to representatives of Qihoo 360, 
StartCom and WoSign who travelled great distances to come. I'm happy that 
Mozilla was able to successfully communicate what we hoped to see from these 
companies, and expect to see a proposed plan from them very shortly.

Once that plan is published, we will be able to discuss whether the steps 
contained in it should lead to Mozilla changing our proposal for the measures 
we intend to 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

RE: Comodo issued a certificate for an extension

[Richard Wang]

I think I know the reason; this may be helpful for your investigation.

This is a code bug from CA issuing system that the engineer mis-understand the 
free additional domain added rule. System treat the "www" as a subdomain, most 
case it is, but in this case, it is top domain. 
Subscriber finished the domain validation for domain "www.sb", then the issuing 
system using the rule "if the domain is validated, and if the cert request is 
for www.domain.com, then add its top domain - domain.com to the certificate 
automatically", then the signing system added the domain ".sb" as its top 
domain to the certificate. This rule is ok for more case, but for this case, it 
is wrong.

There is another bug that it means Comodo don't have the gTLD blocking system 
that according to the BR, CA can't issue the gTLD domain to subscriber. 

And the excuse of "don’t know this new gTLD" is not a good reason that there 
are many new gTLDs come out very frequently, system can NOT issue the gTLD name 
for subscribers, system must block any known or unknown gTLD in the 
certificate. And this domain - "www.sb" is passed the domain validation, it 
means Comodo system know this gTLD.

This is a BR violated misissuance, I don't know if any more certificates are 
mis-issued since it is a bug in the code that may affect other similar order. I 
recommend Comodo post all issued SSL certificate to CT log server for full 
transparency to let worldwide user to check if any more mis-issuance happened.  



Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Robin Alden
Sent: Monday, September 26, 2016 1:29 AM
To: 'Peter Bowen' ; 'Nick Lamb' 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Comodo issued a certificate for an extension

Hi All,
We did receive a direct report of the problem yesterday (24th 
September) from a Mozilla rep., thanks, and we undertook an investigation and 
remediation exercise yesterday.

The software problem which caused or allowed this certificate to be issued has 
been corrected.

That certificate (https://crt.sh/?id=34242572) was revoked yesterday morning.

We will issue a report tomorrow (26th September).

Regards
Robin Alden
Comodo



> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+robin=comodo@lists.mozilla.org] On Behalf Of Peter Bowen
> Sent: 25 September 2016 17:37
> To: Nick Lamb 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Comodo issued a certificate for an extension
> 
> On Sun, Sep 25, 2016 at 9:19 AM, Nick Lamb  wrote:
> > On Sunday, 25 September 2016 15:35:07 UTC+1, mono...@gmail.com
> wrote:
> >> am I the only one who a) thinks this is slightly problematic and b) 
> >> is
> surprised that the cert still isn't revoked?
> >
> > I don't know enough about the .sb ccTLD to be clear how problematic 
> > the
> described scenario is. I would certainly like to know more. Wikipedia 
> tells me that .sb is operated like .uk used to be, with registrant 
> domains appearing only as 3LDs e.g. you used to able to buy 
> example.co.uk but not example.uk, so that having control of example.sb 
> is itself exceptional, let alone www.sb
> 
> According to https://nic.net.sb/, which is linked from
> http://www.iana.org/domains/root/db/sb.html:
> 
> "Starting from February 12, 2016 Solomon Telekom Company Limited is 
> pleased to announce the extending of .sb domain space place by 
> allowing registrations directly at the ‘second-level’."
> 
> So it appears that the scenario is that someone (presumably the 
> reporter of this issue) registered www.sb., a second level domain 
> name, which would be in accordance with the described change.
> 
> > It is important to me - as a relying party - to know if there is a 
> > problem in
> Comodo's domain validation which allows people to obtain certificates 
> for names which they do not (or perhaps, depending how .sb is run, 
> even
> cannot) control. It is not terribly important to me in principle which 
> names are affected, but in practice the extent of the risk might 
> influence Mozilla's decision as to what if anything should be done, by them 
> or by Comodo.
> >
> > However right now it's the weekend, people who do this stuff as 
> > their day
> job, rather than an outside interest, may not have responded because 
> they're busy watching televised sports or baking cakes. I will grow 
> more concerned if there's no follow-up from anybody next week.
> 
> It is unclear if this has been reported to the CA (Comodo).  While 
> some CA operators do read this Mozilla forum, it is not an official 
> communication channel for any CA, as far as I know.  Any request to 
> revoke a certificate needs to be sent to the address specified by the 
> CA in their CPS.
> 
> Thanks,
> Peter
> 

Fwd: [cabfpub] Public disclosure of 68 GlobalSign SSL certificates issued without EKU or KU

[Richard Wang]

This is the recent incident from GlobalSign.

Please notice WoSign incident is occurred in 2015  for free DV SSL, not OV or 
EV.

Best Regards,

Richard

Begin forwarded message:

From: Doug Beattie 
>
Date: September 21, 2016 at 04:48:00 GMT+8
To: CABFPub >
Subject: [cabfpub] Public disclosure of 68 GlobalSign SSL certificates issued 
without EKU or KU


Following a recent code update to our GlobalSign Certificate Centre (GCC) 
platform, we have discovered a bug which manifests itself when orders are 
re-issued with modified domains within the Subject Alternative Name field of 
the certificate.  When users added or removed SANs in their OV or EV 
certificate between 29 August and 19 September the resulting certificates did 
not contain the Key Usage (KU) or Extended Keu Usage (EKU) extensions.  KU is 
optional according to the BRs, but EKU is mandatory.  All certificates 
contained Basic Constraints.
The issue was identified on Friday and the system patched Friday night.  
Customers in the western region were notified Friday afternoon and those in 
APAC and Japan on Monday and Tuesday (Monday was a holiday in Japan).  The 
support team was in contact with impacted customers Monday and Tuesday to 
follow up and recommend they reissue the certificate and revoke the one 
containing the issue.  Those that could not be contacted had their certificates 
revoked by the GlobalSIgn vetting team.
Currently, all but 1 certificate has been revoked.  The one remaining will be 
revoked with the next 24 hours and belongs to a high profile site in Japan who, 
due to the timing of the issue, needs another day.
We have verified that in total 68 certificates were affected.  4 of these are 
EV and 64 OV.   The risk to the community and to our other customers is 
therefore low as we have existing relationships with all customers and have 
vetted them to a higher level of confidence to issue the original certificate 
in the first place, although obviously the inconvenience on both sides is not 
welcome.
We’re putting new systems in place to parse issued certificates for compliance 
with the BRs which will catch any future certificate content issues more 
quickly.
For more information and the list of certificates, see the Mozilla bug filed 
earlier today: https://bugzilla.mozilla.org/show_bug.cgi?id=1304089
Regards,
Doug

___
Public mailing list
pub...@cabforum.org
https://cabforum.org/mailman/listinfo/public
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Comodo issued a certificate for an extension

[Richard Wang]

First, I must make declaration that I don't know "Showfom", and I don't know if 
he/she is a WoSign customer.

As I said in my final statement that I wish all Mozilla trusted CA can post 
their issued certificate to CT log server for full transparency, I am sure not 
WoSign mis-issued certificate only, maybe some CA have more serious problems.

I paste my statement again here:
WoSign believes that the Certificate Transparency is a very good solution for 
self-discipline that force employees to attach great importance to product 
quality control, and for external oversight mechanism that let the third party 
supervise the CA's activity. 
WoSign is the first CA that volunteer to post all issued SSL Certificates to 
Google CT log server initiatively. Our aim is to let the worldwide users trust 
WoSign SSL certificates, and hope to drive the global CAs to be open and 
transparent publishing all issued certificates to CT log server, making 
worldwide users, browser vendors and related stakeholder to take an overall 
supervision, this will benefit the global Internet security.


@Showfom: you don't need to say " Sorry for my bad English", your English is 
very good! Our native language is Chinese, not English, so no need to say 
sorry, I NEVER say this word again.


Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Showfom
Sent: Saturday, September 24, 2016 2:30 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Comodo issued a certificate for an extension

First, let me introduce myself, I'm a famous investor of ccTLD domains from 
China.

Recently we get an easy-remember domain www.sb, please note the extension is .sb

I ordered a Comodo Positive SSL for this domain, the common name which I submit 
is www.sb

Usually they will give us a certificate for www.sb and www.www.sb, but this 
time Comodo issues a certificate with DNS name www.sb and sb

I can't find our certificate in crt.sh but can be viewed here

https://censys.io/certificates/719c282a51e935051e88bf6115dda0731da21c0e12c08e6bcea36078e83e4966

Or you can simply type https://www.sb/ in your browser to view the certificate

https://www.sb/uploads/images/201609/24/181/n9k4qfbVYj.png

I also tried to make an nginx conf in my server for https://sb/ you can change 
your /etc/hosts or just use curl commmand

curl -v -H "Host: sb" https://www.sb/

You can find 403 Forbidden in title without any SSL certificate error because I 
set the return status for https://sb/ to 403

Sorry for my bad English

Best Regards,
@Showfom
___
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: Comodo issued a certificate for an extension

[Richard Wang]

First, I must make declaration that I don't know "Showfom", and I don't know if 
he/she is a WoSign customer.

As I said in my final statement that I wish all Mozilla trusted CA can post 
their issued certificate to CT log server for full trenchancy, I am sure not 
WoSign mis-issued certificate, maybe some CA have more serious problems..

I paste my statement again here:
WoSign believes that the Certificate Transparency is a very good solution for 
self-discipline that force employees to attach great importance to product 
quality control, and for external oversight mechanism that let the third party 
supervise the CA's activity. 
WoSign is the first CA that volunteer to post all issued SSL Certificates to 
Google CT log server initiatively. Our aim is to let the worldwide users trust 
WoSign SSL certificates, and hope to drive the global CAs to be open and 
transparent publishing all issued certificates to CT log server, making 
worldwide users, browser vendors and related stakeholder to take an overall 
supervision, this will benefit the global Internet security.


@Showfom: you don't need to say " Sorry for my bad English", your English is 
very good! Our native language is Chinese, not English, so no need to say 
sorry, I NEVER say this word again.


Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Showfom
Sent: Saturday, September 24, 2016 2:30 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Comodo issued a certificate for an extension

First, let me introduce myself, I'm a famous investor of ccTLD domains from 
China.

Recently we get an easy-remember domain www.sb, please note the extension is .sb

I ordered a Comodo Positive SSL for this domain, the common name which I submit 
is www.sb

Usually they will give us a certificate for www.sb and www.www.sb, but this 
time Comodo issues a certificate with DNS name www.sb and sb

I can't find our certificate in crt.sh but can be viewed here

https://censys.io/certificates/719c282a51e935051e88bf6115dda0731da21c0e12c08e6bcea36078e83e4966

Or you can simply type https://www.sb/ in your browser to view the certificate

https://www.sb/uploads/images/201609/24/181/n9k4qfbVYj.png

I also tried to make an nginx conf in my server for https://sb/ you can change 
your /etc/hosts or just use curl commmand

curl -v -H "Host: sb" https://www.sb/

You can find 403 Forbidden in title without any SSL certificate error because I 
set the return status for https://sb/ to 403

Sorry for my bad English

Best Regards,
@Showfom
___
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

[Richard Wang]

Hi Gerv,

Please check this news (Feb 25th 2015) in OSCCA website: 
http://www.oscca.gov.cn/News/201312/News_1254.htm that all China licensed CA 
finished the PKI/CA system upgrade that all licensed CA MUST be able to issue 
SM2 certificate to subscribers.

As I said in last year CABF face to face meeting in Switzerland, WebTrust is 
USA standard, ESTI is Europe standard, I think China have its own standard 
also. This a problem for global CA that have business in worldwide countries 
that maybe need to setup many roots to manage for complying with different 
standard.

We know issuing SM2 cert is not complied with BR, but you can treat it as 
"compelled" by regulations, so we need to test the gateway installed RSA 
certificate and SM2 certificate in the public Internet, to test the 
auto-negotiation from browser to gateway, if the browser like Firefox don't 
support SM2, then the gateway will use RSA certificate for communication, if 
the browser like 360 browser that support SM2, then use SM2 certificate.

We revoked the SM2 certificate after finishing the test.


Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Gervase Markham
Sent: Friday, September 23, 2016 6:55 PM
To: Han Yuwei ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

On 23/09/16 11:49, Han Yuwei wrote:
>> http://www.oscca.gov.cn/Column/Column_32.htm
> 
> If anybody want a English version of laws & regulations, Percy and I may help.

No-one is denying that SM2 may be a Chinese government standard. What we are 
saying is the fact that it's a standard does not compel WoSign to issue 
certificates using it from their publicly-trusted roots.

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: Incidents involving the CA WoSign

[Richard Wang]

Hi Gerv,

This is the final statement about the incident: 
https://www.wosign.com/report/WoSign_final_statement_09232016.pdf (in English)

https://www.wosign.com/report/WoSign_final_statement_CN_09232016.pdf  (中文版) (In 
Chinese, this is easy for Chinese users.)

I think this is the supplement of the two released reports. 

Please let me if you have any questions about this statement, thanks.


Best Regards,

Richard Wang
CEO
WoSign CA Limited


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Richard Wang
Sent: Friday, September 16, 2016 6:05 PM
To: Gervase Markham <g...@mozilla.org>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Incidents involving the CA WoSign

Hi Gerv,

This is the final report: 
https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf 

Please let me if you have any questions about the report, thanks.


Best Regards,

Richard Wang
CEO
WoSign CA Limited


-Original Message-
From: Gervase Markham
Sent: Wednesday, September 7, 2016 7:00 PM
To: Richard Wang; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Hi Richard,

On 07/09/16 11:06, Richard Wang wrote:
> This discuss has been lasting two weeks, I think it is time to end it, 
> it doesn’t worth to waste everybody’s precious time.

Unfortunately, I think we may be only beginning.

I have prepared a list of the issues we are tracking with WoSign's certificate 
issuance process and business:

https://wiki.mozilla.org/CA:WoSign_Issues 

Please can you provide a response to issues F, P, S and T at your earliest 
convenience?

In addition, if you have further things to say about issues D, H, J, L, N or V 
we would be happy to hear them.

Thank you for your suggestions, but once Mozilla has a full understanding of 
what has gone on we will be in a better position to decide what next actions 
are appropriate.

With best wishes,

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: WoSign and StartCom audit reports

[Richard Wang]

Thanks for your hard work. I wish you can finish check for all other CA's 
report ASAP.

For WoSign, the report covered all 4 roots, not 3 roots.

For StartCom, Eddy can say something about it, StartCom is 1000% independent 
for everything at 2015.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Peter Bowen
Sent: Friday, September 23, 2016 10:54 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: WoSign and StartCom audit reports

As hinted at in my earlier email about what is expected in audit reports, I've 
been looking at WebTrust audit reports from many CAs in the Mozilla program and 
those applying to be in the program.

Since there has been lots of discussion about WoSign and Startcom recently, I 
took a look at their latest reports.  I thought others might be interested in 
the result.

Thanks,
Peter

Review of WoSign audit reports
for the period 1 January 2015 to 31 December 2015

Good:
- Uses AICPA standards
- Uses current criteria versions

Bad:
- Only covers three roots, not subordinate CAs (true for all three
reports: CA, BR, and EV)
- Does not provide assurance that subordinate CA certificate requests are 
accurate, authenticated, and approved

Really Bad:
- Includes 'emphasis of matters' which show failures of controls but still 
claims to be an unqualified opinion
- The EV opinion does not note that some of the EV certificates using a SHA-1 
hash in the signature have expiration dates after 2016-12-31


Review of StartCom audit reports
for the period 1 January 2015 to 31 December 2015

Good:
- Uses AICPA standards
- Uses current criteria versions

Bad:
- Only covers two roots, not subordinate CAs (true for all three
reports: CA, BR, and EV)
- Does not provide assurance that subordinate CA certificate requests are 
accurate, authenticated, and approved
- Does not provide assurance that it meets the Network and Certificate System 
Security Requirements as set forth by 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

OpenSSL OCSP serious vulnerability

[Richard Wang]

OpenSSL OCSP Status Request extension unbounded memory growth (CVE-2016-6304)

http://security.360.cn/cve/CVE-2016-6304/index.html?from=timeline=0


Best Regards,

Richard
___
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

[Richard Wang]

Sorry, the random apart time is from 20 minutes to 60 minutes, not to 40 
minutes.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Richard Wang
Sent: Thursday, September 22, 2016 1:50 PM
To: Peter Bowen <pzbo...@gmail.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Gervase Markham 
<g...@mozilla.org>
Subject: RE: Incidents involving the CA WoSign

For security, the notBefore time is not the exact time of signing, random from 
20 minutes to 40 minutes ahead.

For 6 long delta time, we said it is a CT Post System bug; For 2016-07-30 
between 05:20 and 07:40 (CST), it is caused by the Internet connection problem 
from China to Google CT log server that need to resign after the internet 
connection is ok.
For normal case, it is OK, good.

Thanks.


Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Thursday, September 22, 2016 12:32 PM
To: Richard Wang <rich...@wosign.com>
Cc: Gervase Markham <g...@mozilla.org>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

On Wed, Sep 21, 2016 at 9:10 PM, Richard Wang <rich...@wosign.com> wrote:
>> Are you saying out of over 40,000 orders over the last year, only six 
>> "stopped to move forward" for a period of a week or more and these happen to 
>> all have been ordered on Sunday, December 20, 2015 (China time)?
>
> You mean we issued 40,000 certificates at Dec 20, 2015?

No, there slightly over 40418 certificates issued by CAs under the WoSign roots 
which have embedded Signed Certificate Timestamps.  They were issued over the 
course of approximately one year; the earliest notBefore date is 
2015-08-20T09:40:48Z and my CT data set was up to date as of 2015-09-05.

Of these 40418 certificates, 40394 had a delta between notBefore and the 
earliest SCT is less than 3 hours. Eighteen certificates have a delta between 5 
hours and 51 hours; all 18 of these have a notBefore on 2016-07-30 between 
05:20 and 07:40 (CST). The remaining 6 certificates have a delta of between 
262.3 hours (10.9 days) and 693.7 hours (28.9 days).  All six of these have a 
notBefore on 2015-12-20 (CST).

For with it is worth, the largest difference between the earliest embedded 
timestamp and the latest is less than 15 minutes in all certificates.

> We issued SHA-1 certificate at every day, Dec 20 is not a special day, why 
> you care about this day is Computest get the SHA-1 certificate used this date 
> that we still don't know how he get this, so we closed this API completely, 
> even deleted the API domain resolution.

I'm looking at all WoSign issued certificates, ignoring the hash algorithm used 
in the signature.  Two dates have certificates that are clear outliers when 
measuring the difference between notBefore and the timestamps.  I'm wondering 
what is special about these dates or these certificates.

Thanks,
Peter
___
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

[Richard Wang]

For security, the notBefore time is not the exact time of signing, random from 
20 minutes to 40 minutes ahead.

For 6 long delta time, we said it is a CT Post System bug;
For 2016-07-30 between 05:20 and 07:40 (CST), it is caused by the Internet 
connection problem from China to Google CT log server that need to resign after 
the internet connection is ok.
For normal case, it is OK, good.

Thanks.


Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Thursday, September 22, 2016 12:32 PM
To: Richard Wang <rich...@wosign.com>
Cc: Gervase Markham <g...@mozilla.org>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

On Wed, Sep 21, 2016 at 9:10 PM, Richard Wang <rich...@wosign.com> wrote:
>> Are you saying out of over 40,000 orders over the last year, only six 
>> "stopped to move forward" for a period of a week or more and these happen to 
>> all have been ordered on Sunday, December 20, 2015 (China time)?
>
> You mean we issued 40,000 certificates at Dec 20, 2015?

No, there slightly over 40418 certificates issued by CAs under the WoSign roots 
which have embedded Signed Certificate Timestamps.  They were issued over the 
course of approximately one year; the earliest notBefore date is 
2015-08-20T09:40:48Z and my CT data set was up to date as of 2015-09-05.

Of these 40418 certificates, 40394 had a delta between notBefore and the 
earliest SCT is less than 3 hours. Eighteen certificates have a delta between 5 
hours and 51 hours; all 18 of these have a notBefore on 2016-07-30 between 
05:20 and 07:40 (CST). The remaining 6 certificates have a delta of between 
262.3 hours (10.9 days) and 693.7 hours (28.9 days).  All six of these have a 
notBefore on 2015-12-20 (CST).

For with it is worth, the largest difference between the earliest embedded 
timestamp and the latest is less than 15 minutes in all certificates.

> We issued SHA-1 certificate at every day, Dec 20 is not a special day, why 
> you care about this day is Computest get the SHA-1 certificate used this date 
> that we still don't know how he get this, so we closed this API completely, 
> even deleted the API domain resolution.

I'm looking at all WoSign issued certificates, ignoring the hash algorithm used 
in the signature.  Two dates have certificates that are clear outliers when 
measuring the difference between notBefore and the timestamps.  I'm wondering 
what is special about these dates or these certificates.

Thanks,
Peter
___
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

[Richard Wang]

> Are you saying out of over 40,000 orders over the last year, only six 
> "stopped to move forward" for a period of a week or more and these happen to 
> all have been ordered on Sunday, December 20, 2015 (China time)?

You mean we issued 40,000 certificates at Dec 20, 2015?

Here is the last two weeks in 2015 issued SSL certificates statistics that I 
send it to Gerv:

   WEEK FRI SAT SUN MON TUE WED THU FRI 
SAT SUN MON TUE WED THU
Dec. 2015   18  19  20  21  22  23  24  25  
26  27  28  29  30  31
Issued No   419 321 278 348 746 463 407 424 
294 257 424 380 506 344
SHA-1 Cert  39  24  46  18  43  29  31  25  
3   0   29  31  37  13
SHA-2 Cert  380 297 232 330 703 434 376 399 
291 257 395 349 469 331


We issued SHA-1 certificate at every day, Dec 20 is not a special day, why you 
care about this day is Computest get the SHA-1 certificate used this date that 
we still don't know how he get this, so we closed this API completely, even 
deleted the API domain resolution.


Best Regards,

Richard


>Thanks,
 wrote:
> Hi Gerv,
>
> See below inline, thanks.
>
> Regards,
>
> Richard
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign.com@lists.mozilla.o
> rg] On Behalf Of Gervase Markham
> Sent: Wednesday, September 21, 2016 9:19 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Incidents involving the CA WoSign
>
> Hi Richard,
>
> Thanks for the additional information.
>
___
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

[Richard Wang]

Thanks for your good test to have an experience to know more how we work.

What I told Gerv that you can place an order at our site today -- Sept. 22nd 
2016, but DON'T do the domain validation, leave it here. Four months later, you 
login your account to finish the domain validation, then system will post to CT 
log server to get SCT data, then the cert issued data is Jan 22nd 2017, the 
cert notBefore is Jan 22nd 2017. But the order data in our system is Sept 22nd 
2016. 

This is for explanation that Gerv ask why the order time is four month ago- Aug 
15th, but the notBefore (the issuance day) is Dec. 20th for a free DV SSL 
certificate that take so long time.

I wish I said this clearly, thanks.


Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Thursday, September 22, 2016 11:38 AM
To: Richard Wang <rich...@wosign.com>
Cc: Gervase Markham <g...@mozilla.org>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Richard,

I'm having a really hard time reconciling what you describe with what is found 
in the CT logs and what I observed today when doing as you suggested and 
getting a cert from https://buy.wosign.com/free/.

I pulled all the WoSign certificates from CT logs that have embedded SCTs.  
There are 40418 such certificates (as of a few days ago), of which 898 are EV 
certificates.  For the EV certificates, other than the six that were raised as 
potentially being backdated, the delta between the notBefore date and the 
earliest SCT embedded in the certificate ranged from 1130.54 to 9949.10 
seconds.  890 of the 898 EV certificates had a delta under one hour.  When 
looking at the full set of 40418, the delta ranges from 1128.91 to 182896.75 
seconds.  All the certificates with a delta greater than 1 seconds have a 
notBefore date of 2016-07-29, again with the exception of the six certificates 
Gerv raised.

Are you saying out of over 40,000 orders over the last year, only six "stopped 
to move forward" for a period of a week or more and these happen to all have 
been ordered on Sunday, December 20, 2015 (China time)?

I also would like to get your feedback on the timeline I observed today when I 
get a certificate at the site you suggested.  Here is what I observed (ordered 
by time):
2015-09-21 15:31UTC Order created
2015-09-21 19:58UTC Domain Validated
2015-09-21 20:05UTC Uploaded CSR (sorry, failed to log time,
approximate time)
State moved to "Pending" (shortly after uploading CSR)
2016-09-21 23:10:42 UTC Certificate NotBefore
2016-09-21 23:36:32 UTC Log SCT (using precertificate)
2016-09-21 23:36:33 UTC Log SCT (using precertificate)
2016-09-21 23:36:33 UTC Log SCT (using precertificate)
2016-09-21 23:36:35 UTC WoSign Log SCT (using precertificate)
2016-09-21 23:37:08 UTC Date header on Certificate ready for collection email

Mail received headers: 23:37:13 (by mta1.wosign.com), 23:37:44 (by 
mx.google.com).

It would appear that the NotBefore was not set until after I completed 
validation, uploaded a CSR, and the order passed other (possibly
human) checks. From that point it was less than half an hour until I had my 
certificate.  Is this the behaviour you expect to see?

Thanks,
Peter

On Wed, Sep 21, 2016 at 7:26 AM, Richard Wang <rich...@wosign.com> wrote:
> Hi Gerv,
>
> See below inline, thanks.
>
> Regards,
>
> Richard
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign.com@lists.mozilla.o
> rg] On Behalf Of Gervase Markham
> Sent: Wednesday, September 21, 2016 9:19 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Incidents involving the CA WoSign
>
> Hi Richard,
>
> Thanks for the additional information.
>
> On 21/09/16 11:11, Richard Wang wrote:
>> Some SHA-1 certificate is free SSL certificate that no any reason for 
>> us to help them get the SHA-1 certificate if we are intentional, and 
>> some certificate is even never used or even not retrieved from our 
>> system, this also can be certified it is a normal order without any 
>> doubt.
>
> I have examined the spreadsheet you sent (note: may not be available to 
> mozilla.dev.security.policy participants due to lack of attachment support). 
> The "Categrory 4 - 3:  12 Normal FREE DV SSL Certificates"
> contains 12 certificates, which have no cost associated with them, and no 
> identity vetting other than domain control. Why did each of these take over a 
> month, and in some cases nearly 4 months, to be issued? What was the hold-up?
> -
> R: You can place order there and don't do the domain validation, 4 
> months later, you finished the domain control validation, then issue 
> the certificate. Please try it by yourself here:

Sanctions short of distrust

[Richard Wang]

I know WoSign make some mistakes in 2015, and I accept any reasonable fair 
enough sanction. But WoSign will continue to do our best to provide best 
products and best service to worldwide customers, no matter what the sanction 
is.
Here is the answer for your questions:

> Do we trust that WoSign will honor requests for certs to be revoked?

Yes, we honor your requests for certs to be revoked for FREE according to our 
CPS. We used Akamai CDN for worldwide customer to provide best CRL/OCSP service.

> Do we trust that revocation will take place in a timely matter?

Yes, we will take place your revocation request in a timely matter that exceed 
your expectation – within 24 hours (24 x 365 non-stop).

> Do we trust that WoSign will not collect information on hits to any OCSP 
> responders they have set up and share that info with...whomever?

Yes, any CA can do this if need. But you can use OCSP Stapling in your web 
server.
We don’t worry about most China online banking system and many ecommerce 
website using the foreign CA certificate, what do you worry about? As I said, 
we used Akamai CDN service that all hits will go to Akamai Edge servers first.


Best Regards,

Richard Wang
CEO
WoSign CA limited


From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Peter Kurrasch
Sent: Thursday, September 22, 2016 3:06 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Time to distrust (was: Sanctions short of distrust)

Do we trust that WoSign will honor requsts for certs to be revoked? Do we trust 
that revocation will take place in a timely matter? Do we trust that WoSign 
will not collect information on hits to any OCSP responders they have set up 
and share that info with...whomever?

___
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

[Richard Wang]

Not this case.
Gerv ask why the order is placed at Aug. 12th 2015, why it is issued at Dec. 
20th 2015, since he finished the domain validation at Dec 20th.


Best Regards,

Richard

On Sep 21, 2016, at 22:54, Kurt Roeckx <k...@roeckx.be<mailto:k...@roeckx.be>> 
wrote:

On 2016-09-21 16:26, Richard Wang wrote:
R: You can place order there and don't do the domain validation, 4 months 
later, you finished the domain control validation, then issue the certificate. 
Please try it by yourself here: https://buy.wosign.com/free/

So the date in the certificate is from when the order was placed? This seems to 
contradict other things that have been stated, including why for instance issue 
F happens.


Kurt

___
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: Incidents involving the CA WoSign

[Richard Wang]

Hi Gerv,

See below inline, thanks.

Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Gervase Markham
Sent: Wednesday, September 21, 2016 9:19 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Hi Richard,

Thanks for the additional information.

On 21/09/16 11:11, Richard Wang wrote:
> Some SHA-1 certificate is free SSL certificate that no any reason for 
> us to help them get the SHA-1 certificate if we are intentional, and 
> some certificate is even never used or even not retrieved from our 
> system, this also can be certified it is a normal order without any 
> doubt.

I have examined the spreadsheet you sent (note: may not be available to 
mozilla.dev.security.policy participants due to lack of attachment support). 
The "Categrory 4 - 3:  12 Normal FREE DV SSL Certificates"
contains 12 certificates, which have no cost associated with them, and no 
identity vetting other than domain control. Why did each of these take over a 
month, and in some cases nearly 4 months, to be issued? What was the hold-up?
-
R: You can place order there and don't do the domain validation, 4 months 
later, you finished the domain control validation, then issue the certificate. 
Please try it by yourself here: https://buy.wosign.com/free/ 
--
> I think there are many reasons to stop to sign it due to double check, 
> for EV order, it must pass at least 6 person’s check:

Yes, indeed. But at what point during these checks do the following events 
happen?

A) Pre-cert is created and signed (if needed)
B) Pre-cert is sent to CT (if needed)
C) Real cert is created and signed
D) Cert is sent to the customer

I would expect none of these things to happen until all checks are completed. 
We know from previous conversations that your step 7 (next day review) happens 
after C) and D). Where do those four events fit into your seven steps, exactly?
-
R: not of all. The process is stopped after pre-signed the cert but not post to 
CT log server.
-
> Not the case, only one simple bug from CT Post system. I try to say 
> more clearly.
> https://crt.sh/?serial=6D24E483E27F55479C5C555B37745353 is ordered in 
> 19th Dec. 2015, and system pre-signed the pre-cert using SHA-1, no any 
> problem. But it is stopped due to some more check. At 4th Jan.
> 2016, this order finished the final check and go to signing server, 
> signing server generated a new SHA-2 pre-cert to post to CT log server 
> since SHA-1 is not allowed, and get SCT data to the certificate, this 
> is the second certificate:
> https://crt.sh/?serial=31742a2b12809bfca04cffc050903837, also no any 
> problem. The problem is the CT post system have a bug that posted the 
> two related pre-cert to CT log server (SHA-1 pre-cert is the original 
> one, and SHA-2 pre-cert is the new copied one), then get two 
> certificates one signed with SHA-1 and one is SHA-2.  We also posted 
> the two issued certificates to CT log server later.

But that's not how CT works. You don't sent the CT server a pre-cert and get a 
cert back. You send it a pre-cert, and it sends SCTs back. You then need to get 
those SCTs, incorporate them into a new certificate which has the SCTs but not 
the poison extension, and then sign that using your signing server, and then 
store it in your database. All that happened by mistake, due to a single bug? 
You stored the certificate in your system for a number of months because you 
still had it in September when you uploaded it to CT.
--
R: let me try to draw a work flow:
1) SHA-1 cert request at Dec 19th 2015, system pre-signed it as "Pre-cert A" in 
our database, this order is in pending issuance status;
2) but this order is reviewed and stopped to move forward by some reason; so 
this order still in pending status;
3) at Jan 4th 2016, this order is released to move forward. But today is Jan 
4th that SHA-1 cert is forbidden, so the signing server sign the same CSR again 
using SHA-2 to be "Pre-cert B";
4) then the CT Post system posted the two pre-cert into CT log server since 
this two pre-cert is in one order record, this is the bug, it must post the 
Pre-cert B to CT log server, not Pre-cert A, but it posted both;
5) the two pre-cert get SCT data, back to signing server, the signing server 
signed the two cert out: one is SHA-1 with notBefore Dec 19th 2015, one is 
SHA-2 with notBefore Jan 4th 2016;
6) this means the original order copied to two orders in system with two signed 
certificate. The interesting thing is customer just retrieve the SHA-2 cert and 
installed it in his website.
We don't know this bug till someone expose this in the email discussion since 

RE: Incidents involving the CA WoSign

[Richard Wang]

See below inline, thanks.



Best Regards,



Richard



-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Tuesday, September 20, 2016 7:37 PM
To: Richard Wang <rich...@wosign.com<mailto:rich...@wosign.com>>
Subject: Re: Incidents involving the CA WoSign



Hi Richard,



On 16/09/16 11:05, Richard Wang wrote:

> Hi Gerv,

>

> This is the final report:

> https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf

>

> Please let me if you have any questions about the report, thanks.



Thank you for this report. I have a few follow-up questions:



Issue H: Duplicate Serial Numbers



1) You write: "Firstly 313 certificates and secondly 27 certificates were 
affected by a system bug with the serial number generation, generating a serial 
number starting with “0” in the first left position. The signing system had a 
bug that didn’t know how to deal with this kind of serial number."



Can you explain a bit more how such a bug can lead to all the certificates 
having the same serial number?

---

Richard:  please check the first 313 certificate serial is 
“56D1570DA645BF6B44C0A7077CC6769” and the second 27 certificate is 
“D3BBDC3A0175E38F9D0070CD050986A” that only 31 bytes. But our serial number 
rule is 32 bytes, so the real two serial number is 
“056D1570DA645BF6B44C0A7077CC6769” and “0D3BBDC3A0175E38F9D0070CD050986A” that 
the signing system has a bug that don’t know how to deal with this kind of 
serial and locked to use this same serial number to sign the certificate.

Please notice the two case (313 and 27) happened in the same time that the 
first 313 certificate is issued by one intermediate CA in English, and the 
second 27 certificate is signed by another intermediate CA in Chinese. This is 
why two case, but we fix the bug, then no more happened.

--



Issue S: Backdated SHA-1 Certs



2) You say that you "found only 8 SHA-1 SSL certificates that were mis-issued 
after January 1st 2016 until June 28th 2016." Why did your searching end at 
June 28th? Have you looked at the rest of June, July and August?

-

Richard: I checked every system to make sure every procedure step has closed 
the SHA-1 option for SSL certificate at June 28th 2016 after we got report from 
Computest, there are another place in API can go to signing server that don’t 
go to SHA-1 blocking system first, this is a bug from the unused API code for 
StartEncrypt. So I can guarantee no more after that day.





3) You say you sent an email to all your staff at the end of December 
forbidding SHA-1 issuance. Does that mean the staff have control of whether a 
cert uses SHA-1 or not? Does WoSign employ certificate templates to make sure 
all appropriate fields are set correctly? If not, why not? If so, is the hash 
algorithm used something that employees can set or override?

---

Richard: as I said in the report, after my email, the Buy website don’t accept 
SHA-1 request after Dec. 30th 2015. But due to some pending request in the 
system that ordered before Dec. 30th 2015, so the PKI system still allow to 
sign SHA-1, this is the problem, we have 3 systems: Buy – CMS – PKI. No anyone 
can change the setting since the certificate template setting is controlled by 
me only.

---



4) All 64 of the certificates being considered here have a notBefore date of 
Sunday, 20th December 2015. Does that correctly reflect the date the 
certificates were created (to within a day)? (For this question, ignore the 2 
certificates mis-issued to CompuTest via the StartEncrypt API.)

If not, what is the technical reason for this back/forward dating? And can you 
please provide a list of the 64 certificates along with their actual dates of 
creation?

---

Richard: For the 62 certificates, there are 22 certificates issued at 19th Dec, 
40 certificates is issued at 20th Dec. 2015.  I checked our system, Dec 20th is 
very normal day, we issued SHA-1 certificate at every day, just one day no 
SHA-1 cert. We provide 24 x 365 service for worldwide customers.
Here is the statistics for the last two weeks SSL certificate issuance in 2015.

[cid:image001.png@01D21431.B2C05D70]

Some SHA-1 certificate is free SSL certificate that no any reason for us to 
help them get the SHA-1 certificate if we are intentional, and some certificate 
is even never used or even not retrieved from our system, this also can be 
certified it is a normal order without any doubt.

--



Issue S, Category 1



These questions relate to your first category, the six certificates which were 
mis-issued due to a bug.



5) You say that the certificates were pre-signed, at some point before midnight 
on 31st December 2016, but then the process was stopped for payment or proof 
document problems. Is it WoSign's normal practice to sign certificat

RE: Incidents involving the CA WoSign

[Richard Wang]

See below inline, thanks.

Best Regards,

Richard

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Tuesday, September 20, 2016 7:37 PM
To: Richard Wang <mailto:rich...@wosign.com>
Subject: Re: Incidents involving the CA WoSign

Hi Richard,

On 16/09/16 11:05, Richard Wang wrote:
> Hi Gerv,
> 
> This is the final report: 
> https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf
> 
> Please let me if you have any questions about the report, thanks.

Thank you for this report. I have a few follow-up questions:

Issue H: Duplicate Serial Numbers

1) You write: "Firstly 313 certificates and secondly 27 certificates were 
affected by a system bug with the serial number generation, generating a serial 
number starting with “0” in the first left position. The signing system had a 
bug that didn’t know how to deal with this kind of serial number."

Can you explain a bit more how such a bug can lead to all the certificates 
having the same serial number?
---
Richard:  
Please check the first 313 certificate serial is 
“56D1570DA645BF6B44C0A7077CC6769” and the second 27 certificate is 
“D3BBDC3A0175E38F9D0070CD050986A” that only 31 bytes. But our serial number 
rule is 32 bytes, so the real two serial number is 
“056D1570DA645BF6B44C0A7077CC6769” and “0D3BBDC3A0175E38F9D0070CD050986A” that 
the signing system has a bug that don’t know how to deal with this kind of 
serial and locked to use this same serial number to sign the certificate. 
Please notice the two case (313 and 27) happened in the same time that the 
first 313 certificate is issued by one intermediate CA in English, and the 
second 27 certificate is signed by another intermediate CA in Chinese. This is 
why two case, but we fix the bug, then no more happened.
--

Issue S: Backdated SHA-1 Certs

2) You say that you "found only 8 SHA-1 SSL certificates that were mis-issued 
after January 1st 2016 until June 28th 2016." Why did your searching end at 
June 28th? Have you looked at the rest of June, July and August?
-
Richard: 
I checked every system to make sure every procedure step has closed the SHA-1 
option for SSL certificate at June 28th 2016 after we got report from 
Computest, there are another place in API can go to signing server that don’t 
go to SHA-1 blocking system first, this is a bug from the unused API code for 
StartEncrypt. So I can guarantee no more after that day. 


3) You say you sent an email to all your staff at the end of December 
forbidding SHA-1 issuance. Does that mean the staff have control of whether a 
cert uses SHA-1 or not? Does WoSign employ certificate templates to make sure 
all appropriate fields are set correctly? If not, why not? If so, is the hash 
algorithm used something that employees can set or override?
---
Richard: 
As I said in the report, after my email, the Buy website don’t accept SHA-1 
request after Dec. 30th 2015. But due to some pending request in the system 
that ordered before Dec. 30th 2015, so the PKI system still allow to sign 
SHA-1, this is the problem, we have 3 systems: Buy – CMS – PKI. No anyone can 
change the setting since the certificate template setting is controlled by me 
only.
---

4) All 64 of the certificates being considered here have a notBefore date of 
Sunday, 20th December 2015. Does that correctly reflect the date the 
certificates were created (to within a day)? (For this question, ignore the 2 
certificates mis-issued to Computest via the StartEncrypt API.)
If not, what is the technical reason for this back/forward dating? And can you 
please provide a list of the 64 certificates along with their actual dates of 
creation?
---
Richard: 
For the 62 certificates, there are 22 certificates issued at 19th Dec, 40 
certificates is issued at 20th Dec. 2015.  I checked our system, Dec 20th is 
very normal day, we issued SHA-1 certificate at every day, just one day no 
SHA-1 cert. We provide 24 x 365 service for worldwide customers. 
 
Some SHA-1 certificate is free SSL certificate that no any reason for us to 
help them get the SHA-1 certificate if we are intentional, and some certificate 
is even never used or even not retrieved from our system, this also can be 
certified it is a normal order without any doubt.
--

Issue S, Category 1

These questions relate to your first category, the six certificates which were 
mis-issued due to a bug.

5) You say that the certificates were pre-signed, at some point before midnight 
on 31st December 2016, but then the process was stopped for payment or proof 
document problems. Is it WoSign's normal practice to sign certificates before 
payment has been received? Is it normal practice to sign certificates before 
all identity checks have been completed?
---
Richard: 
I think there are many re

RE: Incidents involving the CA WoSign

[Richard Wang]

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.

Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Tuesday, September 20, 2016 10:18 AM
To: Richard Wang <rich...@wosign.com>
Cc: Nick Lamb <tialara...@gmail.com>; 
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 <rich...@wosign.com> 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:
>> This case is WoSign problem, you found out all related subordinate companies 
>> and all related parent companies that up to nine generations! I think this 
>> is NOT the best practice in the modern law-respect society.
>
> It seems the governments of the European Union countries (including the UK 
> where one of the mentioned companies is located) disagree with you about 
> whether this is best practice.
>
> Identifying individual human persons behind a company is a key plank of their 
> anti-money laundering and anti-tax evasion policies. To identify these human 
> persons it is necessary to look through any number (even more than nine) of 
> layers of corporate ownership. In the UK the legal term is Persons with 
> Significant Control and PSC registration is mandatory since this summer, a 
> company registered in the UK is obliged to figure out if there are such 
> Persons and if so list them in its routine filings. Failing to properly 
> investigate, or concealing the truth about control of the company is 
> punishable by forfeiture, ie the state would seize the company's assets.
___
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

[Richard Wang]

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@lists.mozilla.org] 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:
> This case is WoSign problem, you found out all related subordinate companies 
> and all related parent companies that up to nine generations! I think this is 
> NOT the best practice in the modern law-respect society.

It seems the governments of the European Union countries (including the UK 
where one of the mentioned companies is located) disagree with you about 
whether this is best practice.

Identifying individual human persons behind a company is a key plank of their 
anti-money laundering and anti-tax evasion policies. To identify these human 
persons it is necessary to look through any number (even more than nine) of 
layers of corporate ownership. In the UK the legal term is Persons with 
Significant Control and PSC registration is mandatory since this summer, a 
company registered in the UK is obliged to figure out if there are such Persons 
and if so list them in its routine filings. Failing to properly investigate, or 
concealing the truth about control of the company is punishable by forfeiture, 
ie the state would seize the company's assets.
___
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

[Richard Wang]

Your behavior let me think of a Chinese word "株连九族", means "to implicate the 
nine generations of a family", this is an extreme penalty in feudal times in 
China that if a man committed a crime, the whole clan that up to nine 
generation was implicated, all must be killed together.  
Please refer to Bing dictionary: 
http://cn.bing.com/dict/search?q=%E6%A0%AA%E8%BF%9E%E4%B9%9D%E6%97%8F=n=Z9LH5=%E6%A0%AA%E8%BF%9E%E4%B9%9D%E6%97%8F=1-4=-1==0E897ABC8DD04BE09B182CB4EB71ED6A

This case is WoSign problem, you found out all related subordinate companies 
and all related parent companies that up to nine generations! I think this is 
NOT the best practice in the modern law-respect society.

To answer your question, I am sorry I don't know who is my shareholder's 
shareholder's shareholders, this is out of my job.  


Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Monday, September 19, 2016 10:31 PM
To: Richard Wang <rich...@wosign.com>
Cc: Gervase Markham <g...@mozilla.org>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Richard,

I'm still somewhat confused.  Can you review the following statements and 
either confirm they are true or specify they are not true and correct them?
I hope these are reasonably easy to confirm or for you to correct if they are 
not true.

Thanks,
Peter

On Mon, Sep 19, 2016 at 2:51 AM, Richard Wang <rich...@wosign.com> wrote:
> Hi Gerv,
>
> For Issue R listed in Wiki, we released the news today: 
> https://www.wosign.com/english/News/WoSign_completed_equity_investment
> _to_StartCom_CA.htm
>
>
> Best Regards,
>
> Richard
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign.com@lists.mozilla.o
> rg] On Behalf Of Richard Wang
> Sent: Friday, September 16, 2016 6:05 PM
> To: Gervase Markham <g...@mozilla.org>
> Cc: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Incidents involving the CA WoSign
>
> Hi Gerv,
>
> This is the final report: 
> https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pd
> f
>
> Please let me if you have any questions about the report, thanks.
>
>
> Best Regards,
>
> Richard Wang
> CEO
> WoSign CA Limited
>
>
> -Original Message-
> From: Gervase Markham
> Sent: Wednesday, September 7, 2016 7:00 PM
> To: Richard Wang; mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Incidents involving the CA WoSign
>
> Hi Richard,
>
> On 07/09/16 11:06, Richard Wang wrote:
>> This discuss has been lasting two weeks, I think it is time to end 
>> it, it doesn’t worth to waste everybody’s precious time.
>
> Unfortunately, I think we may be only beginning.
>
> I have prepared a list of the issues we are tracking with WoSign's 
> certificate issuance process and business:
>
> https://wiki.mozilla.org/CA:WoSign_Issues
>
> Please can you provide a response to issues F, P, S and T at your earliest 
> convenience?
>
> In addition, if you have further things to say about issues D, H, J, L, N or 
> V we would be happy to hear them.
>
> Thank you for your suggestions, but once Mozilla has a full understanding of 
> what has gone on we will be in a better position to decide what next actions 
> are appropriate.
>
> With best wishes,
>
> 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

[Richard Wang]

Hi Gerv,

For Issue R listed in Wiki, we released the news today: 
https://www.wosign.com/english/News/WoSign_completed_equity_investment_to_StartCom_CA.htm
 


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Richard Wang
Sent: Friday, September 16, 2016 6:05 PM
To: Gervase Markham <g...@mozilla.org>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Incidents involving the CA WoSign

Hi Gerv,

This is the final report: 
https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf 

Please let me if you have any questions about the report, thanks.


Best Regards,

Richard Wang
CEO
WoSign CA Limited


-Original Message-
From: Gervase Markham
Sent: Wednesday, September 7, 2016 7:00 PM
To: Richard Wang; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Hi Richard,

On 07/09/16 11:06, Richard Wang wrote:
> This discuss has been lasting two weeks, I think it is time to end it, 
> it doesn’t worth to waste everybody’s precious time.

Unfortunately, I think we may be only beginning.

I have prepared a list of the issues we are tracking with WoSign's certificate 
issuance process and business:

https://wiki.mozilla.org/CA:WoSign_Issues 

Please can you provide a response to issues F, P, S and T at your earliest 
convenience?

In addition, if you have further things to say about issues D, H, J, L, N or V 
we would be happy to hear them.

Thank you for your suggestions, but once Mozilla has a full understanding of 
what has gone on we will be in a better position to decide what next actions 
are appropriate.

With best wishes,

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: Incidents involving the CA WoSign

[Richard Wang]

Thank you very much for helping us.

For SM2 algorithm, this is out of this thread, I can discuss with you off list.

Regards,

Richard

> On Sep 16, 2016, at 22:32, Vincent Lynch <vtly...@gmail.com> wrote:
> 
>> On Friday, September 16, 2016 at 6:07:56 AM UTC-4, Richard Wang wrote:
>> Hi Gerv,
>> 
>> This is the final report: 
>> https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf 
>> 
>> Please let me if you have any questions about the report, thanks.
>> 
>> 
>> Best Regards,
>> 
>> Richard Wang
>> CEO
>> WoSign CA Limited
> 
> Hi Richard,
> 
> Thank you for you and your team's hard work on the report. As an observer, I 
> found it very informative.
> 
> I do have a follow up question regarding Issue P. I'm curious as to why this 
> test ever took place with publicly trusted certificates given that the SM2 
> algorithm is not allowed by the CA/B Forum.
> 
> Say this test was "successful". Whats next? Since SM2 is not allowed, was 
> WoSign planning on introducing a ballot to the CA/B Forum to approve SM2?
> 
> Sincerely,
> 
> Vincent
> ___
> 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

[Richard Wang]

Please read the report carefully that it is NOT the validation system is 
hijacked.


Regards,

Richard

> On Sep 16, 2016, at 21:31, Han Yuwei <hanyuwe...@gmail.com> wrote:
> 
> 在 2016年9月16日星期五 UTC+8下午6:07:56，Richard Wang写道：
>> Hi Gerv,
>> 
>> This is the final report: 
>> https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf 
>> 
>> Please let me if you have any questions about the report, thanks.
>> 
>> 
>> Best Regards,
>> 
>> Richard Wang
>> CEO
>> WoSign CA Limited
>> 
> 
> About mis-issued alicdn.com and github.com, is the whitelist a acceptable 
> solution? I thought it is a serve problem that possible hijacks on CA's 
> validation host to the server. Lots of vulnerablity could be used by hackers 
> such as DNS poisoning and TCP hijacks. This time the alicdn noticed this 
> problem because it is a big company. If this happened to a relatively small 
> company can we notice this in time? I am very doubt about that. Anything we 
> can do to prevent this from happening?
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Richard Wang]

Hi Gerv,

This is the final report: 
https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf 

Please let me if you have any questions about the report, thanks.


Best Regards,

Richard Wang
CEO
WoSign CA Limited


-Original Message-
From: Gervase Markham  
Sent: Wednesday, September 7, 2016 7:00 PM
To: Richard Wang; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Hi Richard,

On 07/09/16 11:06, Richard Wang wrote:
> This discuss has been lasting two weeks, I think it is time to end it, 
> it doesn’t worth to waste everybody’s precious time.

Unfortunately, I think we may be only beginning.

I have prepared a list of the issues we are tracking with WoSign's certificate 
issuance process and business:

https://wiki.mozilla.org/CA:WoSign_Issues 

Please can you provide a response to issues F, P, S and T at your earliest 
convenience?

In addition, if you have further things to say about issues D, H, J, L, N or V 
we would be happy to hear them.

Thank you for your suggestions, but once Mozilla has a full understanding of 
what has gone on we will be in a better position to decide what next actions 
are appropriate.

With best wishes,

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

RE: Sanctions short of distrust

[Richard Wang]

Please don't mix StartCom with WoSign case, StartCom is 100% independent at 
2015.

Even now, it still independent in the system, in the validation team and 
management team, we share the CRL/OCSP distribution resource only.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Adam Caudill
Sent: Tuesday, September 13, 2016 7:30 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Sanctions short of distrust

Of all the possible options - G seems to be the most practical. It provides a 
few key benefits, that I see as making it a clear leader:

1) It can be implemented quickly. It has been discussed that C is rather 
complex because of the size of the list, with the only truly practical solution 
being the development of a new method of querying certificates to see if they 
are in the list. That would take time to design, build, and coordinate with 
various vendors to implement. Given the severity of the issues, and the lack of 
transparency, I believe it's clear that a solution to minimize future harm is 
needed as quickly as possible.

2) As pointed out, the list would naturally shrink over time; as domain names 
expire, certificates are revoked or expire (without new ones being issued), the 
list could be updated to make it smaller and smaller over time. So the impact 
of size will diminish as time goes on.

3) This provides an opportunity for a very clearly defined turndown - establish 
a date of general distrust when whitelist because active, and date of whitelist 
expiration. This makes it easy for all to have a general idea of when these 
restrictions will be enforced, giving vendors and customers clear expectations 
and time to prepare.

4) This also provides an opportunity for StartCom / WoSign to attempt to clean 
up their act, and continue servicing existing customers (while minimizing risk 
by limiting new certificates) during the process. They could re-apply for 
inclusion, demonstrating they they are now actually in compliance without 
excessive harm to them or to users. While it would be easiest to simply call 
for the death penalty and be done, this could serve as a substantial enough 
wake-up call to get them to correct their issues and operate properly. When 
faced with the impending doom of the company, they are likely to be willing to 
consider more options to truly correct issues. Personally, I'm not at all 
convinced that the current management will be able to correct the issues, but 
if there's a way forward that can minimize risk and provide them a chance to 
change sufficiently that it minimizes impact to customers and end-users, that 
seems like the route to pursue.

When trying to strike a balance that preserves trust, and minimizes impact to 
users, there is no perfect solution, but this option seems to strike a very 
reasonable balance.
___
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

[Richard Wang]

Hi all,

We will publish a more comprehensive report in the next several days that will 
attempt to cover most / all issues.
Thanks for your patience.

Regards,

Richard

> On 7 Sep 2016, at 18:58, Gervase Markham <g...@mozilla.org> wrote:
> 
> Hi Richard,
> 
>> On 07/09/16 11:06, Richard Wang wrote:
>> This discuss has been lasting two weeks, I think it is time to end
>> it, it doesn’t worth to waste everybody’s precious time.
> 
> Unfortunately, I think we may be only beginning.
> 
> I have prepared a list of the issues we are tracking with WoSign's
> certificate issuance process and business:
> 
> https://wiki.mozilla.org/CA:WoSign_Issues
> 
> Please can you provide a response to issues F, P, S and T at your
> earliest convenience?
> 
> In addition, if you have further things to say about issues D, H, J, L,
> N or V we would be happy to hear them.
> 
> Thank you for your suggestions, but once Mozilla has a full
> understanding of what has gone on we will be in a better position to
> decide what next actions are appropriate.
> 
> With best wishes,
> 
> Gerv


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign’s Ownership of StartCom

[Richard Wang]

Hi all,

An announcement and disclosure will be made shortly pending completion of the 
business transaction.
We can provide the proof documents to Mozilla to show this transaction is not 
finished if Mozilla think it is necessary.


Regards,

Richard

> On 9 Sep 2016, at 17:47, Gervase Markham <g...@mozilla.org> wrote:
> 
> Dear m.d.s.policy,
> 
> We have been actively investigating reports that WoSign and StartCom may
> have failed to comply with our policy on change of control notification.
> Below is a summary representing the best of our knowledge and belief,
> based on our findings and investigation to date.
> 
> The operations of the CA known as StartCom have historically been owned
> and controlled by an Israeli company, number 513747303, called "סטארט
> קומארשל בע”מ", or in English "Start Commercial Ltd". This company will
> be referred to in this document as "StartCom IL". It has normally been
> represented in public and the CAB Forum by its COO/CTO, Eddy Nigg.
> 
> On August 5th, 2015 a new company, "StartCom CA Ltd", was created in
> Hong Kong.[0] This company will be referred to in this document as
> "StartCom HK".
> 
> On August 21st, 2015 a new company, also called "StartCom CA Ltd", was
> created in the UK.[1] This company will be referred to in this document
> as "StartCom UK".
> 
> 100% of the shares of “StartCom CA Ltd” in the UK are listed as being
> owned by "StartCom CA Ltd".[2] This seems circular, but our
> understanding is it actually refers to StartCom HK, which has the same
> name. StartCom UK is documented as having two directors. One is Gaohua
> (Richard) Wang, who will be known to you all as he represents WoSign in
> this forum and at the CAB Forum. The other, appointed last month, is
> Iñigo Barreira, formerly of the CA Izenpe and now of StartCom.
> 
> StartCom HK's 100% ownership appears to give it total control over
> StartCom UK, including the ability to hire and fire directors at will,
> due to a special clause (#73) in the company formation documents.[3]
> 
> StartCom HK's Company Registration Number (CRN) is 2271553, which can be
> looked up at the Cyber Search Centre of the Integrated Companies
> Registry Information System[4] in Hong Kong. There is a requirement for
> registration and a small payment, but the relevant documents have been
> provided by Mozilla. These documents show that:
> 
> * StartCom HK’s documents list only one director, Gaohua (Richard) Wang.[5]
> 
> * StartCom HK’s documents appear to show it is 100% owned (10,000
> shares) by “WoSign CA Limited”.[6]
> 
> We understand that on or around the 1st of November 2015, ownership of
> all of the shares in StartCom IL was transferred from 15 different
> shareholders (including the majority shareholder, named Revital Nigg) to
> the recently-formed StartCom UK.[7] At around the same time, Gaohua
> (Richard) Wang became the sole director of StartCom IL.[8] Details of
> these changes can be looked up at the appropriate Israeli governmental
> department. They require a payment, but are public records, and the
> relevant documents have been provided by Mozilla.
> 
> So to summarise our understanding: as of today, StartCom IL (sole
> director: Richard Wang) is 100% owned by StartCom UK (two directors:
> Richard Wang and Iñigo Barreira), which is 100% owned by StartCom HK
> (sole director: Richard Wang), which is 100% owned by the CA WoSign
> (CEO: Richard Wang).
> 
> It is important to note that there is nothing confidential about any of
> the above and none of what is described is illegal. Company ownership
> information in these jurisdictions is public information. CAs have been
> bought and sold in the past. However, the following aspects of the
> situation are problematic:
> 
> A) Mozilla's CA policy has a requirement that:
> 
> "We require that all CAs whose certificates are distributed with our
> software products notify us... when the ownership control of the CA’s
> certificate(s) changes, or when ownership control of the CA’s operations
> changes."[9]
> 
> It seems clear to us from the above account that, if our understanding
> is correct, this transaction fits this requirement - ownership control
> of the CA's operations has changed, and StartCom is now wholly owned and
> controlled by WoSign. However, the change in ownership was not reported
> to Mozilla.
> 
> B) When questioned, representatives of StartCom and WoSign have
> specifically denied that anything had happened which needed to be
> reported to Mozilla, even when this particular clause of the policy was
> drawn to their attention.
> 
> On 23rd February 2016, Richard Wang wrote: “no ‘Change in 

Re: Incidents involving the CA WoSign

[Richard Wang]

Your top 10 or top 5 is not same as my top 10 or top 5.
BTW, 
Dangdang.com is using our certificate: 
https://www.ssllabs.com/ssltest/analyze.html?d=login.dangdang.com

Some is also using our certificate that you don't know.


Regards,

Richard

> On 8 Sep 2016, at 23:59, Ming <moonbingb...@gmail.com> wrote:
> 
> 在 2016年9月7日星期三 UTC+8下午6:08:33，Richard Wang写道：
>> Hi Gerv, Kathleen and Richard,
>> 
>> This discuss has been lasting two weeks, I think it is time to end it, it 
>> doesn’t worth to waste everybody’s precious time.
>> I make my confession that our system and management do have some problems 
>> which lead to the misissuance of some certificates. And I am very sorry that 
>> WoSign don’t notify all browsers after the incident happened and even after 
>> the problem fixed.
>> 
>> I’d like to give my suggestion action for Mozilla as below:
>> 1. Mozilla will trust those SSL certificates only:
>>(1) The certificate notBefore date is before Jan. 1st 2015;
>>(2) The certificate notBefore date is from Jan. 1st 2015 to July 4th 2016 
>> that listed in the Google CT log server;
>>(3) The certificate notBefore date is from July 5th 2016 to Sept xx 2016 
>> that embedded SCT data in the certificate;
>>(4) The certificate notBefore date is from Sept xx 2016 that embedded SCT 
>> data in the certificate and must have the “C=CN” in the certificate subject.
>> 
>> 2. Mozilla can assign a WebTrust auditor to WoSign office to check and 
>> inspect every incident, check every relevant issued certificate, and record 
>> a report with:  what happened, why this happened and what is being done to 
>> prevent this in the future etc., WoSign will pay the audit cost.
>> 
>> I’d like to make some supplements about 1. (4) above, this term means WoSign 
>> will only issue SSL certificates to China subscribers. 
>> WoSign issued about 120K SSL certificates for websites in China including 
>> many central government websites like MIIT and many other local province 
>> government websites, many university websites, many online banking websites, 
>> 6 of the Top 10 ecommerce websites, big supermarket online store like 
>> Walmart, 4 of the Top 5 cloud service in China, and many big companies that 
>> listed in NYSE and Nasdaq, and many subsidiaries of foreign countries big 
>> companies.
> 
> Richard,I check the  top 10 e-commerce websites in China, ONLY suning.com and 
> yhd.com are your subscribers; and ZERO of the top 5 cloud service companies 
> in China use WoSign.
> 
> I have reason to doubt the authenticity of the data you provided. 
> 
> there is the top 10 e-commerce websites in China:
> taobao.com
> jd.com
> tmall.com
> amazon.cn
> vip.com
> meituan.com
> suning.com
> dangdang.com
> jumei.com
> yhd.com
> 
> the top 5 cloud service companies in China:
> aliyun.com
> qcloud.com
> qingcloud.com
> ucloud.cn
> hwclouds.com
> 
> 
>> Those customers like to use WoSign certificate especially our support of 
>> Chinese, local support and customer service. And some of them paid up to 
>> 10-year certificate fee in advance, we need to renew their certificate for 
>> free once it is about to expire at every three years for OV SSL.
>> 
>> I wish Mozilla could accept my suggestion, and I am sure WoSign will do it 
>> better after getting this so big lesson. 
>> Thank you.
>> 
>> 
>> Best Regards,
>> 
>> Richard Wang
>> CEO
>> WoSign CA Limited
>> 
>> 
>> -Original Message-
>> From: dev-security-policy 
>> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
>> Behalf Of Richard Wang
>> Sent: Sunday, September 4, 2016 5:49 PM
>> To: Gervase Markham <g...@mozilla.org>; 
>> mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: RE: Incidents involving the CA WoSign
>> 
>> Hi all,
>> 
>> We finished the investigation and released the incidents report today: 
>> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
>> 
>> This report has 20 pages, please let me if you still have any questions, 
>> thanks.
>> 
>> This report is just for Incident 0-2, we will release a separate report for 
>> another incident X soon.
>> 
>> 
>> Best Regards,
>> 
>> Richard Wang
>> CEO
>> WoSign CA Limited
>> 
>> 
>> -Original Message-
>> From: Gervase Markham [mailto:g...@mozilla.org] 
>> Sent: Wednesday, August 24, 2016 9:08 PM
>> To: mozilla-dev-security-pol...@lists.mozilla.org
>> C

Re: Incidents involving the CA WoSign

[Richard Wang]

We posted all 2015 certificates, total 109,405

We almost finished 2016 certificates, till now, 129,426, not finished.

All 392 cert is not from one serial number, it is from several serial numbers.


Regards,

Richard

> On 7 Sep 2016, at 20:07, Kurt Roeckx <k...@roeckx.be> wrote:
> 
>> On 2016-09-07 13:00, Gervase Markham wrote:
>> Hi Richard,
>> 
>>> On 07/09/16 11:06, Richard Wang wrote:
>>> This discuss has been lasting two weeks, I think it is time to end
>>> it, it doesn’t worth to waste everybody’s precious time.
>> 
>> Unfortunately, I think we may be only beginning.
>> 
>> I have prepared a list of the issues we are tracking with WoSign's
>> certificate issuance process and business:
>> 
>> https://wiki.mozilla.org/CA:WoSign_Issues
> 
> Thanks for putting this all in a page because I already lost track of most of 
> the issues.
> 
> This URL was posted, and at least seems to match the date range:
> https://crt.sh/?serial=056d1570da645bf6b44c0a7077cc6769=1662
> 
> It currently only has 314 of the mentioned 392 duplicates.  I don't know if 
> there are other duplicate serials we need to look for, or if they failed to 
> publish all 392.  It's at least my understanding that all certificates for 
> 2015 should already have been submitted to CT.
> 
> Related to issue F, we've been told that all 2015 certificates should have 
> been published to CT.  We got a mail saying that with "Date: Fri, 2 Sep 2016 
> 07:37:52 +".  I added the https://crt.sh/?id=30736090 to aviator later, 
> and it's now in their log too.
> 
> I guess it could be useful for everybody to go over this page and see if all 
> the issues that were raised are on that page.
> 
> 
> Kurt
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Richard Wang]

Got it, thanks.
We will reply to you soon.
By the way, the link you used in the page to our report is not correct.

Regards,

Richard

> On 7 Sep 2016, at 18:58, Gervase Markham <g...@mozilla.org> wrote:
> 
> Hi Richard,
> 
>> On 07/09/16 11:06, Richard Wang wrote:
>> This discuss has been lasting two weeks, I think it is time to end
>> it, it doesn’t worth to waste everybody’s precious time.
> 
> Unfortunately, I think we may be only beginning.
> 
> I have prepared a list of the issues we are tracking with WoSign's
> certificate issuance process and business:
> 
> https://wiki.mozilla.org/CA:WoSign_Issues
> 
> Please can you provide a response to issues F, P, S and T at your
> earliest convenience?
> 
> In addition, if you have further things to say about issues D, H, J, L,
> N or V we would be happy to hear them.
> 
> Thank you for your suggestions, but once Mozilla has a full
> understanding of what has gone on we will be in a better position to
> decide what next actions are appropriate.
> 
> With best wishes,
> 
> Gerv


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Richard Wang]

Hi Gerv, Kathleen and Richard,

This discuss has been lasting two weeks, I think it is time to end it, it 
doesn’t worth to waste everybody’s precious time.
I make my confession that our system and management do have some problems which 
lead to the misissuance of some certificates. And I am very sorry that WoSign 
don’t notify all browsers after the incident happened and even after the 
problem fixed.

I’d like to give my suggestion action for Mozilla as below:
1. Mozilla will trust those SSL certificates only:
(1) The certificate notBefore date is before Jan. 1st 2015;
(2) The certificate notBefore date is from Jan. 1st 2015 to July 4th 2016 
that listed in the Google CT log server;
(3) The certificate notBefore date is from July 5th 2016 to Sept xx 2016 
that embedded SCT data in the certificate;
(4) The certificate notBefore date is from Sept xx 2016 that embedded SCT 
data in the certificate and must have the “C=CN” in the certificate subject.

2. Mozilla can assign a WebTrust auditor to WoSign office to check and inspect 
every incident, check every relevant issued certificate, and record a report 
with:  what happened, why this happened and what is being done to prevent this 
in the future etc., WoSign will pay the audit cost.

I’d like to make some supplements about 1. (4) above, this term means WoSign 
will only issue SSL certificates to China subscribers. 
WoSign issued about 120K SSL certificates for websites in China including many 
central government websites like MIIT and many other local province government 
websites, many university websites, many online banking websites, 6 of the Top 
10 ecommerce websites, big supermarket online store like Walmart, 4 of the Top 
5 cloud service in China, and many big companies that listed in NYSE and 
Nasdaq, and many subsidiaries of foreign countries big companies. 
Those customers like to use WoSign certificate especially our support of 
Chinese, local support and customer service. And some of them paid up to 
10-year certificate fee in advance, we need to renew their certificate for free 
once it is about to expire at every three years for OV SSL.

I wish Mozilla could accept my suggestion, and I am sure WoSign will do it 
better after getting this so big lesson. 
Thank you.


Best Regards,

Richard Wang
CEO
WoSign CA Limited


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Richard Wang
Sent: Sunday, September 4, 2016 5:49 PM
To: Gervase Markham <g...@mozilla.org>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Incidents involving the CA WoSign

Hi all,

We finished the investigation and released the incidents report today: 
https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 

This report has 20 pages, please let me if you still have any questions, thanks.

This report is just for Incident 0-2, we will release a separate report for 
another incident X soon.


Best Regards,

Richard Wang
CEO
WoSign CA Limited


-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Wednesday, August 24, 2016 9:08 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Cc: Richard Wang <rich...@wosign.com>
Subject: Incidents involving the CA WoSign

Dear m.d.s.policy,

Several incidents have come to our attention involving the CA "WoSign".
Mozilla is considering what action it should take in response to these 
incidents. This email sets out our understanding of the situation.

Before we begin, we note that Section 1 of the Mozilla CA Certificate 
Enforcement Policy[0] says: "When a serious security concern is noticed, such 
as a major root compromise, it should be treated as a security-sensitive bug, 
and the Mozilla Policy for Handling Security Bugs should be followed." It is 
clear to us, and appears to be clear to other CAs based on their actions, that 
misissuances where domain control checks have failed fall into the category of 
"serious security concern".

Incident 0
--

On or around April 23rd, 2015, WoSign's certificate issuance system for their 
free certificates allowed the applicant to choose any port for validation. Once 
validation had been completed, WoSign would issue certificates for that domain. 
A researcher was able to obtain a certificate for a university by opening a 
high-numbered port (>50,000) and getting WoSign to use that port for validation 
of control.

This problem was reported to Google, and thence to WoSign and resolved.
Mozilla only became aware of it recently.

* Before the recent passage of Ballot 169 in the CAB Forum, which limits the 
ports and paths which can be used, the Baseline Requirements said that one 
acceptable method of domain validation was "Having the Applicant demonstrate 
practical control over the FQDN by making an agreed‐upon change to information 
found on an online Web page identified by 

RE: Incidents involving the CA WoSign

[Richard Wang]

Thanks for your comment.

For Github case:
1. what happened:  issued the certificate that included un-validated domain, 
and found out this mistake in the next day review, and revoked this 
certificate. 
2. why this happened: this is bug as you described, and due to many orders need 
to review manually, so the first day missed and issued; the next day second 
same order come and found out, then rejected.
3. what is being done to prevent this in the future: We fixed this bug, and we 
changed the github setting from "flag" to "reject" for class 1 and class 2 
order to reduce the manual check mistake.

For Figure 13, this subscriber finished the domain control validation for 
domain: netwi.ru, this means the domain: mail. netwi.ru and mx.netwi.ru are 
validated; and it finished the website control validation for domain: 
mail.idisk.su, so only 1 domain mx.idisk.su not validated. 
We can past the process log screenshot for this order in the next report that 
still preparing.

Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Kurt Roeckx
Sent: Tuesday, September 6, 2016 4:56 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

On 2016-09-05 22:37, Percy wrote:
> In page 11, you mentioned that "System blocked many illegal request every 
> day, the following screen shot is the reject order log", in which you 
> attached a log with Google, Microsoft, QQ domains. Those domains are rejected 
> because of the top domain whitelist. Does that mean those attempts passed 
> your automatic validation and were only rejected because of the whitelist?
>
> And as Kurt pointed out, for the flag, why does it happen only AFTER the 
> certificate is already issued? Since you specifically have the whitelist for 
> topdomains, you would know mis-used of such certs have particularly high 
> impacts.

I think that was a misunderstanding on my part. In the other e-mail I send I 
came to the conclusion that what probably happened was that they were flagged 
for manual review and approved. And so that there really is something wrong 
with the manual review process. Their solution to that was to move "github.com" 
from manual review to reject.

The document really is hard to follow and seems to more concentrate on 
defending themselves, how fast they are and show that they do prevent some 
certificates from being issued. What I'm looking for is just the facts of what 
happened, why this happened, what is being done to prevent this in the future.

My current understanding of what happened with the github.com case is:
- It's possible that the list of hostnames is changed between the point of 
validation and the user pressed the "submit request" button.  This change can 
be caused by both the software adding other hostnames itself, or the user 
adding new hostnames.  I understand that when the user pressed the button a CSR 
is generated.
- Once the CSR is generated, it's trusted that the list of hostnames in it have 
been validated, which might not be the case.
- Because gibhub.com is in the list of hostnames that needs to be checked, it's 
flagged for review.
- The manual review just approved it.

What I think is wrong:
- There is no check that the hostnames have been validated after the CSR has 
been generated.
- Too many github.com certificates get flagged for manual review causing the 
reviewers to not look careful and just approve it.  The fix they used is to 
reject "github.com" itself instead of flagging it for review. 
  They should probably also flag less things for review (probably after talking 
to github.)


Looking at Figure 13, the first entry says it has 4 SANs in it, but claims only 
1 was validated and 1 was not validated, what happened to the other 2?


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

[Richard Wang]

The first email is the guy found the problem, the second email is asking for 
revocation to related person that he/she can't do it.

Sure, we have CMS (Certificate Management System), every order is processed in 
the system by the proper duty person.  See Figure 8, the top menu is
Order Info, personal info, proof documents, processing log, order remark, 
domain validation log
That we just display the menu "processing log" in the screenshot to show all 
process event like shipping tracking system.

I am sorry that we are busy with the second report that maybe can't reply all 
inquiry email. Some question will be replied in the second report.


Best Regards,

Richard

-Original Message-
From: Kurt Roeckx [mailto:k...@roeckx.be] 
Sent: Monday, September 5, 2016 1:34 AM
To: Richard Wang <rich...@wosign.com>
Cc: Gervase Markham <g...@mozilla.org>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

On Sun, Sep 04, 2016 at 09:49:25AM +, Richard Wang wrote:
> Hi all,
> 
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf

In section 2.2 you explain that there is a mail at 9:01 and 9:38, where I think 
the one from 9:38 asks for the revocation of the certificates by e-mail. Is 
there a procedure in place that those e-mails get acted upon? Why is this done 
via e-mail and not some some other system that can make sure it's being 
followed up?


Kurt

___
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

[Richard Wang]

Hi all,

We finished the investigation and released the incidents report today: 
https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 

This report has 20 pages, please let me if you still have any questions, thanks.

This report is just for Incident 0-2, we will release a separate report for 
another incident X soon.


Best Regards,

Richard Wang
CEO
WoSign CA Limited


-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Wednesday, August 24, 2016 9:08 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Cc: Richard Wang <rich...@wosign.com>
Subject: Incidents involving the CA WoSign

Dear m.d.s.policy,

Several incidents have come to our attention involving the CA "WoSign".
Mozilla is considering what action it should take in response to these 
incidents. This email sets out our understanding of the situation.

Before we begin, we note that Section 1 of the Mozilla CA Certificate 
Enforcement Policy[0] says: "When a serious security concern is noticed, such 
as a major root compromise, it should be treated as a security-sensitive bug, 
and the Mozilla Policy for Handling Security Bugs should be followed." It is 
clear to us, and appears to be clear to other CAs based on their actions, that 
misissuances where domain control checks have failed fall into the category of 
"serious security concern".

Incident 0
--

On or around April 23rd, 2015, WoSign's certificate issuance system for their 
free certificates allowed the applicant to choose any port for validation. Once 
validation had been completed, WoSign would issue certificates for that domain. 
A researcher was able to obtain a certificate for a university by opening a 
high-numbered port (>50,000) and getting WoSign to use that port for validation 
of control.

This problem was reported to Google, and thence to WoSign and resolved.
Mozilla only became aware of it recently.

* Before the recent passage of Ballot 169 in the CAB Forum, which limits the 
ports and paths which can be used, the Baseline Requirements said that one 
acceptable method of domain validation was "Having the Applicant demonstrate 
practical control over the FQDN by making an agreed‐upon change to information 
found on an online Web page identified by a uniform resource identifier 
containing the FQDN". This method therefore did not violate the letter of the 
BRs. However, Mozilla considers the basic security knowledge that ports over 
1024 are unprivileged should have led all CAs not to accept validations of 
domain control on such ports, even when not documented in the BRs.

* The misissuance incident was not reported to Mozilla by WoSign as it should 
have been (see above).

* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].

Incident 1
--

In June 2015, an applicant found a problem with WoSign's free certificate 
service, which allowed them to get a certificate for the base domain if they 
were able to prove control of a subdomain.

The reporter proved the problem in two ways. They accidentally discovered it 
when trying to get a certificate for med.ucf.edu and mistakenly also applied 
for www.ucf.edu, which was approved. They then confirmed the problem by using 
their control of theiraccount.github.com/theiraccount.github.io to get a cert 
for github.com, github.io, and www.github.io.

They reported this to WoSign, giving only the Github certificate as an example. 
That cert was revoked and the vulnerability was fixed. However recently, they 
got in touch with Google to note that the ucf.edu cert still had not been 
revoked almost a year later.

* The lack of revocation of the ucf.edu certificate (still unrevoked at time of 
writing, although it may have been by time of posting) strongly suggests that 
WoSign either did not or could not search their issuance databases for other 
occurrences of the same problem. Mozilla considers such a search a basic part 
of the response to disclosure of a vulnerability which causes misissuance, and 
expects CAs to keep records detailed enough to make it possible.

* This misissuance incident was not reported to Mozilla by WoSign as it should 
have been (see above).

* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].

Incident 2
--

In July 2016, it became clear that there was some problems with the 
StartEncrypt automatic issuance service recently deployed by the CA StartCom. 
As well as other problems it had, which are outside the scope of this 
discussion, changing a simple API parameter in the POST request on the 
submission page changed the root certificate to which the resulting certificate 
chained up. The value "2" made a certificate signed by "StartCom Class 1 DV 
Server CA", "1" selected "WoSign CA Free SSL Certificate G2" and "0" selected 
"CA 沃通根证书", another root certificate owned by WoSign an

Re: Incidents involving the CA WoSign

[Richard Wang]

It is posted, just Peter not find it that I told him the   Log id.

We are also checking system again to double check if we missed some.

Please be patient for our full 20 pages report, thanks,

Regards,

Richard

> On 4 Sep 2016, at 12:12, Matt Palmer  wrote:
> 
>> On Sat, Sep 03, 2016 at 02:18:44PM -0700, Peter Bowen wrote:
>> Can you also please check the following two certificates?  It looks
>> like they were missed when logging all the 2015 certs.
>> 
>> https://www.censys.io/certificates/c04748c89de2bf73d56b601cf61db32953dfeca5ef62e0281d326c4ce9035fe2
>> https://www.censys.io/certificates/d99309f071141454f805c13551a827aa116bb53daefd8609e296c06b0dcdf720
>> 
>> Additionally, it looks like there may be a gap in logging for 2016.
>> For example, 
>> https://www.censys.io/certificates/06797f8095ba4d9c9ec5b9475cff7df3b258069cc89f303cd91dc329eaf0c08f
>> does not show up in any log.
> 
> Our of curiosity, is anyone keeping a tally of the number of times WoSign
> has said, "yep, they're all logged now", only to have more unlogged
> certificates turn up?  This is starting to feel like a bit of a repeat of
> DigiNotar, insofar as a CA doesn't appear to have a clear record of all
> issuance.
> 
> - Matt
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Richard Wang]

This is another case that we will include it in our report.
We issued two test cert using SM2 algorithm that used the same serial number as 
the RSA cert (same subject) to test if we can setup a gateway that install this 
two type cert, it can shake hand automatically using different cert based on 
the browser algorithm support.

Regards,

Richard

> On 4 Sep 2016, at 12:49, Peter Bowen <pzbo...@gmail.com> wrote:
> 
>> On Thu, Sep 1, 2016 at 9:00 AM, Ryan Sleevi <r...@sleevi.com> wrote:
>>> On Wed, August 31, 2016 10:09 pm, Richard Wang wrote:
>>> Thanks for your so detail instruction.
>>> Yes, we are improved. The two case is happened in 2015 and the mis-issued
>>> certificate period is only 5 months that we fixed 3 big bugs during the 5
>>> months.
>>> For CT, we will improve the posting system.
>> 
>> I had a little trouble parsing this, but let's make sure we're on the same
>> page. I've continued Gerv's original numbering:
>> 
>> Incident -2: 16 January 2015 - 5 March 2015 - 1,132 BR-violating SHA-1
>> certificates ( https://cert.webtrust.org/SealFile?seal=2019=pdf )
>> Incident -1: April 4, 2015 - WoSign is informed it's routinely violating
>> its CPS for issued certificates (
>> https://www.wosign.com/policy/wosign-policy-1-2-10.pdf )
>> Incident X: April 9 - April 14, 2015 - 392 duplicate serial numbers
>> Incident 0: April 23, 2015 - 72 potentially dangerous port-validated
>> certificates
>> Incident 1: June, 2015 - 33 unvalidated base-domain from sub-domain
>> certificates
>> Incident 2: July, 2016 - At least 1 backdated SHA-1 certificate (was this
>> the only one? I wasn't clear from
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ
>> )
> 
> It was brought to my attention that there is another incident.  WoSign
> issued at least two certificates that have subject public keys which
> are for the SM2 algorithm.  SM2 is an elliptic curve based algorithm
> but it does not use the US NIST P-256, P-384, or P-512 curves.  The
> CA/Browser Forum Baseline Requirements and Mozilla CA Certificate
> Maintenance Policy both require that only these three curves be used
> for elliptic curve keys.
> 
> In addition to including subjects keys using unapproved parameters, it
> seems these each share their serial number with another certificate
> for the same subject.  So these are two more cases of duplicate serial
> numbers for different content.
> 
> The log entries for the SM2 certificates are
> https://ctlog.wosign.com/ct/v1/get-entries?start=109239=109240;
> crt.sh doesn't have them.  The matching serial numbers are
> https://crt.sh/?id=30613201 and https://crt.sh/?id=30613200.
> 
> Thanks,
> Peter


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Richard Wang]

Sorry, I am busy with incident report that up to 20 pages.
It will be released soon today.

Two reports: one for the incident 0-2, another one is for incident X including 
you point out one.


Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Sunday, September 4, 2016 5:19 AM
To: Richard Wang <rich...@wosign.com>
Cc: Ryan Sleevi <r...@sleevi.com>; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Richard,

Can you also please check the following two certificates?  It looks like they 
were missed when logging all the 2015 certs.

https://www.censys.io/certificates/c04748c89de2bf73d56b601cf61db32953dfeca5ef62e0281d326c4ce9035fe2
https://www.censys.io/certificates/d99309f071141454f805c13551a827aa116bb53daefd8609e296c06b0dcdf720

Additionally, it looks like there may be a gap in logging for 2016.
For example, 
https://www.censys.io/certificates/06797f8095ba4d9c9ec5b9475cff7df3b258069cc89f303cd91dc329eaf0c08f
does not show up in any log.

Thanks,
Peter

On Fri, Sep 2, 2016 at 8:31 AM, Richard Wang <rich...@wosign.com> wrote:
> We will check this tomorrow.
> Now our time is 23:32 at night.
>
>
> Regards,
>
> Richard
>
>> On 2 Sep 2016, at 23:20, Peter Bowen <pzbo...@gmail.com> wrote:
>>
>>> On Fri, Sep 2, 2016 at 8:11 AM, Richard Wang <rich...@wosign.com> wrote:
>>> Yes, we posted all 2015 issued SSL from WoSign trusted root.
>>>
>>>> On 2 Sep 2016, at 22:55, Peter Bowen <pzbo...@gmail.com> wrote:
>>>> Based on CT logs, I have seen certificates from the CAs below, all 
>>>> of which have "WoSign" in the name.  Have you logged all 
>>>> certificates which are signed by these CAs and have a notBefore 
>>>> date of 2015010100Z or later to the WoSign CT log?
>>
>> Richard,
>>
>> It seems then there is a newly exposed bug.
>> https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf578
>> 1edbe9d78f9cada8f1d702d5e340ad shows a certificate issued by your CA 
>> that has a notBefore in March 2015.  It does not appear in the CT 
>> log.  However another certificate with identical serial number and 
>> subject, but different Validity, does appear in the log.
>>
>> Are you aware of a bug where you were issuing certificates identical 
>> except for validity period?
>>
>> Thanks,
>> Peter
___
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

[Richard Wang]

From the screenshot, we know why Percy hate WoSign so deeply, we know he 
represent which CA, everything is clear now.

BTW, as I said that the two related pages in our website are deleted. 

Regards,

Richard

> On 3 Sep 2016, at 02:16, Percy  wrote:
> 
>> On Friday, September 2, 2016 at 3:07:46 AM UTC-7, Gervase Markham wrote:
>> as others have pointed out in this thread, WoSign is very happy to be seen 
>> as a
>> China CA for marketing purposes inside China.
> 
> WoSign in fact actively emphasis that it's a China CA and the global politics 
> in marketing. WoSign claimed foreign CA might revoke certs to Chinese orgs 
> due to politics and claimed that foreign CA will collect all users 
> information.  This is a typical marketing email they sent.  
> https://pbs.twimg.com/media/CrXf7w3W8AA2zd7.jpg:large Translated below.
> ---
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Richard Wang]

We will check this tomorrow.
Now our time is 23:32 at night.


Regards,

Richard

> On 2 Sep 2016, at 23:20, Peter Bowen <pzbo...@gmail.com> wrote:
> 
>> On Fri, Sep 2, 2016 at 8:11 AM, Richard Wang <rich...@wosign.com> wrote:
>> Yes, we posted all 2015 issued SSL from WoSign trusted root.
>> 
>>> On 2 Sep 2016, at 22:55, Peter Bowen <pzbo...@gmail.com> wrote:
>>> Based on CT logs, I have seen certificates from the CAs below, all of
>>> which have "WoSign" in the name.  Have you logged all certificates
>>> which are signed by these CAs and have a notBefore date of
>>> 2015010100Z or later to the WoSign CT log?
> 
> Richard,
> 
> It seems then there is a newly exposed bug.
> https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf5781edbe9d78f9cada8f1d702d5e340ad
> shows a certificate issued by your CA that has a notBefore in March
> 2015.  It does not appear in the CT log.  However another certificate
> with identical serial number and subject, but different Validity, does
> appear in the log.
> 
> Are you aware of a bug where you were issuing certificates identical
> except for validity period?
> 
> Thanks,
> Peter


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Richard Wang]

Yes, we plan to post to one of the Google log server tommorrow.

Regards,

Richard

> On 2 Sep 2016, at 22:54, Peter Bowen <pzbo...@gmail.com> wrote:
> 
>> On Fri, Sep 2, 2016 at 12:37 AM, Richard Wang <rich...@wosign.com> wrote:
>> We finished the CT posting, all 2015 issued SSL certificate is posted to 
>> WoSign CT log server: https://ctlog.wosign.com, total 101,410 certificates.
> 
> Richard,
> 
> Based on CT logs, I have seen certificates from the CAs below, all of
> which have "WoSign" in the name.  Have you logged all certificates
> which are signed by these CAs and have a notBefore date of
> 2015010100Z or later to the WoSign CT log?
> 
> Do you also plan to submit these to at least one Google-operated log?
> 
> Thanks,
> Peter


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Richard Wang]

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Friday, September 2, 2016 6:07 PM
To: Richard Wang <rich...@wosign.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

> And, as others have pointed out in this thread, WoSign is very happy to be 
> seen as a China CA for marketing purposes inside China.

We deleted the related two pages.

Best Regards,

Richard
___
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

[Richard Wang]

You mean if a Chinese, a Chinese company own a USA CA, then the USA CA become 
un-trustworthiness?

I still think this topic is out of THE Topic - Incident.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Matt Palmer
Sent: Friday, September 2, 2016 4:51 PM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

On Fri, Sep 02, 2016 at 06:53:23AM +, Richard Wang wrote:
> I think we are out of topic.

On the contrary, the trustworthiness of CAs is *entirely* on topic.

- Matt

___
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

[Richard Wang]

Please remember this sentence:
Every re-distribution the wrong information will heavy his penalty (including 
site cache or mirror site).  

You are harming him! 


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Percy
Sent: Friday, September 2, 2016 2:23 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign



On Thursday, September 1, 2016 at 11:01:08 PM UTC-7, Richard Wang wrote:
> OK I try to say some that I wish I don't violate my company confidential 
> policy.
> 
> 1. Eddy told me that this guy is the former employee of StartCom, he violates 
> the signed NDA that he must shutdown the site within the limit time. Every 
> re-distribution the wrong information will heavy his penalty (including site 
> cache or mirror site).  I am sure every company don't like its former 
> employee to expose company's confidential information.
> 

NDA only applies for information that's privileged. The content here 
https://archive.is/8bSp6 can be obtained all from public sources, hence 
exempted from NDA. 

In case WoSign tries to send take down request to Achieve.is, I mirrored the 
content on pastebin too http://pastebin.com/hiKxmGMH Good luck taking that 
down. 


> 2. WoSign invested in 5 companies worldwide including in North America, 
> Europe and Asia (China), but my company is a private company that no any 
> liability to expose everything that we don't like to expose. And Mozilla also 
> don't have the policy that every CA must expose its shareholder and director.
> 
Sure, your company is a private company. But the public doesn't have an 
obligation to trust you either. 


> 3. Please don't bind WoSign incident problem with StartCom, it is two 
> independent company that one registered in China and one located in Israel. 
> StartCom and WoSign have maintained a business relationship for many years 
> since 2011 when WoSign startup CA business. And WoSign root is cross signed 
> by StartCom root due to the problem that root inclusion took long time.
> 

Two independent companies that share the same infrastructure, director and user 
trust according to https://archive.is/8bSp6 , doesn't look very independent to 
me. 

> 
> Best Regards,
> 
> Richard
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign.com@lists.mozilla.o
> rg] On Behalf Of Peter Gutmann
> Sent: Friday, September 2, 2016 11:59 AM
> To: Vincent Lynch <vtly...@gmail.com>; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Incidents involving the CA WoSign
> 
> Vincent Lynch <vtly...@gmail.com> writes:
> 
> >I think Eddy Nigg (founder of StartCom) and/or Richard Wang (of 
> >WoSign) should make a statement about this.
> 
> +1.  I'd already asked for something like this earlier and got silence 
> +as a
> response, which isn't inspiring confidence.
> 
> Peter.
> ___
> 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

[Richard Wang]

OK I try to say some that I wish I don't violate my company confidential policy.

1. Eddy told me that this guy is the former employee of StartCom, he violates 
the signed NDA that he must shutdown the site within the limit time. Every 
re-distribution the wrong information will heavy his penalty (including site 
cache or mirror site).  I am sure every company don't like its former employee 
to expose company's confidential information.

2. WoSign invested in 5 companies worldwide including in North America, Europe 
and Asia (China), but my company is a private company that no any liability to 
expose everything that we don't like to expose. And Mozilla also don't have the 
policy that every CA must expose its shareholder and director.

3. Please don't bind WoSign incident problem with StartCom, it is two 
independent company that one registered in China and one located in Israel. 
StartCom and WoSign have maintained a business relationship for many years 
since 2011 when WoSign startup CA business. And WoSign root is cross signed by 
StartCom root due to the problem that root inclusion took long time.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Peter Gutmann
Sent: Friday, September 2, 2016 11:59 AM
To: Vincent Lynch <vtly...@gmail.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Incidents involving the CA WoSign

Vincent Lynch <vtly...@gmail.com> writes:

>I think Eddy Nigg (founder of StartCom) and/or Richard Wang (of WoSign) 
>should make a statement about this.

+1.  I'd already asked for something like this earlier and got silence 
+as a
response, which isn't inspiring confidence.

Peter.
___
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