Re: StartCom inclusion request: next steps

[Percy via dev-security-policy]

"Conclusion: StartCom's attempt to restart the CA was rushed."

"It was a very hard task in very few time but the people at 360 tried 
everything to get it done by that date, end of december 2016, and yes, we 
reached the date but with many failures"

May I ask why StartCom choose to rush everything in PHP from the ground up 
rather than using the more secure system already in place in the old StartCom?  
From my understanding, the distrust of StartCom is more related to the secret 
acquisition by  WoSign an Qihoo 360 rather than insecure infrastructure. So if 
the deadline is so imminent as you stated and pressure is so high from 
customers, can't you use the reasonably secure old code base rather than 
rushing everything from the ground up? Then you will have more time transition 
to another system if needed with sufficient time for secure processes?
___
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

[Percy via dev-security-policy]

On Wednesday, August 30, 2017 at 11:15:04 AM UTC-7, Kathleen Wilson wrote:
> Posted:
> 
> https://blog.mozilla.org/security/2017/08/30/removing-disabled-wosign-startcom-certificates-firefox-58/
> 
> I will look into getting this translated and published in China.
> 
> Thanks,
> Kathleen

Thank you so much for taking Chinese users into consideration! 
___
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

[Percy via dev-security-policy]

links to all of WoSign's announcement in case anyone want to verify.
https://www.wosign.com/news/index.htm  year 2017
https://www.wosign.com/news/index2016.htm year 2016
___
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

[Percy via dev-security-policy]

In fact, can you tell us, when was the first time WoSign started to notify 
users about replacing certs?  

I've dig through all of WoSign's announcement and the first and in fact the 
ONLY announcement regarding replacing certs is dated July 10th, 2017 , titled 
Announcement regarding Google's decision on July 7th".  During Sept 19, 2016 to 
July 10th 2017, WoSign posted a total of 19 announcements, including 
announcements like mountain hiking competition in Youth Day, trips to Yangtze 
River Delta, Wosign's professional services won customers' acknowledgment.   

Of course your customers might be unable to replace certs in time if you only 
notified them July this year while browser announcement such decisions in Oct 
last year!
___
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

[Percy via dev-security-policy]

It's true that the first post has a link to that second post. However, the 
related sentence is 

To learn more, please visit "Announcement regarding Google's decision on July 
7th", with a hyperlink to the second post. 

And only the second post mentions anything about replacing certs. I hardly 
think users would understand they are risking being blocked by major browsers 
from such a benign looking sentence. 
___
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

[Percy via dev-security-policy]

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

Re: Remove old WoSign root certs from NSS

[Percy via dev-security-policy]

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-wosign-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-and-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

Microsoft to remove WoSign and StartCom certificates in Windows 10

[Percy via dev-security-policy]

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

Re: StartCom cross-signs disclosed by Certinomis

[Percy via dev-security-policy]

On Monday, August 7, 2017 at 2:36:10 PM UTC-7, Itzhak Daniel wrote:
> 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?
> 
> Links:
> 1. https://www.letsphish.org/files/StartCom-CA-SPA-Appointment.pdf
> 2. https://www.letsphish.org/files/StartCom-CA-SPA-Profile.pdf
> 3. https://beta.companieshouse.gov.uk/company/09744347

StartCom CA Spain Sociedad Limitada was not in the original hierarchy [1] or 
the proposed hierarchy [2] . I request that StartCom makes a full disclosure of 
the ownership information. 

In addition, in the WoSign remediation plan, WoSign Stated[3] that 

Due to the severity of issues noted within, the decision has been made to 
address the above three areas as they fall under the areas of 1) 
leadership/authority in WoSign and StartCom, 2) operational/business process 
and 3) technology. 

If WoSign/Startcom has determined leadership/authority is the No.1 cause of 
issues, why is Richard Wang appointed as a director of StartCom merely 6 month 
after his removal? This doesn't even mention his COO role at WoSign. 

[1] 
https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/startcom%7Csort:relevance/mozilla.dev.security.policy/0pqpLJ_lCJQ/z69lmZ88DwAJ
[2]https://en.wikipedia.org/wiki/StartCom#cite_note-structure201612-9
[3]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

Re: Remove old WoSign root certs from NSS

[Percy via dev-security-policy]

On Thursday, August 3, 2017 at 3:55:34 PM UTC-7, Kathleen Wilson wrote:
> On Monday, July 10, 2017 at 12:47:31 PM UTC-7, Kathleen Wilson wrote:
> > I also think we should remove the old WoSign root certs from NSS.
> > 
> > Reference:
> > https://wiki.mozilla.org/CA/Additional_Trust_Changes#WoSign
> > ~~
> > Mozilla currently recommends not trusting any certificates issued by this 
> > CA after October 21st, 2016. That recommendation covers the following roots:
> > 
> > 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
> > 
> > This restriction has been implemented in both in the Mozilla platform 
> > security code (PSM), which is shared by the Mozilla applications (Firefox, 
> > Thunderbird, etc.), and in addition, in the NSS library code, which is used 
> > by applications that use the NSS certificate verification APIs. 
> > ~~
> > 
> > Please let me know if you foresee any problems with removing these root 
> > certs from NSS.
> > 
> > Thanks,
> > Kathleen
> 
> 
> I have filed Bug #1387260 to remove the old WoSign root certificates. This 
> will likely happen in the October batch of root changes.
> 
> Kathleen

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

[Percy via dev-security-policy]

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

Is there a design outline in the security audit as well? No one in the 
community can judge either yours or WoSign's statement as this information is 
not shared with us. I suggest either WoSign or Mozilla/Google share such 
information with the community if it's not under NDA. Otherwise, this 
discussion is rather unproductive as we have crucial information missing.
___
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

[Percy via dev-security-policy]

On Tuesday, July 11, 2017 at 8:16:50 AM UTC-7, Jonathan Rudenberg wrote:
> > On Jul 11, 2017, at 06:53, okaphone.elektronika--- via dev-security-policy 
> >  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=8BDFE4A526BFB35C8A417B10F4D0ABE9E1D60D28A412539D5BC71C19B46FEF21
> https://crt.sh/?opt=cablint=124AAD38DAAC6B694D65F45226AB5152FC46D229CBC203E0814D175F39977FF3
> https://crt.sh/?opt=cablint=9B78C78B32F4AC717B3DEFDABDACC4FEFA61BFD17782B83F75ADD82241147721
> https://crt.sh/?opt=cablint=AAB0B5A08F106639A5C9D720CD37FDB30E7F337AEBAF9407FD854B5726303F7B
> https://crt.sh/?opt=cablint=9DCE6A924CE837328D379CE9B7CDF4A2BA8A0E8EC01018B9DE736EBC64442361
> https://crt.sh/?opt=cablint=62A9A9FDCDC04A043CF2CB1A5EAFE33CF9ED8796245DE4BD5250267ADEFF005A
> https://crt.sh/?opt=cablint=6A72FA5DCC253D2EE07921898B9A9BB263FD1D20FE61B1F52F939C0C1C0DCFEE
> https://crt.sh/?opt=cablint=238E2E96665748D2A05BAAEEC8BAE6AFE7B7EF4B1ADA4908354C855C385ECD81
> https://crt.sh/?opt=cablint=C11C00EB0E14EEB30567D749FFD30445E0B490D1DCA7B7E082FD1CB0A40A71C0
> https://crt.sh/?opt=cablint=4DEF4CFD21A969E8349E4428FDEC73767C01DE6127843312511B71029F4E3836

I guess such mis-issurances are not covered by this security audit as the entry 
are done internally. But I hope that WoSign release the full security audit so 
that this community can evaluate objectively, rather than rely on so called 
summary.
___
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

[Percy via dev-security-policy]

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 
> Cc: Itzhak Daniel ; 
> 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 
> >
>  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=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
> 
> 
> 
> 
> 
> 
> 
>--
> 
>konklone.com | 
> @konklone

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

Re: StartCom continues to sell untrusted certificates

[Percy via dev-security-policy]

On Monday, May 1, 2017 at 7:49:32 AM UTC-7, Henri Sivonen wrote:
> On Mon, May 1, 2017 at 11:31 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > On 01/05/17 07:52, Percy wrote:
> >> It seems that StartCom continues to sell untrusted certs. Neither their
> home page https://www.startcomca.com/ nor their announcement page
> https://www.startcomca.com/index/news mentions that those certs are not
> trusted.
> >
> > Why is this something that Mozilla should be concerned with?
> >
> > "Selling untrusted certs" is not a crime, or a violation of any
> > standard. Mozilla is not the global authority on what certificates may
> > be issued. If StartCom are providing certificates which do not do what
> > their customers expect, I'm sure those customers will let them know
> > about it soon enough.
> 
> What StartCom claims about compatibility is potentially more
> Mozilla-relevant than what they are silent about. At the bottom of their
> front page, it says "StartCom™ / StartSSL™is supported by:" followed by
> icons. The icons include an early icon for Camino and the SeaMonkey icon.
> Since Camino was discontinued before Mozilla's change in trust in StartCom
> certificates, I guess having Camino there isn't technically incorrect, but
> is about as relevant as having the Flock icon there. However, is it correct
> to have the SeaMonkey icon there? The latest SeaMonkey release seems to
> post-date the Mozilla root program's trust change in StartCom certificates.
> (But then, it seems that there have been a number of Firefox ESR security
> patch releases that post-date the SeaMonkey release. Is SeaMonkey still
> active, despite appearing not to ship Gecko security updates, and does
> SeaMonkey implement the same trust special-casing as Firefox? It seems to
> produce nightlies still.)
> 
> -- 
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/

Ha, it seems that they removed those icons in response to your comments. Now 
they only list Edge, IE, Android and windows.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

StartCom continues to sell untrusted certificates

[Percy via dev-security-policy]

It seems that StartCom continues to sell untrusted certs. Neither their home 
page https://www.startcomca.com/ nor their announcement page 
https://www.startcomca.com/index/news mentions that those certs are not 
trusted. 
___
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

[Percy via dev-security-policy]

On Friday, April 28, 2017 at 1:19:01 AM UTC-7, Richard Wang wrote:
> 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.
> 

This is not what you said. You said "Mozilla’s sanctions are too severe" 
-https://www.wosign.com/english/News/announcement_about_Mozilla_Action_20161024.htm
> 
> 
> 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.
> 

Since all the certs are supposedly included in the cert transparency already, 
would you able to share what apps pinned your certs with the certs?  Of only a 
handful of banking related apps included in the apps, I haven't seen any 
failure because of pinning. In fact, why would the Chrome distrust cause the 
failure in pinning in the app? 
> 
> 
> 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.
> 

Could you point to a Microsoft announcement that points to removal of WoSign 
certs? In fact, Microsoft explicitly said WoSign/StartCom is trusted. 
https://social.technet.microsoft.com/wiki/contents/articles/37425.microsoft-trusted-root-certificate-program-participants-as-of-march-9-2017.aspx
 (as of March 9, 2017)

> 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 

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

[Percy]

On Sunday, December 18, 2016 at 5:45:16 PM UTC-8, 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
> 
> -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

I found WoSign's explanation completely incredulous.  

WoSign has been sending **unsolicited** marketing emails to websites that use 
Let's Encrypt cert essentially saying Let's Encrypt might revoke cert at will 
and ask users to switch to WoSign (Email attached). After I posted on the forum 
about this, WoSign stated "From the screenshot, we know why Percy hate WoSign 
so deeply, we know he represent which CA[Let's Encrypt], everything[about all 
those incidents surrounding WoSign that led to its distrust] is clear now. " 
(https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/IxnAbfFGDQAJ)

I find it hard to believe that if WoSign thought Let's Encrypt is a company 
that will send troll to undermine WoSign, WoSign would register Let's Encrypt's 
domain to protect Let's Encrypt's trademark. (Admittedly, WoSign's accusation 
of me came later but I'm assuming his attitudes towards Let's Encrypt is the 
same over the years). 

-
This is a typical unsolicited marketing email they sent to Let's Encrypt users. 
 https://pbs.twimg.com/media/CrXf7w3W8AA2zd7.jpg:large Translated below.
---
Dear friend:
I'm *** from WoSign CA. WoSign is the first SSL cert company in China. Your 
website *'s SSL cert is from Let's Encrypt, expiring at Oct, 2016. If you 
switch to WoSign before the expiration you can enjoy buy one year get one year 
free.

The risks associated with foreign CA:
1. Cert revocation
If foreign CA is influenced by politics and revoke c

Please restrict/remove WoSign and StartCom CA from Android

[Percy]

WoSign and StartCom has been included as root CA in official Android builds. 
(https://code.google.com/p/android/issues/detail?id=71363 
https://code.google.com/p/android/issues/detail?id=21632)

Apple has restrict/remove WoSign and StartCom from iOS 10.2.  "Google has 
determined that two CAs, WoSign and StartCom, have not maintained the high 
standards expected of CAs and will no longer be trusted by Google Chrome, in 
accordance with our Root Certificate Policy. " The announcement didn't say 
anything about Android. Is there any plan to restrict remove WoSign and 
StartCom from Android?
___
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

[Percy]

Well, based on the previous deception of WoSign before, during and after 
Mozilla's investigation, I'm not remotely surprised to see this. 


On Friday, December 16, 2016 at 10:18:27 AM UTC-8, tde...@gmail.com wrote:
> 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

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

[Percy]

On Wednesday, December 14, 2016 at 8:29:24 PM UTC-8, zbw...@gmail.com wrote:
> 在 2016年12月15日星期四 UTC+8上午9:53:29，Percy写道：
> > lslqtz,
> > Could you host a subdomain say wosign.loliwiki.org with this cert? So we 
> > can test the blocking is functioning correctly.
> 
> I was pulled into the black list.

What do you mean? Are you the original poster?
___
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.

[Percy]

lslqtz,
Could you host a subdomain say wosign.loliwiki.org with this cert? So we can 
test the blocking is functioning correctly. 
___
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.

[Percy]

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

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

[Percy]

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

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

[Percy]

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

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

[Percy]

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

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

[Percy]

lslqtz,
How did you obtain this certificate from WoSign? Through the public website or 
some other means?
___
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.

[Percy]

On the WoSign website https://buy.wosign.com/free/?lan=en , it clearly states 
that "Sorry, due to some security consideration, 
WoSign decide to close the free SSL certificate application temporarily. Sept. 
29th 2016."
___
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

[Percy]

On Tuesday, November 15, 2016 at 12:37:56 AM UTC-8, Thijs Alkemade wrote:
> On 13 Nov 2016, at 10:08, Percy <percyal...@gmail.com> 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.
> 
> Hi Percy,
> 
> I’ve been following Apple’s security updates to determine when the announced 
> block becomes active and how it is implemented. Using 10.11.6, with no 
> updates available, it appears this block is not yet active for me. There are 
> no errors when I try to visit https://inow.ua in Safari 
> (https://crt.sh/?id=43120524 appears to be the last certificate issued by 
> "WoSign CA Free SSL Certificate G2” which is currently still in use). In the 
> file 
> /System/Library/Security/Certificates.bundle/Contents/Resources/Allowed.plist 
> I only see two CINNIC roots listed.
> 
> Could you tell us what OS and version you used to determine that Apple has 
> limited "WoSign CA Free SSL Certificate G2”?
> 
> Best regards,
> Thijs Alkemade

You can also check this thread 
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/ZFOZCFW4K-s 
Ryan pointed out that the whitelist has been implemented in the newest version
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Percy]

On Wednesday, August 3, 2016 at 2:45:23 PM UTC-7, Kathleen Wilson wrote:
> This request from Guangdong Certificate Authority (GDCA) is to include the 
> "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and 
> enabled EV treatment.
> 
> GDCA is a nationally recognized CA that operates under China’s Electronic 
> Signature Law. GDCA’s customers are business corporations registered in 
> mainland China, government agencies of China, individuals or mainland China 
> citizens, servers of business corporations which have been registered in 
> mainland China, and software developers.
> 
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1128392
> 
> And in the pending certificates list:
> https://wiki.mozilla.org/CA:PendingCAs
> 
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=8749437
> 
> Noteworthy points:
> 
> * Root Certificate Download URL:
> https://bugzilla.mozilla.org/attachment.cgi?id=8748933
> https://www.gdca.com.cn/cert/GDCA_TrustAUTH_R5_ROOT.der
> 
> * The primary documents are provided in Chinese.
> 
> CA Document Repository: 
> https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/
> http://www.gdca.com.cn/cp/cp
> http://www.gdca.com.cn/cps/cps
> http://www.gdca.com.cn/cp/ev-cp
> http://www.gdca.com.cn/cps/ev-cps
> 
> Translations into English:
> CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
> CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749
> 
> * CA Hierarchy: This root certificate has internally-operated subordinate CAs
> - GDCA TrustAUTH R4 SSL CA (issues 2048-bit SSL certs)
> - GDCA TrustAUTH R4 Generic CA (issues 2048-bit individual certs)
> - GDCA TrustAUTH R4 CodeSigning CA (issues 2048-bit CodeSigning certs)
> - GDCA TrustAUTH R4 Extended Validation SSL CA (issues 2048-bit EV SSL certs)
> - GDCA TrustAUTH R4 Extended Validation Code Signing CA (issues 2048-bit EV 
> CodeSigning certs)
> 
> * This request is to turn on the Websites trust bit.
> 
> CPS section 3.2.5: For domain verification, GDCA needs to check the written 
> materials which can be used to prove the ownership of corresponding domain 
> provided by applicant. Meanwhile, GDCA should ensure the ownership of domain 
> from corresponding registrant or other authoritative third-party databases. 
> During the verification, GDCA needs to perform the following procedures:
> 1. GDCA should confirm that the domain's owner is certificate applicant based 
> on the information queried from corresponding domain registrant or 
> authoritative third-party database and provided by applicant.
> 2. GDCA should confirm that the significant information (such as document 
> information of applicant) in application materials are consistent with the 
> reply of domain's owner by sending email or making phone call based on the 
> contact information (such as email, registrar, administrator's email 
> published at this domain's website, etc.) queried from corresponding domain 
> registrant or authoritative third-party database.
> If necessary, GDCA also need to take other review measures to confirm the 
> ownership of the domain name. Applicant can't refuse to the request for 
> providing appropriate assistance.
> 
> 
> * EV Policy OID: 1.2.156.112559.1.1.6.1
> 
> * Test Website: https://ev-ssl-test-1.95105813.cn/
> 
> * CRL URLs:
> http://www.gdca.com.cn/crl/GDCA_TrustAUTH_R5_ROOT.crl
> http://www.gdca.com.cn/crl/GDCA_TrustAUTH_R4_SSL_CA.crl
> http://www.gdca.com.cn/crl/GDCA_TrustAUTH_R4_Extended_Validation_SSL_CA.crl
> 
> * OCSP URL:
> http://www.gdca.com.cn/TrustAUTH/ocsp
> 
> * Audit: Annual audits are performed by PricewaterhouseCoopers Zhong Tian LLP 
> according to the WebTrust criteria.
> WebTrust CA: https://cert.webtrust.org/SealFile?seal=2024=pdf
> WebTrust BR: https://cert.webtrust.org/SealFile?seal=2025=pdf
> WebTrust EV: https://cert.webtrust.org/SealFile?seal=2026=pdf
> 
> * Potentially Problematic Practices: None Noted
> (http://wiki.mozilla.org/CA:Problematic_Practices)
> 
> This begins the discussion of the request from Guangdong Certificate 
> Authority (GDCA) to include the "GDCA TrustAUTH R5 ROOT" certificate, turn on 
> the Websites trust bit, and enabled EV treatment. At the conclusion of this 
> discussion I will provide a summary of issues noted and action items. If 
> there are outstanding issues, then an additional discussion may be needed as 
> follow-up. If there are no outstanding issues, then I will recommend approval 
> of this request in the bug.
> 
> Kathleen

I posted on the solidot (Chinese Slashdot) about this. The majority comments 
want the application rejected.  
https://translate.google.com/translate?hl=en=zh-CN=en=http%3A%2F%2Fwww.solidot.org%2Fstory%3Fsid%3D50368
___
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

[Percy]

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

Re: Apple's response to the WoSign incidents

[Percy]

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

Re: WoSign still trusted somehow on Mac even after manual distrust of StartCom

[Percy]

Yeah, I suspected so but I didn't find it in the security content 
(https://support.apple.com/en-ca/HT207275).

I remember when Gerv discussed the idea on whitelisting intermediate cert, he 
mentioned that firefox didn't want to undermine user sovereignty by overriding 
the user's trust choice. I guess Apple might not have considered this. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

WoSign still trusted somehow on Mac even after manual distrust of StartCom

[Percy]

You can see from image1 that all StartCom roots are marked distrust systemwide. 
No WoSign roots are included on Mac. 

However when I'm accessing https://www.schrauger.com/ in Chrome, the HTTPS 
connection is marked as valid (image2) and the certification authority of 
WoSign is regarded as a valid intermediate cert. In the same session, when 
accessing https://wosign.com, the same intermediate cert is marked as untrusted 
(image3) which is what I expect. 

The same thing happened in Safari (Image 4&5). Can someone explain how the 
Certification Authority of WoSign (Serial number: 7250751724796726) is 
sometimes valid when the root cert is distrusted? 

Images: 
https://docs.google.com/document/d/1oB8P9466KcQhq8aZPvw9b8LEt9S0hffMWjoN7t3r8xg/edit
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog

[Percy]

On Monday, October 24, 2016 at 6:09:50 PM UTC-7, Kathleen Wilson wrote:
> The security blog about Distrusting New WoSign and StartCom Certificates has 
> been published:
> 
> https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/
> 
> Chinese translations of it will be posted soon.
> 
> Thanks,
> Kathleen

StartCom finally posted an announcement publicly on Nov. 3 
https://startssl.com/NewsDetails?date=20161103
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Something About CFCA (China Financial Certification Authority)

[Percy]

On Sunday, October 30, 2016 at 4:19:12 AM UTC-7, Han Yuwei wrote:
> According to their CPS (Chinese version 3.2 Jul.2016),
> 
> 1. All CAs can issue SM2 certificates and uses SM3 Hash.
> 
> 2. There is a "signing key" generated by subscriber and "encryption key" 
> generated by CFCA which transmitted to subscriber.
> 
> 3. For SSL certificate, the longest vaild duration is 5 years, which is much 
> more than 39 months.
> 
> Are those conflicting with Mozilla's policy?

https://www.ssllabs.com/ssltest/analyze.html?d=www.cfca.com.cn

This server is vulnerable to the OpenSSL Padding Oracle vulnerability 
(CVE-2016-2107) and insecure. Grade set to F.

Rather ironical for a CA's official site, isn't it?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog

[Percy]

Ryan,
It's great Chrome will distrust WoSign and StartCom. Google's blog post
stated that "Due to a number of technical limitations and concerns, Google
Chrome is unable to trust all pre-existing certificates while ensuring our
users are sufficiently protected from further misissuance.". Could you
elaborate what whitelist method will Google adopt?

Furthermore, even though Google is completely blocked in China, news about
Google are mostly not censored. Is it possible for Google to have a Chinese
translation as well, especially regarding WoSign? Such translation can
accelerate the early removal process.


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


On Mon, Oct 31, 2016 at 4:18 PM, Ryan Sleevi <r...@sleevi.com> wrote:

> On Monday, October 24, 2016 at 6:09:50 PM UTC-7, Kathleen Wilson wrote:
> > The security blog about Distrusting New WoSign and StartCom Certificates
> has been published:
> >
> > https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-
> startcom-certificates/
> >
> > Chinese translations of it will be posted soon.
> >
> > Thanks,
> > Kathleen
>
> Google has now posted its response, in light of the findings and
> discussion helpfully driven by Mozilla, at https://security.googleblog.
> com/2016/10/distrusting-wosign-and-startcom.html
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign: updated report and discussion

[Percy]

According to http://se.360.cn/event/gmzb.html, the browser needs to send a
http header Accept-Protocal: SM-SSL. Perhaps someone can do an Internet
scan against Chinese sites (especially gov) to observe SM2 certs

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


On Mon, Oct 31, 2016 at 10:54 AM, Han Yuwei <hanyuwe...@gmail.com> wrote:

> 在 2016年10月31日星期一 UTC+8下午11:50:46，Gervase Markham写道：
> > On 30/10/16 19:47, Han Yuwei wrote:
> > > SM2 is widely used in Chinese government websites. There is a openssl
> > > branch (https://github.com/guanzhi/GmSSL) who implemented
> > > SM2/SM3/SM4. And I don't see any other depolyment in HTTPS.
> >
> > Right, but my question remains: can you find a site with a WoSign SM2
> > certificate, which chains up to a root Mozilla trusts?
> >
> > Gerv
>
> I am sorry that I can't provide such a certificate for I am not involved
> in these systems. And I am not likely think there could be a SM2
> certificate because major broswers don't implemented SM2/SM3/SM4 so the
> server would only send RSA/ECC certificates.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Percy]

On Wednesday, October 12, 2016 at 12:12:08 PM UTC-7, Ryan Sleevi wrote:
> As Gerv suggested this was the official call for incidents with respect to 
> StartCom, it seems appropriate to start a new thread.
> 
> It would seem that, in evaluating the relationship with WoSign and Qihoo, we 
> naturally reach three possible conclusions:
> 1) StartCom is treated as an independent entity
> 2) StartCom is treated as a subsidiary of Qihoo
> 3) StartCom is treated as a subsidiary of WoSign
> 
> We know there are serious incidents with WoSign that, collectively, encourage 
> the community to distrust future certificates. However, there hasn't been a 
> similar investigation into the trustworthiness of StartCom as an independent 
> entity or as an entity operated by Qihoo. It would seem that germane to the 
> discussion is how trustworthy the claims are - from either StartCom or Qihoo 
> - and how that affects trust.
> 
> Incidents with StartCom:
> A) Duplicate Serials. https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
> We know that StartCom had issues issuing duplicate serials, in violation of 
> RFC 5280. We know that they did not prioritize resolution, and when 
> attempting resolution, did so incompletely, as the issue still resurfaced.
> 
> C) Improper OCSP responder. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
> We know that StartCom continues to have issue with their OCSP responder after 
> they issue certificates. Presumably, this is a CDN distribution delay, but we 
> can't be sure, especially considering Incident A was with the underlying 
> systems. As a consequence of this, users with StartCom certificates are 
> disproportionately disadvantaged from enabling OCSP stapling, which many 
> browser programs support (and is perhaps the only viable path towards a 
> complete revocation solution).
> 
> E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 / 
> https://bugzilla.mozilla.org/show_bug.cgi?id=994478
> We know StartCom had a notoriously poor response to HeartBleed. Eddy first 
> dismissed the significance, and then when proven wrong, still continued to 
> charge $25 USD for revocation. Ostensibly, this is a violation of the 
> Baseline Requirements, in that CAs are required to revoke certificates 
> suspected of Key Compromise. However, despite the BRs effective date of 2012, 
> Mozilla was not aggressively imposing compliance then (... or now, to be 
> fair).
> 
> G) StartCom BR violations - IV 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1266942
> StartCom was materially violating its CP/CPS and the Baseline Requirements 
> with respect to certain types of validation. No explanation for the root 
> cause provided.
> 
> I) StartCom BR violations (2) - Key Sizes 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1015767
> StartCom was issuing certificates less than 2048 bits.
> 
> K) StartCom impersonating mozilla.com. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=471702
> StartCom's (former) CEO Eddy Nigg obtained a key and certificate for 
> www.mozilla.com and placed it on an Internet-facing server.
> 
> M) StartCom BR violations (3) - Key exponents 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1212655
> StartCom was not enforcing the BRs with respect to RSA public exponents.
> 
> O) StartCom BR violations (4) - Curve violations 
> https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269183
> StartCom was not enforcing the BRs with respect to EC curve algorithms.
> 
> 
> 
> In addition to discussion of StartCom issues, it seems relevant to future 
> trust to evaluate issues with Qihoo. Many in the Mozilla community may not 
> have direct interactions with Qihoo, but they have obtained some notoriety in 
> security circles.
> 
> Q.A) Qihoo masking their browser as a critical Windows security update to IE 
> users.
> http://wmos.info/archives/7717 / 
> http://www.theregister.co.uk/2013/02/01/qihoo_government_warning_fraud/
> Qihoo displayed a misleading security update for Windows users that instead 
> installed their browser.
> 
> Q.C) Qihoo browser actively enables insecure cryptography.
> https://docs.google.com/document/d/1b7lenmn5XO06QohaJzVffnJxjXjY1rD70wg34gfuxRo/edit
> Qihoo's browser is notably insecure with respect to SSL/TLS, with some of the 
> insecure changes requiring active modification to the low-level source 
> libraries that Chromium (of which they're based on) uses.
> 
> Q.E) Qihoo apps removed from app stores due to malware
> https://www.techinasia.com/qihoo-committing-fraud-google-making-huge-mistake 
> / https://www.techinasia.com/qihoo-apps-banned-apple-app-store
> Qihoo Apps have repeatedly been banned from Apple's App Store due to issues
> 
> Q.G) Qihoo "security" apps repeatedly found as unfair competition
> https://www.techinasia.com/qihoo-360-loses-chinas-courts-ordered-pay-sogou-82-million-unfair-competition
> 
> 
> 
> I hope the above show that the odds are if the original 

Re: WoSign: updated report and discussion

[Percy]

On Sunday, October 30, 2016 at 6:15:48 AM UTC-7, Gervase Markham wrote:
> On 29/10/16 22:42, Percy wrote:
> > However, on the official website
> > (https://www.wosign.com/about/Why_WoSign.htm) WoSign stated that "沃通是
> > 中国唯一一家也是全球唯一一家能签发全球信任的采用国产加密算法(SM2) 的SSL证书和代码签名证书的商业CA。" WoSign is
> > the only commercial CA in China -- only commercial CA in the world
> > that can Sign SM2 SSL certs/code signing cert that is globally
> > trusted.
> 
> Well, that statement is either false or very misleading, because in
> order for an SM2 certificate to be useful "globally", there needs to be
> wide browser support. I don't know exactly which browsers support SM2,
> but I know that Firefox, Chrome, Safari, IE and Edge do not.
> 
> > This means that WoSign is not only signing SM2 certs for testing but
> > also signing SM2 from the globally trusted roots in production. I
> > suspect that there are SM2 certs from trusted root WoSign certs used
> > in the wild.
> 
> Can you find one?
> 
> Gerv

Gerv,
Firefox, Chrome, Safari, IE and Edge combined market share is 41.54% [1] and 
the rest are domestic browsers. This is a 360 browser with SM2 
http://se.360.cn/event/gmzb.html

[1]http://tip.umeng.com/uploads/data_report/2015final.pdf
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Percy]

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

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


On Sat, Oct 29, 2016 at 11:36 PM, 谭晓生 <tanxiaosh...@360.cn> wrote:

> Is there anybody thought about why it happens in China? Why the local
> browser did not block the self-issued certificates?
>
> Thanks，
> Xiaosheng Tan
>
>
>
> 在 2016/10/30 下午1:17，“Percy”<percyal...@gmail.com> 写入:
>
> On Saturday, October 29, 2016 at 5:54:10 PM UTC-7, Matt Palmer wrote:
> > On Sat, Oct 29, 2016 at 02:59:07PM -0700, Percy wrote:
> > > Perhaps not. However, Qihoo 360's behavior calls the
> trustworthiness of the
> > > entire company into question. And such trust, in my view, should be
> > > evaluated when WoSign/StartCom submit their re-inclusion requests
> in the
> > > future.
> >
> > You can make that argument when WoSign/StartCom's reinclusion
> discussions
> > take place on this list.  Now is not the appropriate time for that.
> >
> > - Matt
>
> WoSign/StartCom's re-inclusion request might be a year from now. In
> the meanwhile, those 400 million users will be exposed to MITM. That's why
> I'm bringing it up now, rather than one year later.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Percy]

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

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

Re: StartCom & Qihoo Incidents

[Percy]

Perhaps not. However, Qihoo 360's behavior calls the trustworthiness of the
entire company into question. And such trust, in my view, should be
evaluated when WoSign/StartCom submit their re-inclusion requests in the
future.

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


On Sat, Oct 29, 2016 at 2:38 PM, Peter Bowen <pzbo...@gmail.com> wrote:

> On Sat, Oct 29, 2016 at 2:29 PM, Percy <percyal...@gmail.com> wrote:
> > So 400 million Chinese users[1] are left vulnerable to MITM by even a
> casual attacker and we cannot do anything about it!?
>
> As stated previously, it is not for one browser to tell another how to
> behave and the CA/Browser Forum explicitly cannot set requirements on
> members for a number of reasons, including anti-trust concerns.
>
> While probably not equivalent, this is not all that different from
> software licensing discussions.  Each author of software can set
> licensing terms as permitted by law; these terms might mean the
> software qualifies as Free/Libre/Open Source Software (FLOSS) or they
> may have requirements that meet other needs.  As I’m sure you are
> aware, there are viewpoints that say that the only ethical stance is
> only FLOSS and there are viewpoints that FLOSS is almost always wrong.
> It is not for Mozilla to say that all browsers must be FLOSS (nor for
> the CAB Forum to say such), even if one could argue that the only
> option for a secure browser is for it to be FLOSS.
>
> Thanks,
> Peter
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign: updated report and discussion

[Percy]

Gerv,
I believe I found the new updated report still has intentional deception. 

Issue P: Use of SM2 Algorithm (Nov 2015) WoSign stated that it's only used for 
testing purposes. 

However, on the official website (https://www.wosign.com/about/Why_WoSign.htm) 
WoSign stated that "沃通是中国唯一一家也是全球唯一一家能签发全球信任的采用国产加密算法(SM2) 的SSL证书和代码签名证书的商业CA。" 
WoSign is the only commercial CA in China -- only commercial CA in the world 
that can Sign SM2 SSL certs/code signing cert that is globally trusted. 

This means that WoSign is not only signing SM2 certs for testing but also 
signing SM2 from the globally trusted roots in production. I suspect that there 
are SM2 certs from trusted root WoSign certs used in the wild.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Percy]

So 400 million Chinese users[1] are left vulnerable to MITM by even a casual 
attacker and we cannot do anything about it!?



[1]: http://se.360.cn/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Percy]

On Thursday, October 27, 2016 at 5:26:23 PM UTC-7, Erwann Abalea wrote:
> Le jeudi 27 octobre 2016 09:55:09 UTC+2, Percy a écrit :
> > So this is it? Qihoo can continue to get away with this MITM browser?
> 
> I'm afraid that can't be solved by Mozilla. Qihoo is free to sell or freely 
> distribute their browser.

Since I'm not familiar with CAB forum, does CAB forum has authority to compel 
its members to protect its users?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Percy]

"When facing any requirements of laws and regulations or any demands for 
undergoing legal
process of court and other agencies, GDCA must provide confidential information 
in this CP"

Can GDCA specify what other agencies are included? In China, many requests are 
relayed simply through a phone call without any paper trail or IM and the 
service providers must meet the demand very quickly. Are such informal 
procedures honored by GDCA?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Percy]

On Thursday, October 27, 2016 at 3:22:03 AM UTC-7, wangs...@gmail.com wrote:
> 在 2016年10月27日星期四 UTC+8上午8:09:06，Peter Kurrasch写道：
> > I think these are both good points and my recommendation is that Mozilla 
> > deny GDCA's request for inclusion.
> > 
> > 
> > We should not have to explain something as basic as document versioning and 
> > version control. If GDCA can not demonstrate sufficient controls over their 
> > documentation, there is no reason for the Internet community to place 
> > confidence in any of the other versioning systems that are needed to 
> > operate a CA.
> > 
> > 
> > Question: Are auditors expected to review translations of CP or CPS docs 
> > and verify consistency between them?
> > 
> > 
> >  
> > 
> > 
> > 
> >
> > 
> > 
> >   
> >   
> > From: Jakob Bohm
> > Sent: Saturday, October 22, 2016 9:07 AM
> > To: mozilla-dev-s...@lists.mozilla.org
> > Subject: Re: Guang Dong Certificate Authority (GDCA) root inclusion request
> > 
> > 
> > On 21/10/2016 10:38, Han Yuwei wrote:
> > >
> > > I think this is a major mistake and a investgation should be conducted 
> > > for CPS is a critical document about CA. This is not just a translation 
> > > problem but a version control problem. Sometimes it can be lying.
> > >
> > 
> > Let me try to be more specific:
> > 
> > When publishing a document called CPS version 4.3 the document with
> > that number must have the same contents in all languages that have a
> > document with that name and version number.
> > 
> > When making any change, even just correcting a mistyped URL, the
> > document becomes a new document version which should have a new and
> > larger number than the number of the document before the change.
> > Thus when a published document refers to a broken URL on your own
> > server, it is often cheaper to repair the server than to publish a new
> > document version.  Some of the oldest CAs have been proudly
> > publishing their various important files at multiple URLs corresponding
> > to whatever was mentioned in old CP and CPS documents etc., only
> > shutting down those URLs years after the corresponding CA roots were
> > shut down.
> > 
> > There can also be a "draft" document which has no number and which
> > contains the changes that will go into the next numbered edition.  Such
> > a "draft" would have no official significance, as it has not been
> > officially "published".  For a well-planned change, the final "draft"
> > would be translated and checked into the relevant languages (e.g.
> > Chinese with mainland writing system, Chinese with Hong Kong and Macao
> > Special Administrative Regions old writing system, English), before
> > simultaneously publishing the matching documents with the same number
> > on the same day.
> > 
> > There are infinitely many version numbers in the universe to choose
> > from.  There are also computer programs that can generate new version
> > numbers every time a draft is changed, but computers cannot decide when
> > a version is good enough in all languages to make an official
> > publication, and the computer generated version numbers are often
> > impractical for publication because they count all the small steps that
> > were not published.
> > 
> > 
> > Enjoy
> > 
> > Jakob
> > -- 
> > Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> > Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> > This public discussion message is non-binding and may contain errors.
> > WiseMo - Remote Service Management for PCs, Phones and Embedded
> > ___
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> 
> We’d like to explain a few points.
> 
> 1. We have already implemented version control on Chinese version CP/CPS, the 
> revision and release of CP/CPS are reviewed and approved by the security 
> policy committee (see section 1.5 in CP/CPS). The Chinese version CP/CPS is 
> also reviewed by our auditor.
> 
> 2. The Chinese version CP/CPS is the formal documents we published in our 
> Website. In the initial phase of "Bug 1128392", we have summited the Chinese 
> version CP/CPS to Mozilla, and Mozilla release a basic review list in file 
> "1128392-CAInformation.pdf" which contains instructions for us to summit some 
> chapters of the CP/CPS in English version. We are not able to provide an 
> accurate English version CP/CPS, 

Re: StartCom & Qihoo Incidents

[Percy]

So this is it? Qihoo can continue to get away with this MITM browser?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog

[Percy]

Kathleen,
This coverage is very encouraging! Among the sites you included, huanqiu, which 
is a newspaper operated by the central government is notable. So far, no 
censorship has been observed, contrary to the blanket censorship of the 
previous CNNIC case. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog

[Percy]

Kathleen,
This coverage is very encouraging! Among the sites you included, huanqiu, which 
is a newspaper operated by the central government is notable. So far, no 
censorship has been observed, contrary to the blanket censorship of the 
previous CNNIC case. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog

[Percy]

That you have to ask WoSign. 

The exact wording is 
"将增加一个产品选项，用户可以选购从新的沃通（WoSign）中级根证书下签发的支持所有浏览器（包括火狐浏览器）的SSL证书，在过渡期八折优惠。此中级根证书将由全球信任的其他CA根证书签发，支持所有浏览器和所有新老终端设备。此项产品升级计划一个月内完成并为广大用户提供证书服务；"

My translation: [WoSign] will add a new product selection. Users can choose SSL 
certs signed by the new WoSign intermediate cert. The SSL certs will be trusted 
by all browsers(including firefox). The certs will be 20% off in this 
transition period. The certs will be signed by a publicly trusted CA which 
supports all browsers and all OS, older or new. This product upgrade is 
expected to be completed within a month and will serve our users the 
certificate service they need. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog

[Percy]

StartCom on the other hand, issued no announcement (https://startssl.com/News) 
even under multiple explicit inquires from multiple users 
(https://forum.startcomca.com/viewforum.php?f=16=549011a08d3a081898f1e1542d3ecc10).
   
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog

[Percy]

WoSign has posted an announcement regarding Mozilla's decision. In the 
announcement, WoSign stated 

WoSign actively cooperated with the investigation and has always fix all the 
issues immediately after the discovery and called Mozilla's decision 
"exceptionally severe".

Certs issued by existing WoSign roots will be 90% off from Oct 22nd.

WoSign will launch a new WoSign intermediate cert to continue to sell certs 
trusted by all browsers including Firefox. The intermediate cert will be signed 
by another trusted root CA. This is scheduled to launch within a month. 

-
The full announcement is translated below.
https://www.wosign.com/news/announcement_about_Mozilla_Action_20161024.htm

Announcements about the Mozilla Incident
Release Date: 2016-10-24
Mozilla on August 24 launched an investigation against WoSign CA, and published 
a list of questions ( Wiki ), lists all the issues from March 2015 to July 2016 
period. WoSign addressed these issues with a careful investigation and released 
the investigation report , some issues have been clarified and all issues have 
been fixed immediately after their discovery. WoSign actively cooperated with 
the investigation and argued for the best interests of users, to ensure that 
the certificate issued previously will not be affected.
Mozilla has released on the October 21, the final response to WoSign. WoSign 
has the following statement regarding this incident 
1.the results of the incident
Very sorry to see Mozilla decided from October 22 onwards no longer trust the 
four WoSign root certificate;
After June 1, 2017, after satisfying Mozilla's 6-point operational 
requirements, WoSign CA can re-apply for the Mozilla root certification 
process, re-apply for a new root certificate inclusion.
2. the impact of the incident on the user
All SSL certificates October 21 (including 21), before issuing are not 
affected, can normally be trusted by Mozilla Firefox browser ; after October 21 
SSL certs from WoSign (WoSign) 4 root certificate will not be trusted by 
Firefox.
All code-signing certificates, client certificates, and signature platforms 
(WoSignDoc) issued from the four WoSign roots are unaffected.
3. WoSign’s response measures after the incident
Will update the digital certificate Store Buy website. From October 22, all SSL 
certificates from WoSign four root certificate will be 90% off; free SSL 
certificate service continue to be closed;
Will add a product option, the user can choose to support all browsers SSL 
Certificates (including Firefox) under the new WoSign (WoSign) intermediate 
root certificates issued during the transitional period 20% Off! This 
intermediate root certificate will be issued by other CA root certificates that 
are trusted globally, supporting all browsers and all new and existing terminal 
devices. The product upgrade plan is scheduled to completed within one month 
and provide a certificate for the majority of users;
Will be actively in accordance with the requirements of Mozilla-made 6 points 
for operation, for after June 1, 2017, as soon as possible to complete the new 
root certificate in the various browser system preset work;
Has been and continue to conduct a comprehensive security audit of all systems 
and strengthen the upgrading, while improving the various internal control 
management system, the formation of international standards research team and 
internal audit team to ensure that all systems 100% meet international 
standards, all business operations in strict accordance with international 
standards. Require operation, strengthen the staff in strict accordance with 
the standard operation of the enforcement efforts, offenders will be severely 
punished.
Mozilla's sanctions are exceptionally severe, but we will sincerely accept and 
carry out profound reflection and improvement, continue to improve system 
reliability, security and compliance, strict compliance with various 
international standards and various browser vendors designated security 
management strategy.
We know that: as a Chinese CA's international road is still very long, but 
WoSign’s plan to build world-class PKI certificate service at the beginning 
will stay the same! We will continue to contribute to building a safe and 
trusted global Internet environment, and actively promote the PKI / CA-related 
Chinese standards and international standards system integration.
Thank you very much for your continued trust in the majority of users and 
partners! It is with your support and companionship, WoSign has gone through 
ten years of wind and rain, and achieved SSL certificate in China market share 
of nearly 50% and the global market ranked sixth in the good results, we hope 
to continue with your towards the next more brilliant decade!


___
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

[Percy]

Samuel, 
I absolutely agree with what you're saying. That's why I suggested to Mozilla 
that it mandates WoSign/StartCom to disclose such information on its websites 
or otherwise inform their customers. Currently, new customers have no way to 
know until it's too late, i.e when Firefox releases Firefox 51 next year.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Percy]

Thanks for bringing the discrepancy into our attention. 
Even the cover page of the English and Chinese version of CPS are dated 
differently.

English
Global Digital Cybersecurity Authority
CO., LTD.
Certification Practice Statement (CPS) Version: V4.3
Effective Date: July 1, 2016

Chinese  
数安时代科技股份有限公司
电子认证业务规则
版本:V4.3 
生效日期:2016 年 8 月 1 日 (Effective date: August 1st, 2016)


In 1.1.3 3) the Chinese version shows ROOTCA(SM2) - Guangdong Certificate 
Authority(SM2) while the English version shows ROOTCA(SM2) - SM2 CA 
Certificate. 

I saw 4) included in the English version about 1.1.3 5) 数安时代 R5 根 CA and 6) 
GDCA TrustAUTH E5 ROOT 
are completely missing in the English version. 

I translated the 6) section below.

GDCA TrustAUTH E5 ROOT uses ECC, with the root key length 384-bit . It has 7 
sub-CA. 1)GDCA TrustAUTH E4 EV SSL CA with key length 256-bit and it signs 
256-bit EV SSL servers. 2)GDCA TrustAUTH E4 OV SSL CA and it signs 256-bit OV 
SSL certs for servers. (3)GDCA TrustAUTH E4 IV SSL CA，256-bit key and signs 
256-bit IV SSL certs for servers; (4)GDCA TrustAUTH E4 DV SSL CA，256-bit key 
and signs 256-bit DV SSL certs for servers; (5)GDCA TrustAUTH E4 CodeSigning CA 
256-bit key，and signs 256-bit code certs;(6)GDCA TrustAUTH E4 Generic CA, 
256-bit，signed 256-bit certs for organizations  and individuals ;(7)GDCA 
TrustAUTH E4 Primer CA， 256-bit，and signs 256-bit personal certs.

GDCA TrustAUTH E5 ROOT will expire on 2040 Dec  31st. 
GDCA TrustAUTH E4 EV SSL CA will expire on  2030 Dec 31st. From 2027 Jan,1st 
，no new certs will be signed with it.
…( More expiration date stuff)

GDCA TrustAUTH R5 ROOT 、数安时代 R5 根 CA 证书、GDCA 
TrustAUTH E5 ROOT’s intermediate certs: GDCA conforms to the latest version of 
CA/Browser Forum Baseline Requirements for the Issuance and Management of 
Publicly Trusted SSL Digital Certificates published at www.cabforum.org. In the 
event that a discrepancy arises between interpretations of this document and 
Baseline Requirement, the Baseline Requirement shall govern. 

This is as far as I read. There are probably many more inconsistencies as Yuwei 
pointed out. 
I suggest Mozilla ask a staff who know Chinese to fully translate the Chinese 
CPS yourself and compare with the provided English CPS




___
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

[Percy]

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

[Percy]

> I’m not sure what I could reasonably require (and enforce) of the CA in 
> regards to  communicating with their customers. 

>  I recall that my security blog about CNNIC got censored in China, so I'm not 
> sure what Mozilla can do about informing the CA's customers of this pending 
> change/impact. 

Because 360 safe browser is the most dominant browser in China. Qihoo, the 
parent company of WoSign/StartCom produced this browser. I assume Qihoo's 
browser will not take any action against its own CAs. 

So If Mozilla or other parties is not mandating WoSign/StartCom disclose such 
incidents to its users, but WoSign is portraying WoSign to be this fast growing 
company with great security record (as WoSign's latest press release did), 
users of WoSign will not be able to know about the distrust, even sometime 
after the grace period ends (1 year or 2 year from now). Web owners will only 
found out after the grace period, when they somehow accessed the site with 
non-360 safe browser. 

Indeed, your announcement about CNNIC was censored in China. In fact, I 
monitored and broke this news.  However, WoSign is not a government agency and 
the announcement shouldn't be censored. I suggest Mozilla at least publish a 
blog post in Chinese about this, but preferably mandating WoSign/StartCom to 
publish on its official sites to inform users about its bad security practices.
___
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

[Percy]

On Wednesday, October 12, 2016 at 8:12:29 PM UTC-7, Percy wrote:
> WoSign has so far announced nothing about those incidents or immediate 
> distrust (Apple and Mozilla) to its end users. On the contrary, WoSign had a 
> press release dated Oct 8th 
> (https://www.wosign.com/news/netcraft-ssl-oct.htm) titled "WoSign SSL certs 
> reaches almost 50% market share in China". In the press release, it stated 
> that "WoSign's achievement today is due to company founder and CEO Richard 
> Wang leads all staff to be dedicated". WoSign is depicted as this positive, 
> strong growing company. Nothing about its distrust in the immediate future is 
> mentioned. 
> 
> In Oct 7th, in the incident report in English, WoSign admitted multiple 
> intentional mistakes and deceptions  
> (https://www.google.com/url?q=https%3A%2F%2Fwww.wosign.com%2Freport%2FWoSign_Incident_Report_Update_07102016.pdf=D=1=AFQjCNGRzAxwYrEEiA_SN5gfcsftSst0nA)
>  and that the CEO Richard Wang to be relieved of its duties. 
> 
> I'm calling WoSign out on this two-faced behavior towards Chinese end users 
> and foreign security researchers.

WoSign and StartCom are still actively selling certs which cost one hundreds or 
more dollars. I think Mozilla should mandate that WoSign/StartCom inform their 
users of such incidents or at least the imminent distrust by Mozilla (and 
Apple). Now users are left in the dark for those trust decisions which violates 
the minimum disruption principle.
___
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

[Percy]

> Others have noted the mismatch here with an October 1 date elsewhere in 
> the document. I think we should pick a single date in the future, to 
> allow the CAs concerned to wind down operations without leaving 
> customers having just obtained certs which will stop working in a few 
> months. So I would argue for October 21st in line with our principle of 
> minimal disruption to cert owners. 

I think Oct 1st is a better deadline. WoSign has stopped issuing DV certs since 
Sept 29th and Apple has banned certs after 2016-09-19. There is no reason to 
give WoSign another week of time to issuing new certs. 

"Sorry, due to some security consideration, 
WoSign decide to close the free SSL certificate application temporarily. Sept. 
29th 2016.
You can visit https://www.startssl.com to get a Free SSL Certificate."
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign: updated report and discussion

[Percy]

(Hmm, my previous comment about two faced WoSign disappeared from Google group 
probably due to anti-spam. Gerv, can you recover it for me?)

I also want to point out that WoSign is currently asking customers to go to 
StartCom to get DV certs. If we continue to trust StartCom, then WoSign 
basically suffered no consequences for gross negligence. 

"
Sorry, due to some security consideration, 
WoSign decide to close the free SSL certificate application temporarily. Sept. 
29th 2016.
You can visit https://www.startssl.com to get a Free SSL Certificate.
"
https://buy.wosign.com/free/#ssl
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign: updated report and discussion

[Percy]

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

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



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

Re: StartCom & Qihoo Incidents

[Percy]

The Chinese wikipedia has well documented controversies surrounding Qihoo 360. 
Unfortunately, it's not translated into the English Wikipedia. So please go to 
https://zh.wikipedia.org/wiki/%E5%A5%87%E8%99%8E360#.E5.95.86.E4.B8.9A.E7.9F.9B.E7.9B.BE.E4.B8.8E.E4.BA.89.E8.AE.AE.E4.BA.8B.E4.BB.B6
 and use Google Translate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Percy]

I'd also like to point out the Qihoo 360 cheated in all anti-virus tests 
http://www.computerworld.com/article/2917384/malware-vulnerabilities/antivirus-test-labs-call-out-chinese-security-company-as-cheat.html
 When Qihoo was caught out, Qihoo turned it into a market campaign, calling 
AV-C outdated and saying Qihoo's cloud engine is much more advanced and 
announced it quit 
(http://tech.sina.com.cn/i/2015-05-02/doc-icczmvup0903459.shtml article in 
Chinese )
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign: updated report and discussion

[Percy]

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

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

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

Re: WoSign: updated report and discussion

[Percy]

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

Re: WoSign and StartCom

[Percy]

"anyone issuing certificates for .cn, .hk or .mo domain *MUST* submit those 
certificate to the CT server set (with similar constraints as you require for 
WoSign/StartCom) "

This means you're rather ill-informed about the Chinese Internet. Most Chinese 
sites still use .com domains. But this is not what users are worried about as 
.cn domains are already under Chinese jurisdiction. They're more worried about 
attack against .com domains such as MITM against Github Outlook, Yahoo,Google 
and iCloud.
___
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

[Percy]

On Tuesday, October 4, 2016 at 4:41:18 AM UTC-7, Rob Stradling wrote:
> Today we have revoked (via CRL and OCSP) all 3 of the cross-certificates
> that we'd issued to WoSign:
> 
> https://crt.sh/?id=3223853
> https://crt.sh/?id=12716343
> https://crt.sh/?id=12716433
> 
> See also:
> https://bugzilla.mozilla.org/show_bug.cgi?id=906611#c2
> 
> On 06/09/16 11:11, Rob Stradling wrote:
> > Hi Peter.  Since you mentioned Comodo's cross-certification of the
> > "Certification Authority of WoSign" root, we thought we should respond...
> > 
> > On 05/09/16 23:58, Peter Bowen wrote:
> > 
> >> Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
> >> of WoSign by /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
> >> Network/OU=http://www.usertrust.com/CN=UTN - DATACorp SGC expiring
> >> 2019-06-24T19:06:30Z
> > 
> > This cross-certificate [1] is currently unexpired and unrevoked.  However...
> > 
> > The "UTN - DATACorp SGC" root was removed from NSS last year [2].
> > 
> > "UTN - DATACorp SGC" was also cross-certified by the "AddTrust External
> > CA Root" root [3], but we revoked the cross-certificates in December
> > 2015, invited Mozilla to add them to OneCRL [4] and disclosed them as
> > revoked to Salesforce [5].  (I don't know why Mozilla haven't yet added
> > these to OneCRL.  A few weeks ago I marked Bug 1233408 as blocking Bug
> > 1155095 in the hope that it would get noticed!)
> > 
> >> Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
> >> of WoSign by /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
> >> Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Object expiring
> >> 2019-07-09T18:40:36Z
> > 
> > These two cross-certificates [6] are currently unexpired and unrevoked.
> > However...
> > 
> > The "UTN-USERFirst-Object" root is only enabled for the Code Signing
> > trust bit in NSS, which AIUI has been effectively dead for about a year [7].
> > 
> > There are 2 cross-certs (currently unconstrained and unrevoked) issued
> > by "AddTrust External CA Root" to "UTN-USERFirst-Object" [8].  However,
> > the cross-certs issued to WoSign [6] are EKU-constrained to Code Signing
> > / Time Stamping.
> > 
> > 
> >> 1) Should any action be taken against the operators of these CAs due
> >> to the incidents listed?
> >>
> >> My view is that the correct answer is "no, unless it is demonstrated
> >> that the CA operator had knowledge of undisclosed incidents",
> > 
> > Comodo only learned of these incidents after they had been publicly
> > disclosed.
> > 
> > 
> >> 2) If Mozilla decides to take action that results in WoSign no longer
> >> being directly trusted, do those CAs with unrevoked unexpired
> >> cross-signs bear responsibility for any future mis-issuance by WoSign?
> > 
> > Comodo will continue to work to ensure that Mozilla's trust decisions
> > are respected.
> > 
> > 
> > [1] https://crt.sh/?id=3223853
> > 
> > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1208461
> > 
> > [3] https://crt.sh/?q=UTN+-+DATACorp+SGC=1
> > 
> > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1233408
> > 
> > [5] https://crt.sh/mozilla-disclosures#revoked
> > 
> > [6] https://crt.sh/?q=Certification+Authority+of+WoSign=1395
> > 
> > [7]
> > https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02409.html
> > 
> > [8] https://crt.sh/?q=UTN-USERFirst-Object=1
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online

Does this mean all end entity certs chained to them are blocked immediately? 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign and StartCom

[Percy]

On Monday, September 26, 2016 at 7:21:13 AM UTC-7, Gervase Markham wrote:
> Today, Mozilla is publishing an additional document containing further
> research into the back-dating of SHA-1 certificates, in violation of the
> CAB Forum Baseline Requirements, to avoid browser blocks. It also
> contains some conclusions we have drawn from the recent investigations,
> and a proposal for discussion regarding the action that Mozilla's root
> program should take in response.
> 
> Because this document is extensive and contains embedded images, links
> and formatting, I have published it on Google Docs instead of as an
> email message here:
> 
> https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/edit
> 
> However, this forum is the appropriate place for discussing it. Please
> feel free to cut and paste any parts you wish to quote and comment on.
> 
> Gerv

FYI, WoSign has stopped issuing new DV certs. 
"Sorry, due to some security consideration, 
WoSign decide to close the free SSL certificate application temporarily. Sept. 
29th 2016."
https://buy.wosign.com/free/?lan=en
___
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

[Percy]

On Saturday, October 1, 2016 at 9:03:38 PM UTC-7, Kurt Roeckx wrote:
> On Sat, Oct 01, 2016 at 11:35:06AM -0700, Percy wrote:
> > "Apple products will trust individual existing certificates issued from 
> > this intermediate CA and published to public Certificate Transparency log 
> > servers by 2016-09-19"
> > 
> > It seems that Apple has taken the explicit white-listed approach despite 
> > the size drawback mentioned in the other thread.
> 
> >From what I get, they check that it's been logged in CT. And I'm
> not sure what that means, like doing an online check against at CT
> log, require that the SCT has been stappled or have a whitelist.
> 
> 
> Kurt

Either way, this is far better than trusting a notBefore date of the certs when 
the main problem of WoSign is the  tampering of the notBefore date when the 
cover up when explicitly questioned about it. 
___
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

[Percy]

"Apple products will trust individual existing certificates issued from this 
intermediate CA and published to public Certificate Transparency log servers by 
2016-09-19"

It seems that Apple has taken the explicit white-listed approach despite the 
size drawback mentioned in the other thread. I know Apple is a OS vendor which 
probably makes such a deployment easier to implement. But the size of the 
whitelist is not really a concern over the desktop environment. So I hope 
Mozilla and Google can have a explicit whitelist approach on desktop while use 
the notBefore data on mobile to have the stronger safe guard when possible. 
___
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

[Percy]

On Thursday, September 29, 2016 at 10:12:37 AM UTC-7, Han Yuwei wrote:
> 在 2016年9月29日星期四 UTC+8下午11:41:12，Gervase Markham写道：
> > Hi everyone,
> > 
> > Following the publication of the recent investigative report,
> > representatives of Qihoo 360 and StartCom have requested a face-to-face
> > meeting with Mozilla. We have accepted, and that meeting will take place
> > next Tuesday in London.
> > 
> > After that, we expect to see a public response and proposal for
> > remediation from them, which will be discussed here before Mozilla makes
> > a final decision on the action we will take.
> > 
> > Gerv
> 
> Could you disclosure what would you talk about or would be determined on the 
> meeting? And would there be a video or transcript about your meeting?

In the original document,  Mozilla stated that it "is committed to a fair, 
transparent and thorough investigation of the facts of each case." So I think 
at least a summary of the meeting is warranted, if the meeting results in any 
change of Mozilla's previous proposal against WoSign/StartCom.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign and StartCom

[Percy]

On Wednesday, September 28, 2016 at 12:16:51 AM UTC-7, Peter Gutmann wrote:
> Percy <percyal...@gmail.com> writes:
> >On Tuesday, September 27, 2016 at 2:15:38 AM UTC-7, Gervase Markham wrote:
> >> Participants may be interested in this blog post from Tyro:
> >> https://tyro.com/blog/merchant-security-is-tyros-priority/
> >
> >So this is almost proof that WoSign/StartCom has been intentionally back-
> >dating certificates to avoid blocks on SHA-1 issuance in browsers. 
> 
> Did anyone keep a copy of that post?  Looks like they took it down pretty
> quickly, possibly in response to the above.
> 
> Peter.

I'm assuming WoSign/StartCom pressured Tyro to remove the blog post. 
WoSign/StartCom has previously publicly threatened legal actions over the 
secret purchase. 

Are those suppression attempts factored in when making trust decisions?  
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign and StartCom

[Percy]

WoSign's official website stated that "For Free SSL Certificate, it support 20 
domain names for 3 years period" 
(https://buy.wosign.com/free/freeEmailcert.html). In order to identify possible 
backdated certs in the future, I suggest that WoSign/StartCom be mandated to 
upload all unexpired certs (especially those in 2014) to CT, so that we can 
have a complete list of domains. 


On Monday, September 26, 2016 at 7:21:13 AM UTC-7, Gervase Markham wrote:
> Today, Mozilla is publishing an additional document containing further
> research into the back-dating of SHA-1 certificates, in violation of the
> CAB Forum Baseline Requirements, to avoid browser blocks. It also
> contains some conclusions we have drawn from the recent investigations,
> and a proposal for discussion regarding the action that Mozilla's root
> program should take in response.
> 
> Because this document is extensive and contains embedded images, links
> and formatting, I have published it on Google Docs instead of as an
> email message here:
> 
> https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/edit
> 
> However, this forum is the appropriate place for discussing it. Please
> feel free to cut and paste any parts you wish to quote and comment on.
> 
> Gerv

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

Re: WoSign and StartCom

[Percy]

On Tuesday, September 27, 2016 at 2:15:38 AM UTC-7, Gervase Markham wrote:
> On 26/09/16 15:20, Gervase Markham wrote:
> > However, this forum is the appropriate place for discussing it. Please
> > feel free to cut and paste any parts you wish to quote and comment on.
> 
> Participants may be interested in this blog post from Tyro:
> https://tyro.com/blog/merchant-security-is-tyros-priority/
> 
> Gerv

So this is almost proof that WoSign/StartCom has been intentionally back-dating 
certificates to avoid blocks on SHA-1 issuance in browsers. And when being 
specifically asked about those certs, WoSign/StartCom expressively attempted to 
deceive this community by saying all certs are normal. 

Based on this new evidence, do you think the statement "This distrust would 
remain for a minimum of 1 year. After that time, WoSign/StartCom may be 
readmitted to the Mozilla trust program, under the following conditions" should 
be updated to reflect this? 

I think Audit only works for a benign party with unintentional mistakes. The 
new evidence suggest WoSign/StartCom is almost hostile. 
If WoSign/StartCom willfully deceives auditors, changes the code between 
audits, intentionally malpractices outside of auditing period, I don't think 
audits are a safe-guard against them.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign and StartCom

[Percy]

"However, many eyes are on the Web PKI and if such additional back-dating is 
discovered (by any means), Mozilla will immediately and permanently revoke 
trust in all WoSign and StartCom roots."
Could you elaborate a bit on concrete ways of discovering such backdating? 

As WoSign itself suggested, they might only operate such shady practices in 
C=CN. Google is blocked there and hence renders Chrome's automatic certificate 
reporting useless. Most security researchers on this forum will not visit 
Chinese websites and have minimum chances of discovering such certs manually. 
If WoSign is not posting those certs to CT, are there any concrete proposal to 
detect them? Will there be an Internet wide scanning to compare certs issued in 
the wide with the logged CT data?
___
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

[Percy]

Ha! @Showfom perhaps you should try getting a widecard cert from them and 
consequently obtain a cert for all *.sb domains.  
___
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

[Percy]

WoSign stated in the report that "Due to foreign companies to China's
technology blockade, WoSign decided to research and develop all systems by
ourselves in 2009, including BUY system (Online certificate store), CMS
(Certificate Management System, internal work flow), PKI/CA (Certificate
issuing system), CRL/OCSP (Certificate revocation query system) and TSA
(time stamp system). "
I'm assuming WoSign is referring to other companies operating CAs. Perhaps
WoSign can clarify what those companies are and the nature of such
blockade.

WoSign also stated that "WoSign agrees that this is a violation of the BRs
(only three US NIST P-256, P-384, or P-521 curves can be used for elliptic
curve keys in certs), but being a Chinese licensed CA, we must abide by
local laws and regulations, we must actively cooperate with domestic
browsers to test the SSL certificate using SM2 algorithm issued by a global
trusted root in the real Internet, not intranet.

WoSign, as a member of CAB Forum, will spare no effort to continue to
promote China encryption algorithm SM2 to become the international standard
allowed algorithm."


It seems that WoSign is committed to test certificates in a global trusted
root depesite explicit warning of not doing so even now. I see no
Chinese law mandating the insurance of SM2 certificates or forbidding the
insurance of certificate with standard curves. It's unclear to me why
WoSign insisted on testing SM2 with publicly trusted root. If WoSign is
claiming Chinese law mandate such testing/deployment, please refer to such
laws here and perhaps the community can take the local law into account. If
however no such law exists, as far as I know, the such commitment to BR
violation is not acceptable.

On Friday, September 23, 2016, Percy <percyal...@gmail.com> wrote:

> Richard,
> On behalf of most Chinese Internet users who do not speak English, I'm
> asking why WoSign is only making the final statement available in Chinese,
> but not the incident report. WoSign doesn't even have any statement,
> announcement or press release in Chinese regarding any of the incidents
> (except this final statement) anywhere.
>
> As WoSign is the largest CA in China, it must be responsible to Chinese
> users. I'm requesting WoSign to make the incident report available in
> Chinese and available on the WoSign's Chinese site. I believe an
> announcement on the official Chinese site with the link to the incident
> report is also warranted.
>
> On Thursday, September 22, 2016, Richard Wang <rich...@wosign.com
> <javascript:;>> wrote:
>
> > 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
> <javascript:;>
> > <javascript:;>=wosign@lists.mozilla.org <javascript:;>
> <javascript:;>] On Behalf Of
> > Richard Wang
> > Sent: Friday, September 16, 2016 6:05 PM
> > To: Gervase Markham <g...@mozilla.org <javascript:;> <javascript:;>>
> > Cc: mozilla-dev-security-pol...@lists.mozilla.org <javascript:;>
> <javascript:;>
> > 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
> <javascript:;>
> > <javascript:;>
> > 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

Re: Incidents involving the CA WoSign

[Percy]

Richard,
On behalf of most Chinese Internet users who do not speak English, I'm
asking why WoSign is only making the final statement available in Chinese,
but not the incident report. WoSign doesn't even have any statement,
announcement or press release in Chinese regarding any of the incidents
(except this final statement) anywhere.

As WoSign is the largest CA in China, it must be responsible to Chinese
users. I'm requesting WoSign to make the incident report available in
Chinese and available on the WoSign's Chinese site. I believe an
announcement on the official Chinese site with the link to the incident
report is also warranted.

On Thursday, September 22, 2016, Richard Wang  wrote:

> 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 >
> 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: Sanctions short of distrust

[Percy]

Ha. I was the OP of that email. Richard's reply was " From the screenshot, we 
know why Percy hate WoSign so deeply, we know he represent which CA, everything 
is clear now. "

On Thursday, September 22, 2016 at 11:55:43 AM UTC-7, Eric Mill wrote:
> On Wed, Sep 21, 2016 at 6:18 PM, Richard Wang <rich...@wosign.com> wrote:
> 
> >
> > > 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.
> >
> 
> In an earlier thread, someone posted a screenshot of what appeared to be a
> marketing email sent to Let's Encrypt customers, warning them about foreign
> CAs.
> 
> The screenshot image was: https://pbs.twimg.com/media/CrXf7w3W8AA2zd7.jpg:
> large
> 
> And the text as translated by the person who posted the screenshot (which I
> haven't personally verified) was:
> 
> The risks associated with foreign CA:
> 1. Cert revocation
> If foreign CA is influenced by politics and revoke certs for important
> Chinese organizations, the entire system will be paralyzed.
> 
> 2. Information security risks
> If the website uses foreign certs, users need to send information to
> foreign servers in every visit. Time of the visit, the location of the
> visit, IP addresses, and the browser, frequency of the visits are all
> collected by foreign CA. This will leak commercial secrets and sensitive
> data, and is a very risky!
> 
> 
> Here, you're saying you don't consider it to be a threat, and that you
> don't worry if most Chinese online banking and ecommerce websites use a
> foreign CA. Was the screenshot of WoSign's marketing email accurate? And if
> so, what is WoSign committing to doing w/r/t OCSP metadata that it doesn't
> trust foreign CAs to do?
> 
> -- Eric
> 
> 
> >
> >
> > 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
> >
> 
> 
> 
> -- 
> 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: Incidents involving the CA WoSign

[Percy]

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

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

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

>
> Best Regards,
>
> Richard
>
> -Original Message-
> From: Peter Bowen [mailto:pzbo...@gmail.com ]
> Sent: Tuesday, September 20, 2016 10:18 AM
> To: Richard Wang >
> Cc: Nick Lamb >;
> mozilla-dev-security-pol...@lists.mozilla.org 
> Subject: Re: Incidents involving the CA WoSign
>
> Richard,
>
> As someone pointed out on Twitter this morning, it seems that the PSC
> notification for Startcom UK was filed recently:
> https://s3-eu-west-1.amazonaws.com/document-api-images-prod/docs/
> UdxHYAlFj6U9DNs6VBJdnIDv4IQAWd4YKYomMERO_2o/application-pdf
>  Were you unaware of this filing?
>
> Additionally, companies that register to trade on the New York Stock
> Exchange have to file reports with the US Security and Exchange
> Commission.  Qihoo 360 filed a report that included a list of their
> variable interest entities and Qihoo's percent of economic interest in each
> (https://www.sec.gov/Archives/edgar/data/1508913/
> 000114420413022823/v341745_20f.htm
> page F-10).  It also describes all the ways in which Qihoo 360 controls
> these entities, including assuring that Qihoo has decision making authority
> over the entities.
>
> I agree that Mozilla does not require reporting that multiple Root CAs are
> Affiliates.  Perhaps it should.  However, as you know, the CA/Browser Forum
> does require such.  So I don't think it would be a stretch for Mozilla to
> do so.  It is something that should probably be added to the 2.3 policy
> discussion.
>
> Thanks,
> Peter
>
>
> On Mon, Sep 19, 2016 at 6:51 PM, Richard Wang  > wrote:
> > Thanks for your detail info.
> > No worry about this, all companies must be complied with local law.
> >
> > But I really don't care who is my company's shareholder's shareholder's
> shareholder, you need to find out this by yourself if you care.
> >
> > If you think Mozilla must require this, please add to the Mozilla policy
> that require all CA disclose its nine generation including all subordinate
> companies and all parent companies.
> >
> >
> > Best Regards,
> >
> > Richard
> >
> > -Original Message-
> > From: dev-security-policy
> > [mailto:dev-security-policy-bounces+richard 
> =wosign.com@lists.mozilla.o
> > rg] On Behalf Of Nick Lamb
> > Sent: Tuesday, September 20, 2016 9:06 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org 
> > Subject: Re: Incidents involving the CA WoSign
> >
> > On Tuesday, 20 September 2016 01:25:59 UTC+1, Richard Wang  wrote:
> >> 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: Guang Dong Certificate Authority (GDCA) root inclusion request

[Percy]

On Wednesday, August 3, 2016 at 2:45:23 PM UTC-7, Kathleen Wilson wrote:
> This request from Guangdong Certificate Authority (GDCA) is to include the 
> "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and 
> enabled EV treatment.
> 
> GDCA is a nationally recognized CA that operates under China’s Electronic 
> Signature Law. GDCA’s customers are business corporations registered in 
> mainland China, government agencies of China, individuals or mainland China 
> citizens, servers of business corporations which have been registered in 
> mainland China, and software developers.
> 
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1128392
> 
> And in the pending certificates list:
> https://wiki.mozilla.org/CA:PendingCAs
> 
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=8749437
> 
> Noteworthy points:
> 
> * Root Certificate Download URL:
> https://bugzilla.mozilla.org/attachment.cgi?id=8748933
> https://www.gdca.com.cn/cert/GDCA_TrustAUTH_R5_ROOT.der
> 
> * The primary documents are provided in Chinese.
> 
> CA Document Repository: 
> https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/
> http://www.gdca.com.cn/cp/cp
> http://www.gdca.com.cn/cps/cps
> http://www.gdca.com.cn/cp/ev-cp
> http://www.gdca.com.cn/cps/ev-cps
> 
> Translations into English:
> CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
> CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749
> 
> * CA Hierarchy: This root certificate has internally-operated subordinate CAs
> - GDCA TrustAUTH R4 SSL CA (issues 2048-bit SSL certs)
> - GDCA TrustAUTH R4 Generic CA (issues 2048-bit individual certs)
> - GDCA TrustAUTH R4 CodeSigning CA (issues 2048-bit CodeSigning certs)
> - GDCA TrustAUTH R4 Extended Validation SSL CA (issues 2048-bit EV SSL certs)
> - GDCA TrustAUTH R4 Extended Validation Code Signing CA (issues 2048-bit EV 
> CodeSigning certs)
> 
> * This request is to turn on the Websites trust bit.
> 
> CPS section 3.2.5: For domain verification, GDCA needs to check the written 
> materials which can be used to prove the ownership of corresponding domain 
> provided by applicant. Meanwhile, GDCA should ensure the ownership of domain 
> from corresponding registrant or other authoritative third-party databases. 
> During the verification, GDCA needs to perform the following procedures:
> 1. GDCA should confirm that the domain's owner is certificate applicant based 
> on the information queried from corresponding domain registrant or 
> authoritative third-party database and provided by applicant.
> 2. GDCA should confirm that the significant information (such as document 
> information of applicant) in application materials are consistent with the 
> reply of domain's owner by sending email or making phone call based on the 
> contact information (such as email, registrar, administrator's email 
> published at this domain's website, etc.) queried from corresponding domain 
> registrant or authoritative third-party database.
> If necessary, GDCA also need to take other review measures to confirm the 
> ownership of the domain name. Applicant can't refuse to the request for 
> providing appropriate assistance.
> 
> 
> * EV Policy OID: 1.2.156.112559.1.1.6.1
> 
> * Test Website: https://ev-ssl-test-1.95105813.cn/
> 
> * CRL URLs:
> http://www.gdca.com.cn/crl/GDCA_TrustAUTH_R5_ROOT.crl
> http://www.gdca.com.cn/crl/GDCA_TrustAUTH_R4_SSL_CA.crl
> http://www.gdca.com.cn/crl/GDCA_TrustAUTH_R4_Extended_Validation_SSL_CA.crl
> 
> * OCSP URL:
> http://www.gdca.com.cn/TrustAUTH/ocsp
> 
> * Audit: Annual audits are performed by PricewaterhouseCoopers Zhong Tian LLP 
> according to the WebTrust criteria.
> WebTrust CA: https://cert.webtrust.org/SealFile?seal=2024=pdf
> WebTrust BR: https://cert.webtrust.org/SealFile?seal=2025=pdf
> WebTrust EV: https://cert.webtrust.org/SealFile?seal=2026=pdf
> 
> * Potentially Problematic Practices: None Noted
> (http://wiki.mozilla.org/CA:Problematic_Practices)
> 
> This begins the discussion of the request from Guangdong Certificate 
> Authority (GDCA) to include the "GDCA TrustAUTH R5 ROOT" certificate, turn on 
> the Websites trust bit, and enabled EV treatment. At the conclusion of this 
> discussion I will provide a summary of issues noted and action items. If 
> there are outstanding issues, then an additional discussion may be needed as 
> follow-up. If there are no outstanding issues, then I will recommend approval 
> of this request in the bug.
> 
> Kathleen

https://www.ssllabs.com/ssltest/analyze.html?d=www.gdca.com.cn
This server is vulnerable to the OpenSSL Padding Oracle vulnerability 
(CVE-2016-2107) and insecure. Grade set to F.

Maybe someone who has more expertise than me could take a look at this?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

Re: Sanctions short of distrust

[Percy]

On Monday, September 12, 2016 at 2:46:40 PM UTC-7, Ryan Sleevi wrote:
> On Wednesday, August 31, 2016 at 12:43:50 PM UTC-7, Nick Lamb wrote:
> > I have spent some time thinking about this, but I am only one person, and 
> > one with relatively little in-depth knowledge of the Mozilla project, so I 
> > think I will lay out the options I've thought about and invite feedback 
> > though particularly any alternative suggestions.
> 
> Returning to the topic of this thread, there were a number of alternatives 
> put forward that didn't raise to the summary level captured here:
> 
> https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/hj_KMPGUDAAJ
> 
> To recap, and to combine your suggestions, we have:
> A) Distrust with option to manually add back
> B) Distrust with no option to manually add back (aka Blacklist)
> C) Distrust with Whitelist of Certs
>   C.1) Whitelist based on all certs (several hundred thousand)
>   C.2) Whitelist based Alexa Top 1M (~60 thousand)
> D) Trust w/ Heuristic
>   D.1) Certs with notBefore < some date trusted implicitly, certs with 
> notBefore > some date are CT logged
>   D.2) Trust if C=CN is present in subject name (WoSign's proposal)
> E) Trust w/ PR
>   E.1) Require some form of mandatory disclosure of misissuance
> F) Trust w/o any action
> 
> 
> Nick's proposal #1 is was already captured by D1 in the previous thread.
> Nick's proposal #2 is captured by E1
> Nick's proposal #3 is captured by F (no concrete steps were proposed)
> 
> I've not included the RP discussion in the above summary, because I don't 
> believe it talks to actions short of distrust, but about alternative methods 
> of determining trustworthiness. It doesn't provide an actionable framework, 
> for, say dealing with issues that arise when a CA behaves against the public 
> interest.
> 
> 
> To that end, I'm going to offer one more suggestion for consideration:
> G) Distrust with a Whitelist of Hosts
> 
> The issue with C is that it becomes easily inflated by issuing certificates, 
> even if they're not used; that is, a free certificate provider can easily 
> exceed a reasonable size of a whitelist, by issuing many certificates for a 
> given host, even if they're not used.
> 
> Whitelisting by hostname may offer a reasonable solution that balances user 
> need and performance.
> 
> 
> Consider if we start with the list of certificates issued by StartCom and 
> WoSign, assuming the two are the same party (as all reasonable evidence 
> suggests). Extract the subjectAltName from every one of these certificates, 
> and then compare against the Alexa Top 1M. This yields more than 60K 
> certificates, at 1920K in a 'naive' whitelist.
> 
> However, if you compare based on base domain (as it appears in Alexa), you 
> end up with 18,763 unique names, with a much better compressibility. For 
> example, when compared with Chrome's Public Suffix List DAFSA implementation 
> (as one such compressed data structure implementation), this ends up 
> occupying 126K of storage.
> 
> 126K may be within the range of acceptable to ship within a binary. Further, 
> there are a number of things that can be done to reduce this overhead:
> 
> 1) Large vendors (such as microsoft.com and amazonaws.com) appear within this 
> list, but likely don't wish to; this gives a natural reduction function
> 2) This doesn't fully account for revocations
> 3) It could be combined with, say, requiring CT for new certs. While this is 
> hardly a perfect function, given the backdating, it could effectively monitor 
> the issuance of new certificates.
> 4) The Alexa list includes known third-party domain providers (e.x. 
> myqnapcloud.com, myasustor.com) that could be factored out, as they're not 
> centrally managed
> 5) Names naturally expire on this list, giving a reasonable stepping function
> 
> 
> This could be combined with a large scale distrust, and operates on the 
> theory that the primary concerns with a distrust event are minimizing user 
> impact, while allowing sites sufficient time to migrate, and this could offer 
> a one-or-two-release-cycle "graceful turndown" of a CA. If other browsers 
> were able to adopt such a solution, such that the industry could be in rough 
> harmony, this could offer a graduated point to distrust.

I totally agree with Ryan's approach. It seems to be the most practical way and 
quickest to implement considering the severity of the problems. 

A minor suggestion: Mozilla or Google can implement a public-facing portal for 
website owners to request them taking off from the whitelist. The portal can 
work like https://hstspreload.appspot.com/, but rather than checking the 
header, the portal can check whether it's using a non-Wosign/StartCom cert. 
Once verified, the hostname will be removed from whitelist in the next release. 
We can also run those kind of scans periodically to trim the whitelist. 
___
dev-security-policy mailing list

Re: Ambiguous wording or the Mozilla CA security reporting requirement

[Percy]

I agree with Jakob. This is similar to case laws vs statutory law. Even though 
we can get the same understandings from various cases, I believe in this 
situation, it will be clearer to codify such requirements clearly. 


On Monday, September 12, 2016 at 10:38:48 AM UTC-7, Jakob Bohm wrote:
> On 10/09/2016 14:39, Gervase Markham wrote:
> > On 09/09/16 11:59, Jakob Bohm wrote:
> >> Since a major root compromise is generally considered the worst
> >> possible security event for a trusted CA, this wording could easily be
> >> (mis?)understood not to require reporting of lesser security failures,
> >> such as issuing millions (or just hundreds) of certificates without
> >> proper validation etc.
> >
> > Our position on the meaning of this clause, which (by their behaviour)
> > can be said to be shared by many CAs, was set out at the very beginning
> > of the original mail about WoSign.
> >
> 
> Yes, I am aware of this position and suggesting the Mozilla policy be
> changed to reflect its intended meaning.
> 
> This is particularly relevant as one of the CAs currently under
> discussion claimed difficulty understanding that this particular rule
> required them to report lesser incidents.
> 
> 
> Enjoy
> 
> Jakob
> -- 
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded

___
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

[Percy]

On Friday, September 9, 2016 at 2:49:07 AM UTC-7, Gervase Markham 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 legal
> ownership’ in StartCom.”[10]
> 
> On 24th February 2016, Richard Wang wrote: “[StartCom UK] is one of the
> shareholder of [StartCom IL].”[10]
> 
> On 27th February 2016, Eddy Nigg characterised the relationship as
> follows: “StartCom owns its own roots obviously, operates as usual in
> Israel. ... We have a long-standing business relationship and
> cooperation with WoSign which keeps growing.”[10]
> 
> On 2nd September 2016, Richard Wang wrote: “Please don't bind WoSign
> incident problem with StartCom, it is two independent company that one
> registered in China and one located in 

Re: [FORGED] Re: WoSign’s Ownership of StartCom

[Percy]

I found the following info about Andy Ligg.

1) Interestingly, he used addresses/email/phone in HK, UK and Israel various 
domains.
2) He registered various StartEncrypt and StartResell domains in April 2016. 

He is the owner of a list of domains 
epki.cloud  2016-03-25  GODADDY
sccrl.com   2015-05-23  GODADDY.COM, LLC
sslcer.com  2016-05-05  GODADDY.COM, LLC
sslcer.net  2016-05-05  GODADDY.COM, LLC
startauth.com   2016-05-06  GODADDY.COM, LLC
startauth.net   2016-05-06  GODADDY.COM, LLC
startcodesign.com   2016-01-29  GODADDY.COM, LLC
startcom.email  2016-01-18  GODADDY LLC
startencrypt.com2016-04-21  GODADDY.COM, LLC
startencrypt.net2016-04-21  GODADDY.COM, LLC
startesign.com  2016-01-18  GODADDY.COM, LLC
startesign.info 2016-01-18  GODADDY.COM, LLC
startesign.net  2016-01-18  GODADDY.COM, LLC
startesign.org  2016-01-18  GODADDY.COM, LLC
startresell.com 2016-04-27  GODADDY.COM, LLC
startresell.net 2016-04-27  GODADDY.COM, LLC
startssl.biz2016-03-07  GODADDY.COM, INC.
startssl.mobi   2016-03-07  GODADDY.COM, LLC (146)

https://who.is/whois/epki.cloud
Name Andy Ligg
Organization
AddressHong Kong
CityHong Kong
State / Province N/A
Postal Code
Country HK
Phone +44.2079934541
Email webmas...@startcom.uk

https://who.is/whois/startauth.com
startauth.com 
Registered On 2016-05-06
NameAndy Ligg
Organization StartCom CA Limited
Address 4th Floor Imperial House,
Address 15 Kingsway
City London
Postal Code WC2B 6UN
Country UK
Phone+44.2079934170
Email webmas...@startcom.uk

https://who.is/whois/startcodesign.com
startcodesign.com
Name Andy Ligg
Organization StartCom CA Limited
Address 4th Floor Imperial House, 15 K
City London
Postal Code WC2B 6UN
Country UK
Phone +44.2079934541
Email webmas...@startcom.uk

https://who.is/whois/
startssl.biz
Name Andy Ligg
Organization StartCom Limited
Address Ha Sapan 5
City Eilat
Postal Code 8
Country Israel
Phone+972.86344170
webmas...@startssl.com

https://who.is/whois/startencrypt.net
startencrypt.net
Name Andy Ligg
Organization
Address Hong Kong
CityHong Kong
State / ProvinceHK
Postal Code 8
Country HK
Phone+852.2079934308
Email webmas...@startcom.uk


3) https://bugs.chromium.org/p/chromium/issues/detail?id=611672
Certificate Transparency - StartCom CT log server inclusion request
Contact Information:
- Email: c...@startssl.com
- Phone number:  +1.213.341.0329   
- Log Operator: Eddy Nigg, Andy Ligg

Log Server URL: https://ct.startssl.com
___
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

[Percy]

On Wednesday, September 7, 2016 at 3:08:33 AM UTC-7, Richard Wang wrote:
> 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.
> 

Since we already see backdated certificates AND certificates issued without any 
validation, the "C=CN" restriction might be easily defeated if further bugs are 
discovered in the automatic issuance system. 

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

Re: (Optional) list of participants

[Percy]

Percy Alpha; Researcher on Internet security and censorship in China 
http://percya.com ; CA related stuff: Broke the news on China's large scale 
MITM of Github in 2013, iCloud, Outlook, Yahoo in 2014; victim of Great Cannon 
(hijacking HTTP request) DDOS of the website and Github in 2015; called for 
CNNIC's revocation in 2013; monitored CNNIC's censorship on the news of it 
being revoked in 2015. 

On Tuesday, September 6, 2016 at 8:28:53 AM UTC-7, Gervase Markham wrote:
> While we try and evaluate contributions to this forum based on their
> content rather than on who posted them, the issue has been raised that
> it is sometimes useful to know where someone is coming from, who they
> represent, and what experience they have.
> 
> Therefore, I have started an entirely optional list of people who post
> to m.d.s.policy, along with information about them:
> 
> https://wiki.mozilla.org/CA:Policy_Participants
> 
> Please feel free to add yourself if you feel led; please do not add
> anyone other than yourself. This might also be a good place to say, if
> you want to be explicit about it, whether you are representing your
> employer or not.
> 
> Gerv

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

Re: [FORGED] Re: Incidents involving the CA WoSign

[Percy]

Yeah, it's almost impossible to distrust all WoSign authority manually from
keychain access. WoSign has 28 root certs or intermediate certs signed by
other CAs, listed below. (List from
https://github.com/chengr28/RevokeChinaCerts/wiki/ReadMe_Online#about-certificates
)

Certification Authority of WoSign <https://root1evtest.wosign.com/> WoSign
CA Limited <https://www.wosign.com/>
B94294BF91EA8FB64BE61097C7FB001359B676CB
CA 沃通根证书 <https://root2evtest.wosign.com/> WoSign CA Limited
<https://www.wosign.com/> 1632478D89F9213A92008563F5A4A7D312408AD6
Class 1 Primary CA WoSign CA Limited <https://www.wosign.com/>
6A174570A916FBE84453EED3D070A1D8DA442829
Certification Authority of WoSign WoSign CA Limited
<https://www.wosign.com/> 33A4D8BC38608EF52EF0E28A35091E9250907FB9
Certification Authority of WoSign G2 <https://root4evtest.wosign.com/> WoSign
CA Limited <https://www.wosign.com/>
FBEDDC9065B7272037BC550C9C56DEBBF27894E1
CA WoSign ECC Root <https://root5evtest.wosign.com/> WoSign CA Limited
<https://www.wosign.com/> D27AD2BEED94C0A13CC72521EA5D71BE8119F32B
Certification Authority of WoSign StartCom Certification Authority
<https://www.startcom.org/> 868241C8B85AF79E2DAC79EDADB723E82A36AFC3
Certification Authority of WoSign StartCom Certification Authority
<https://www.startcom.org/> 692790DA5189529CC5CE1E16E984277A03023E99
Certification Authority of WoSign StartCom Certification Authority
<https://www.startcom.org/> 804E5FB7DE84F5F5B28347233EAF07846B6070D3
Certification Authority of WoSign StartCom Certification Authority
<https://www.startcom.org/> B0B68AE97CFE2AFACD0DC2010B9D70ACE593E8A6
Certification Authority of WoSign StartCom Certification Authority
<https://www.startcom.org/> 27D5BBE04301E1604839708D172CF09296ED9033
Certification Authority of WoSign UTN-USERFirst-Object
<https://www.comodo.com/> 7C1913D189C46577D7513F980A2CFD7EDCBA0EC9
Certification Authority of WoSign UTN-USERFirst-Object
<https://www.comodo.com/> 1C1ECDCCF764E6168177C5711F33EC9229A29F88
Certification Authority of WoSign G2 Certum CA <https://www.certum.eu/>
B39191CFF08EB6FD8B447C21CAAEF6FC33F1D5AE
Certification Authority of WoSign G2 Certum CA <https://www.certum.eu/>
73FFCA3F815B7A77717FE91912A4DC7B6BFB79CA
CA 沃通根证书 StartCom Certification Authority <https://www.startcom.org/>
D8EFF6C28BB508E4702565F42748454A872BD412
CA 沃通根证书 StartCom Certification Authority <https://www.startcom.org/>
CE335662F0EA6764B95C7F50A995A514ACE8C815
CA 沃通根证书 StartCom Certification Authority <https://www.startcom.org/>
B2FBDA222493A93C38F77C90D4BE6DA17F15F0B0
Certification Authority of WoSign UTN – DATACorp SGC
<https://www.comodo.com/> 56FAADDC596DCF78D585D83A35BC04B690D12736
WoSign Premium Server Authority AddTrust External CA
Root/UTN-USERFirst-Hardware <https://www.comodo.com/>
E3D569137E603E7BACB6BCC66AE943850C8ADF38
WoSign Server Authority AddTrust External CA Root/UTN-USERFirst-Hardware
<https://www.comodo.com/> 3E14B8BD6C568657D852D95D387249AE857B4A39
WoSign SGC Server Authority UTN – DATACorp SGC <https://www.comodo.com/>
6D5A18050D56BFDE525CBE89E8C45DD1B53D12E9
WoSign Client Authority UTN-USERFirst-Client Authentication and Email
<https://www.comodo.com/> FAD4319D4E173FF3853E51C98D21919BF3DA1A1E
WoTrust Premium Server Authority AddTrust External CA
Root/UTN-USERFirst-Hardware <https://www.comodo.com/>
381CBC5048AFD9A02D3E5882D5F22D962B1A5F72
WoTrust Premium Server Authority AddTrust External CA
Root/UTN-USERFirst-Hardware <https://www.comodo.com/>
CF37A5B5C9166BD6B57A56BF67165A584B057241
WoTrust Server Authority AddTrust External CA Root/UTN-USERFirst-Hardware
<https://www.comodo.com/> 337DF96418F08A9355870513AFCEBDC68BCED767
WoTrust SGC Server Authority UTN – DATACorp SGC <https://www.comodo.com/>
46A762F3C3CF3732DE22A8BA1EBBA3BC048F9B8C
WoTrust Client Authority UTN-USERFirst-Client Authentication and Email
<https://www.comodo.com/> 38CFE78D9F1F0B0637AFCAAA3D5549D87C0AA1D0

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


On Tue, Sep 6, 2016 at 8:19 AM, Peter Gutmann <pgut...@cs.auckland.ac.nz>
wrote:

> Nick Lamb <tialara...@gmail.com> writes:
>
> >On Tuesday, 6 September 2016 15:11:00 UTC+1, Peter Gutmann  wrote:
> >> Why would a public CA even need cross-certification from other CAs?
> >
> >Maybe this question has some subtlety to it that I'm missing?
>
> OK, I really meant "that many other CAs".  To take one example, the cross-
> certifying CA known as Usertrust that eventually became part of Comodo has
> been around since the late 1990s, so it's presumably trusted by everything
> under the sun, and then Comodo owns (at least) AddTrust AB, eBiz Networks,
> Positive Software, RegisterFly, Registry Pro, The Code Project, The
> USERTRUST
>

Re: Incidents involving the CA WoSign

[Percy]

On Monday, September 5, 2016 at 3:58:34 PM UTC-7, Peter Bowen wrote:
> On Wed, Aug 24, 2016 at 6:08 AM, Gervase Markham  wrote:
> > 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".
> 
> Gerv and team,
> 
> In addition to the direct impact, I note that WoSign is the subject of
> cross-signatures from a number of other CAs that chain back to roots
> in the Mozilla program (or were in the program).  For example:
> 
> Cross issued to /C=CN/O=WoSign CA Limited/CN=CA
> \xE6\xB2\x83\xE9\x80\x9A\xE6\xA0\xB9\xE8\xAF\x81\xE4\xB9\xA6 by
> /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
> Signing/CN=StartCom Certification Authority expiring
> 2019-12-31T23:59:59Z
> Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
> of WoSign by /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
> Signing/CN=StartCom Certification Authority expiring
> 2019-12-31T23:59:59Z
> 
> Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
> of WoSign G2 by /C=PL/O=Unizeto Sp. z o.o./CN=Certum CA expiring
> 2020-11-02T01:01:59Z
> Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
> of WoSign G2 by /C=PL/O=Unizeto Sp. z o.o./CN=Certum CA expiring
> 2020-11-02T01:59:59Z
> 
> Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
> of WoSign by /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
> Network/OU=http://www.usertrust.com/CN=UTN - DATACorp SGC expiring
> 2019-06-24T19:06:30Z
> Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
> of WoSign by /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
> Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Object expiring
> 2019-07-09T18:40:36Z
> 
> I have two questions:
> 
> 1) Should any action be taken against the operators of these CAs due
> to the incidents listed?
> 
> My view is that the correct answer is "no, unless it is demonstrated
> that the CA operator had knowledge of undisclosed incidents", as I
> believe that the issuer should be able to rely upon the audit reports
> and continued inclusion in the Mozilla trust store as prima facie
> evidence of compliance with Mozilla policy.
> 
> 2) If Mozilla decides to take action that results in WoSign no longer
> being directly trusted, do those CAs with unrevoked unexpired
> cross-signs bear responsibility for any future mis-issuance by WoSign?
> 
> My view is the answer is yes, as WoSign would be a subordinate CA
> rather than a peer being cross-signed.  The Mozilla policy makes it
> clear that "All certificates that are capable of being used to issue
> new certificates, and which directly or transitively chain to a
> certificate included in Mozilla’s CA Certificate Program, MUST be
> operated in accordance with Mozilla’s CA Certificate Policy".
> 
> Thanks,
> Peter

Peter,
I totally agree with your answers. However, relating to question 2, if WoSign 
is restricted to a set of white-listed certs or revoked, I think the 
restriction should apply regardless whether the cert is crossed signed or not. 
This will render question 2 moot, as other CAs are effectively only 
cross-signing the the set of white-listed certs. No certs will be trusted 
anyway, if WoSign is outright revoked either. 
I guess the only situation is that some future (misused) certs will be trusted 
by products that hasn't implemented the whitelist approach, e.g by iOS. Then I 
agree the other root certs should be treated as a subordinate CA.
___
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

[Percy]

On Friday, August 26, 2016 at 12:57:56 PM UTC-7, 233sec Team wrote:
> Wosign's Issue mechanism is high risking for large enterprise.
> This is one prove:
> 
> https://gist.github.com/xiaohuilam/8589f2dfaac435bae4bf8dfe0984f69e
> 
> Alicdn.com is the cdn asset domain name of Taobao/tmall who belong to 
> alibaba, which are Chinese biggest online shopping websites.
> With the fake cert's middle man attack, password stealing, information 
> leaking...

Richard, please also include the incident report for alicdn.com. The whitehat 
(Did you confirm with him, Gerg? ) mentioned "Wosign's Issue mechanism is high 
risking for large enterprise." It might not be an isolated incident, but rather 
a procedural weakness.
___
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

[Percy]

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. 

On Sunday, September 4, 2016 at 2:51:26 AM UTC-7, 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 
> 
> 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 
> 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 

Re: StartCom's StartPKI

[Percy]

Based on the disclosure WoSign/StartCom is trying to bury, WoSign CEO is now 
also in control of StartCom. Hence, the actively misleading information spread 
by him should be taken into consideration when talking about StartCom as well.  
___
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

[Percy]

Ryan,
I agree completely that we shouldn't imply fundamental guilt by
association. However, WoSign threatened legal actions against Itzhak
Daniel's disclosure compiled purely from public sources. I just want to
make sure the disclosure was not buried after the content was taken down.

Richard, the CEO of WoSign, stated "From the screenshot, we know why Percy
hate WoSign so deeply, we know he represent which CA, everything is clear
now." The screenshot refers to
https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/5Lelu0oyDQAJ
and the screenshot proves WoSign is actively misleading the public.
He further seems to think I'm working for Let's Encrypt and consequently
want to undermine WoSign. It is he that needs to answer the questions and
concerned raised rather than discrediting the questioners
or threatening legal actions. For the record, I'm not and have not worked
for Let's Encrypt or any CA.

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


On Sat, Sep 3, 2016 at 12:51 PM, Ryan Sleevi <r...@sleevi.com> wrote:

> Percy,
>
> As I suggested in the other thread, this does not seem a productive or
> fruitful line of inquiry, nor does it seem relevant to the issue at hand,
> nor does it seem to be done respectfully.
>
> That is, the extent of the country of origin of a CA is not itself a
> fundamental issue of trust, nor should translation errors be. I agree that
> there's a line where elements such as actively misleading the public become
> a matter of public concern, but let's try not to suggest there is something
> wrong with being from a particular country, nor that it represents proof of
> wrongdoing.
>
> I believe we are on the cusp of crossing a line here, and would love if we
> could focus on the technical and factual issues, without attempting to
> imply fundamental guilt by association or pseudo-phrenological analysis of
> speech patterns to show some form of wrongdoing.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom's StartPKI

[Percy]

Yeah, their entire website is designed and implemented by someone in China. See 
my analysis here 
http://www.percya.com/2016/09/startcom-operated-solely-in-china.html

On Thursday, August 25, 2016 at 10:11:21 AM UTC-7, rugk wrote:
> Hi,
> I stumbled across this service by StartCom: 
> https://startssl.com/StartPKI (archive link: https://archive.is/GRkAK)
> I got a bit afraid when looking at their nice screenshots 
> (https://archive.is/GRkAK#75%), because they offer intermediate 
> certificates for companies allowing them to issue certificates by 
> themself.
> 
> So I checked their site to find out what this is about.
> The certs are "Trusted by all browsers" 
> (https://archive.is/GRkAK#selection-419.0-419.23).
> So I thought in this case they (StartCom) need to control the process, 
> especially as they allow EV certs to be issued.
> However here is what they state on their website: "StartPKI, let you 
> control your SSL certificate life cycle management by yourself, not by 
> the CA!" (https://archive.is/GRkAK#selection-517.0-517.96)
> This does rather sound as if the company would have a web interface 
> where they can issue certificates like they want...
> 
> So I thought they at least keep the private key on their servers/HSMs. 
> However they mention "FIPS 140 Luna G5 HSM Secured" under "Setup your 
> name issuing CA" (https://archive.is/GRkAK#selection-619.0-631.24), so 
> does this indicate the companies have to setup a HSM? If so, for what if 
> it is not the private key of the intermediate?
> On the other hand they say it you need no "No PKI infrastructure 
> Investment" (https://archive.is/GRkAK#selection-449.0-449.32), but the 
> "All controlled by yourself" 
> (https://archive.is/GRkAK#selection-673.0-673.26) is not a very 
> appeasing statement when it comes to who can issue certificates.
> Also they say you can "Issue certificates instantly" 
> (https://archive.is/GRkAK#selection-425.0-425.28) (for free) I am 
> wondering how this can work for EV certificates.
> 
> On their news page (https://startssl.com/NewsDetails?date=20160428) they 
> say the intermediate CA is "for the exclusive use of the verified 
> organization". But how can they enforce this?
> At least they say that "the intermediate CA will be provided by 
> StartCom's [...] infrastructure", so it seems they keep the intermediate 
> themself.
> 
> So at least they keep the private key. However this still does not 
> answer the question how they control the certificates issued by this 
> intermediate - especially when it comes to EV certificates.
> It is also unclear what kind of verification is made when a company 
> issues a certificate with their own intermediate.
> 
> Also note that there is a difference to StartResell. On their hompage 
> (https://startssl.com/NewsDetails?date=20160530) they also state, that 
> resellers have their own intermediate certificate.
> However there they seem to do the verification by themself and "charge 
> the end user identity validation". This obviously does not happen for 
> StartPKI...
> As StartPKI is "Ready to use in 3 days" 
> (https://archive.is/GRkAK#selection-413.0-413.22) I doubt that they can 
> trust all companies they issue intermediates for to do sane 
> verification.
> 
> The service is all in all quite questionable and statements like "All 
> controlled by yourself" are horrible to hear. I hope this statement is 
> just wrong and they somehow keep control.
> 
> Best regards,
> rugk
> 
> -- 
> I offer PGP support. To send me a PGP-encrypted mail, please ask for my 
> private mail address.

___
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

[Percy]

Andy, are you from the UK office?  Can you explain why your office in UK
fails to identify even the most obvious mistakes on the StartCom website as
outlined in
http://www.percya.com/2016/09/startcom-operated-solely-in-china.html ?
E.g

Start to sell, make big money!
Setup your own website, start to sell your brand SSL certificate to your
customers. Post customer’s identity information to StartSSL, StartCom
charge the validation cost only with 50% off discount, all certificates
issued from your intermediate CA is FREE. StartCom don’t charge your
certificate cost, you make big money!

StartResell is in the background, you focus your sales, we do everything
for you including PKI system, CRL and OCSP distribution, identity
validation etc., we will use your company name to call your customer for
identity validation, no other contact to your customer


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


On Sat, Sep 3, 2016 at 10:29 AM, Andy Ligg <a...@startssl.com> wrote:

> You are completely wrong!
>
> StartCom not only have office in Israel and in China, but also have office
> in UK, welcome to visit our UK office: T05, Castlemead, Lower Castle
> Street, Bristol, BS1 3AG, UK.
>
> And We will setup office in Bilbao, Spain in this month, Inigo Barreia is
> the general manager of StartCom Europe that Eddy announced this in CABF
> mail list.
>
> Regards,
>
> Andy
>
>
> On 2016/9/3 16:17, Percy wrote:
>
>> I did an analysis of the new StartCom website and determined that it was
>> designed and implemented solely in China.  http://www.percya.com/2016/09/
>> startcom-operated-solely-in-china.html  I'm further concerned with the
>> security of "StartResell - Setup your own website, start to sell your brand
>> SSL certificate to your customers". Details here
>> ___
>> 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

[Percy]

I did an analysis of the new StartCom website and determined that it was 
designed and implemented solely in China.  
http://www.percya.com/2016/09/startcom-operated-solely-in-china.html  I'm 
further concerned with the security of "StartResell - Setup your own website, 
start to sell your brand SSL certificate to your customers". Details here
___
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

[Percy]

On Friday, September 2, 2016 at 9:57:24 PM UTC-7, Percy wrote:
> Richard, 
> You claimed on weibo (https://pbs.twimg.com/media/CrZ1Oc6WIAABtrg.jpg:large 
> )that "WoSign has been oppressed by large American companies over the years 
> but has been growing steadily over the past 10 years and is now the 8th 
> largest CA in the world".  Is EFF one of your so called oppressors?  Do you 
> even know what EFF is?

You also claimed (https://pbs.twimg.com/media/CrZ4GV7WgAESKyn.jpg:large) way 
back in 2014 that "If you deploy foreign certificates, you still will not have 
any security in online commerce".  Is it what you truly believe in or were you 
actively trying to mislead potential customers?
___
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

[Percy]

Richard, 
You claimed on weibo (https://pbs.twimg.com/media/CrZ1Oc6WIAABtrg.jpg:large 
)that "WoSign has been oppressed by large American companies over the years but 
has been growing steadily over the past 10 years and is now the 8th largest CA 
in the world".  Is EFF one of your so called oppressors?  Do you even know what 
EFF is?
___
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

[Percy]

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


On Fri, Sep 2, 2016 at 5:04 PM, Richard Wang <rich...@wosign.com> wrote:

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

Are you f**king kidding me? I current do not and have not worked for Let's
Encrypt or EFF in general. Are you accusing me and EFF to collude to take
down WoSign?



>
> BTW, as I said that the two related pages in our website are deleted.
>
> Regards,
>
> Richard
>
> > On 3 Sep 2016, at 02:16, Percy <percyal...@gmail.com> 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
>
___
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

[Percy]

On Friday, September 2, 2016 at 3:07:46 AM UTC-7, Gervase Markham wrote:
> Hi Richard,
> 
> On 01/09/16 04:04, Richard Wang wrote:
> > First, please treat WoSign as a global trusted CA, DON'T stamp as
> > China CA. We need a fair treatment as other worldwide CAs that I am
> > sure WoSign is not the first CA that have incident and not the
> > serious one;
> 
> We are keen to treat WoSign as a global CA. It's certainly true that we
> would be having this discussion about any other global CA which had had
> such a list of incidents. However, it seems that you are advancing
> arguments - such as "we are Chinese; we can't be expected to fully
> understand standards written in English" - which ask for special
> consideration as a Chinese CA rather than a global CA. 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.

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.
---
Dear friend:
I'm *** from WoSign CA. WoSign is the first SSL cert company in China. Your 
website *'s SSL cert is from Let's Encrypt, expiring at Oct, 2016. If you 
switch to WoSign before the expiration you can enjoy buy one year get one year 
free. 

The risks associated with foreign CA:
1. Cert revocation 
If foreign CA is influenced by politics and revoke certs for important Chinese 
organizations, the entire system will be paralyzed. 

2. Information security risks
If the website uses foreign certs, users need to send information to foreign 
servers in every visit. Time of the visit, the location of the visit, IP 
addresses, and the browser, frequency of the visits are all collected by 
foreign CA. This will leak commercial secrets and sensitive data, and is a very 
risky!

3. Server latency
Foreign CA cannot provide 24*7 local support. Servers are overseas and affected 
by submarine cables, latency is 10X. If something happens to submarine cables, 
and cert revocation list is not accessible, important systems with foreign 
certs will be paralyzed. In 2012, there is a incident that submarine cables was 
broken. 

 (contact info stuff)

Best regards and thanks,

WoSign CA Limited. 

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