Re: Google Trust Services Root Inclusion Request

m 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 mak

RE: Re: Google Trust Services Root Inclusion Request

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

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

ssage 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

RE: Re: Google Trust Services Root Inclusion Request

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

RE: Remove old WoSign root certs from NSS

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

RE: Remove old WoSign root certs from NSS

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

RE: Microsoft to remove WoSign and StartCom certificates in Windows 10

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,

RE: StartCom cross-signs disclosed by Certinomis

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

RE: WoSign new system passed Cure 53 system security audit

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 R

Re: WoSign new system passed Cure 53 system security audit

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

Re: WoSign new system passed Cure 53 system security audit

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)

Re: WoSign new system passed Cure 53 system security audit

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 > wrote:

Re: WoSign new system passed Cure 53 system security audit

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 >

RE: WoSign new system passed Cure 53 system security audit

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

RE: WoSign new system passed Cure 53 system security audit

> > 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? > > > >

RE: WoSign new system passed Cure 53 system security audit

7 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 interes

RE: WoSign new system passed Cure 53 system security audit

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

RE: Symantec Conclusions and Next Steps

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 experience we suffered from distrust, it is disastrous for CA and its customers to replace the cert

RE: Symantec Conclusions and Next Steps

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

RE: Criticism of Google Re: Google Trust Services roots

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

RE: Criticism of Google Re: Google Trust Services roots

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:

RE: Google Trust Services roots

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-

Re: Google Trust Services roots

Clear, thanks. Best Regards, Richard > On 9 Mar 2017, at 22:05, Gervase Markham via dev-security-policy > 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

Re: Google Trust Services roots

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

RE: Google Trust Services roots

oot'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-reg

RE: Google Trust Services roots

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? O

RE: Google Trust Services roots

? 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 r

RE: Google Trust Services roots

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

Re: 360 team hacks Chrome

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

360 team hacks Chrome

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

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

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

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

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

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

omain 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 > identi

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

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

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

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

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

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

RE: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

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,

RE: Google Trust Services roots

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