Re: Incidents involving the CA WoSign

[Peter Kurrasch]

Don't sell your namesake domain short! Sure, the Google domains are subject to 
different types of attacks than ‎most others but any domain with a cert has 
value. For example, I'd be happy to use gerv.net as a landing page for my spam 
campaign or as a phishing site or, even better, as a host for malware in my 
malvertising activities. 

All I'm saying is that revocation is valuable for everyone in all sorts of ways.


  Original Message  
From: Gervase Markham
Sent: Friday, October 7, 2016 4:37 AM
To: Peter Gutmann; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

On 07/10/16 04:21, Peter Gutmann wrote:
> That still doesn't necessarily answer the question, Google have their CRLSets
> but they're more ineffective than effective in dealing with revocations
> (according to GRC, they're 98% ineffective,
> https://www.grc.com/revocation/crlsets.htm). 

That statistic assumes that all revocations are equal, which is clearly
not true. A revoked cert for www.google.com is orders of magnitude more
important to Chrome users than one for www.gerv.net.

Gerv

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

Re: Incidents involving the CA WoSign

[Gervase Markham]

On 10/10/16 08:15, Michael Ströder wrote:
> Which "Chrome users"?

All of them as a collective body.

Standard revocation doesn't hold up in an active attack scenario. If
someone has control of your customers' internet connection sufficient
that they can direct a request that was meant to go to your site to
their site instead (to use their bad cert, which is now revoked), they
can also blackhole the OCSP request.

https://wiki.mozilla.org/CA:RevocationPlan is Mozilla's plan to fix
this. I'm sure Chrome has one too. But simply turning on hard-fail OCSP
without other ecosystem changes is not a runner - too many things break.

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

Re: Incidents involving the CA WoSign

[Michael Ströder]

Gervase Markham wrote:
> On 07/10/16 04:21, Peter Gutmann wrote:
>> That still doesn't necessarily answer the question, Google have their CRLSets
>> but they're more ineffective than effective in dealing with revocations
>> (according to GRC, they're 98% ineffective,
>> https://www.grc.com/revocation/crlsets.htm). 
> 
> That statistic assumes that all revocations are equal, which is clearly
> not true. A revoked cert for www.google.com is orders of magnitude more
> important to Chrome users than one for www.gerv.net.

Which "Chrome users"?

Sure there are some users (at least me) for which my domains are "high-value
domains" and much more important than the Google domains.

Ciao, Michael.

___
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

[Gervase Markham]

On 07/10/16 04:21, Peter Gutmann wrote:
> That still doesn't necessarily answer the question, Google have their CRLSets
> but they're more ineffective than effective in dealing with revocations
> (according to GRC, they're 98% ineffective,
> https://www.grc.com/revocation/crlsets.htm). 

That statistic assumes that all revocations are equal, which is clearly
not true. A revoked cert for www.google.com is orders of magnitude more
important to Chrome users than one for www.gerv.net.

Gerv

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

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

On Fri, Oct 07, 2016 at 03:21:48AM +, Peter Gutmann wrote:
> Kurt Roeckx  writes:
> 
> >This is why browsers have something like OneCRL, so that they actually do
> >know about it and why Rob added that information to the bug tracker (
> >https://bugzilla.mozilla.org/show_bug.cgi?id=906611#c2).
> 
> That still doesn't necessarily answer the question, Google have their CRLSets
> but they're more ineffective than effective in dealing with revocations
> (according to GRC, they're 98% ineffective,
> https://www.grc.com/revocation/crlsets.htm).  Given how hard it is to
> determine whether cross-certifications exist (we really have no way of telling
> until a cross-certificate suddenly turns up somewhere), it'd be good to have
> some firm indication of whether a revocation will actually take effect or not.
> Certainly for CRLSets it seems it won't.

Mozilla now requires the disclosue of all intermedidate certificates,
including those cross-certificates. I understand that the CRL
information for all of them should be provided too, and that
Mozilla will import all those in OneCRL. So the problem would be
the undisclosed certificates. In theory we would could go and make
a whitelist of the disclosed ones. I'm not sure if Mozilla actually
has any plans for that.

We should at some point probably also start to add the known but
undisclosed ones to OneCRL.


Kurt

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

Re: Incidents involving the CA WoSign

[Peter Gutmann]

Kurt Roeckx  writes:

>This is why browsers have something like OneCRL, so that they actually do
>know about it and why Rob added that information to the bug tracker (
>https://bugzilla.mozilla.org/show_bug.cgi?id=906611#c2).

That still doesn't necessarily answer the question, Google have their CRLSets
but they're more ineffective than effective in dealing with revocations
(according to GRC, they're 98% ineffective,
https://www.grc.com/revocation/crlsets.htm).  Given how hard it is to
determine whether cross-certifications exist (we really have no way of telling
until a cross-certificate suddenly turns up somewhere), it'd be good to have
some firm indication of whether a revocation will actually take effect or not.
Certainly for CRLSets it seems it won't.

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

Re: Incidents involving the CA WoSign

[Man Ho (Certizen)]

It is an interesting aspect that the Mozilla community has not discussed
thoroughly, or at all.

Cross-signing a third party intermediate cert is equivalent to sharing
of trust, that any CA should only consider it with extreme care. Is it
possibly know how many intermediate cert that is cross-signed by Comodo?
Is there any Comodo's practice statement of cross-signing ? Comodo seems
to be quite keen on this kind of business even after the lesson learn
from its last incident in 2011
(https://blog.mozilla.org/security/2011/03/25/comodo-certificate-issue-follow-up/).


On 10/5/2016 4:43 AM, Kurt Roeckx wrote:
> I can't remember if there were other cross signatutures.


___
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

[Kurt Roeckx]

On Wed, Oct 05, 2016 at 01:30:37PM +, Peter Gutmann wrote:
> Rob Stradling  writes:
> 
> >Easy.  It doesn't make a sound.  Unrevoked certificates don't make sounds
> >either.
> 
> What I was really asking, in a tongue-in-cheek way, was whether there was any
> indication of how successfully the information could be propagated to
> browsers.

This is why browsers have something like OneCRL, so that they
actually do know about it and why Rob added that information
to the bug tracker
(https://bugzilla.mozilla.org/show_bug.cgi?id=906611#c2).

I'm just wondering if that was the correct bug to report this on
and that he shouldn't have opened a new one.

Anyway, Rob wrote there:
> I think the combination of other measures previously taken (the
> removal of the "UTN - DATACorp SGC" root certificate, the
> revocation/blacklisting of the cross-certificates issued to "UTN -
> DATACorp SGC", and the technical constraints in these 3
> cross-certificates issued to WoSign) should mean that these 3
> cross-certificates are already not trusted by Mozilla users.


Kurt

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

Re: Incidents involving the CA WoSign

[Michael Ströder]

Peter Gutmann wrote:
> Rob Stradling  writes:
> 
>> Easy.  It doesn't make a sound.  Unrevoked certificates don't make sounds
>> either.
> 
> What I was really asking, in a tongue-in-cheek way, was whether there was any
> indication of how successfully the information could be propagated to
> browsers.

Since the heroic Mozilla devs removed CRL support from Firefox, nope.

Ciao, Michael.

___
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

[okaphone . elektronika]

> >Easy.  It doesn't make a sound.  Unrevoked certificates don't make sounds
> >either.
> 
> What I was really asking, in a tongue-in-cheek way, was whether there was any
> indication of how successfully the information could be propagated to
> browsers.

Good question. Regardless of the answer, information that doesn't exist cannot 
be propagated at all. So revoking seems te be a start... and a statement. I'd 
say it does make a sound. ;-)

CU Hans
___
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

[Peter Gutmann]

Rob Stradling  writes:

>Easy.  It doesn't make a sound.  Unrevoked certificates don't make sounds
>either.

What I was really asking, in a tongue-in-cheek way, was whether there was any
indication of how successfully the information could be propagated to
browsers.

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

Re: Incidents involving the CA WoSign

[Rob Stradling]

On 05/10/16 14:09, Peter Gutmann wrote:
> Rob Stradling  writes:
> 
>> Today we have revoked (via CRL and OCSP) all 3 of the cross-certificates that
>> we'd issued to WoSign:
> 
> This allows us to examine the modern Internet variant of an old philosophical
> question, "If a certificate is revoked in the web PKI and no one checks the
> CRL, does it make a sound?".

Easy.  It doesn't make a sound.  Unrevoked certificates don't make
sounds either.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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

[Peter Gutmann]

Rob Stradling  writes:

>Today we have revoked (via CRL and OCSP) all 3 of the cross-certificates that
>we'd issued to WoSign:

This allows us to examine the modern Internet variant of an old philosophical
question, "If a certificate is revoked in the web PKI and no one checks the
CRL, does it make a sound?".

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

Re: Incidents involving the CA WoSign

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

[Rob Stradling]

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

___
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

[Gervase Markham]

On 23/09/16 12:38, Richard Wang wrote:
> Please check this news (Feb 25th 2015) in OSCCA website:
> http://www.oscca.gov.cn/News/201312/News_1254.htm that all China
> licensed CA finished the PKI/CA system upgrade that all licensed CA
> MUST be able to issue SM2 certificate to subscribers.

I have only Google Translate to go on, but I can't see how that
announcement says that all licensed CAs MUST issue SM2 certificates to
subscribers from their _publicly-trusted_ roots. As you know, you can
install additional root certificates in any browser for testing purposes.

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

WebTrust is not a USA standard; it would be better to describe it as an
everywhere-but-Europe standard - and I believe even some European CAs
have WebTrust audits. But anyway, this is nothing to do with audit
standards and WebTrust vs. ETSI, this is to do with the Baseline
Requirements, which are a global standard for trust in the Web PKI.

> We know issuing SM2 cert is not complied with BR, but you can treat
> it as "compelled" by regulations, 

There is a mechanism in the BRs (section 9.16.3) for a CA to explain
that they have been compelled by local law to do something violating the
BRs. They can then document it and do it, as long as the CAB Forum is
notified. That did not happen in this case. I'm fairly sure you know
about this section because we've just passed a ballot amending it (which
you voted in favour of), and we've debated it several times.

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

Re: Incidents involving the CA WoSign

[Jakob Bohm]

On 23/09/2016 14:12, Kurt Roeckx wrote:

On 2016-09-23 13:38, Richard Wang wrote:

Hi Gerv,

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

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

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


There seem to be several governments that define their own standard,
like GOST in Russia, SEED in South Korea, and the SM2/SM3/SM4 in China.
I guess you could also see AES as a USA standard and Camellia as a
Japanese standard.



I think in this case SM2 should be compared to the NIST curves, whose
design was not reviewed by anyone from outside NIST/NSA.  Outside the
CA/B forum, there seems to be growing support for other curves such as
the BrainPool curves and the Ed25519 curve.


Internationally we do not want to support all such standards, which is
why we select some. I think this selection is mostly based on the trust
that there is in that algorithm based on international review of them.

The only suggestion I have is that if the government requires you to use
those algorithm for certain certificates that you use a separate CA root
for that.



Such artificial fragmentation reduces algorithm and curve agility in
the worldwide Internet, increasing the risk that the only "permitted"
algorithms are all broken before replacements become "permitted".
having a specific BR rule banning any curve except 3 curves from a
single government project in a single country certainly looks like a
very bad idea.


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

[Kurt Roeckx]

On 2016-09-23 13:38, Richard Wang wrote:

Hi Gerv,

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

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

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


There seem to be several governments that define their own standard, 
like GOST in Russia, SEED in South Korea, and the SM2/SM3/SM4 in China. 
I guess you could also see AES as a USA standard and Camellia as a 
Japanese standard.


Internationally we do not want to support all such standards, which is 
why we select some. I think this selection is mostly based on the trust 
that there is in that algorithm based on international review of them.


The only suggestion I have is that if the government requires you to use 
those algorithm for certain certificates that you use a separate CA root 
for that.



Kurt

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

RE: Incidents involving the CA WoSign

[Richard Wang]

Hi Gerv,

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

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

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

We revoked the SM2 certificate after finishing the test.


Regards,

Richard

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

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

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

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

Re: Incidents involving the CA WoSign

[Gervase Markham]

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

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

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

Re: Incidents involving the CA WoSign

[Gervase Markham]

On 23/09/16 07:55, Richard Wang wrote:
> This is the final statement about the incident: 
> https://www.wosign.com/report/WoSign_final_statement_09232016.pdf (in English)

Thank you.

Gerv

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

Re: Incidents involving the CA WoSign

[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 <rich...@wosign.com> 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:;>=wosign@lists.mozilla.org <javascript:;>] On Behalf Of
> Richard Wang
> Sent: Friday, September 16, 2016 6:05 PM
> To: Gervase Markham <g...@mozilla.org <javascript:;>>
> Cc: mozilla-dev-security-pol...@lists.mozilla.org <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:;>
> 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 <javascript:;>
> https://lists.mozilla.org/listinfo/dev-security-policy
>


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

RE: Incidents involving the CA WoSign

[Richard Wang]

Hi Gerv,

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

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

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

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


Best Regards,

Richard Wang
CEO
WoSign CA Limited


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

Hi Gerv,

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

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


Best Regards,

Richard Wang
CEO
WoSign CA Limited


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

Hi Richard,

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

Unfortunately, I think we may be only beginning.

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

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

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

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

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

With best wishes,

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

RE: Incidents involving the CA WoSign

[Richard Wang]

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


Best Regards,

Richard

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

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

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

Thanks.


Best Regards,

Richard

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

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

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

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

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

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

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

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

RE: Incidents involving the CA WoSign

[Richard Wang]

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

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

Thanks.


Best Regards,

Richard

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

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

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

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

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

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

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

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

Re: Incidents involving the CA WoSign

[Peter Bowen]

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

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

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

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

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

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

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

RE: Incidents involving the CA WoSign

[Richard Wang]

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

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

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

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


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


Best Regards,

Richard


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

RE: Incidents involving the CA WoSign

[Richard Wang]

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

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

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

I wish I said this clearly, thanks.


Best Regards,

Richard

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

Richard,

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

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

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

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

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

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

Thanks,
Peter

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

Re: Incidents involving the CA WoSign

[Peter Bowen]

Richard,

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

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

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

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

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

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

Thanks,
Peter

On Wed, Sep 21, 2016 at 7:26 AM, Richard Wang <rich...@wosign.com> wrote:
> Hi Gerv,
>
> See below inline, thanks.
>
> Regards,
>
> Richard
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
> Behalf Of Gervase Markham
> Sent: Wednesday, September 21, 2016 9:19 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Incidents involving the CA WoSign
>
> Hi Richard,
>
> Thanks for the additional information.
>
> On 21/09/16 11:11, Richard Wang wrote:
>> Some SHA-1 certificate is free SSL certificate that no any reason for
>> us to help them get the SHA-1 certificate if we are intentional, and
>> some certificate is even never used or even not retrieved from our
>> system, this also can be certified it is a normal order without any
>> doubt.
>
> I have examined the spreadsheet you sent (note: may not be available to 
> mozilla.dev.security.policy participants due to lack of attachment support). 
> The "Categrory 4 - 3:  12 Normal FREE DV SSL Certificates"
> contains 12 certificates, which have no cost associated with them, and no 
> identity vetting other than domain control. Why did each of these take over a 
> month, and in some cases nearly 4 months, to be issued? What was the hold-up?
> -
> R: You can place order there and don't do the domain validation, 4 months 
> later, you finished the domain control validation, then issue the 
> certificate. Please try it by yourself here: https://buy.wosign.com/free/
> --
>> I think there are many reasons to stop to sign it due to double check,
>> for EV order, it must pass at least 6 person’s check:
>
> Yes, indeed. But at what point during these checks do the following events 
> happen?
>
> A) Pre-cert is created and signed (if needed)
> B) Pre-cert is sent to CT (if needed)
> C) Real cert is created and signed
> D) Cert is sent to the customer
>
> I would expect none of these things to happen until all checks are completed. 
> We know from previous conversations that your step 7 (next day review) 
> happens after C) and D). Where do those four events fit into your seven 
> steps, exactly?
> -
> R: not of all. The process is stopped after pre-signed the cert but not post 
> to CT log server.
> -
>> Not the case, only one simple bug from CT Post system. I try to say
>> more clearly.
>> https://crt.sh/?serial=6D24E483E27F55479C5C55

Re: Incidents involving the CA WoSign

[Richard Wang]

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


Best Regards,

Richard

On Sep 21, 2016, at 22:54, Kurt Roeckx > 
wrote:

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

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


Kurt

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

[Kurt Roeckx]

On 2016-09-21 16:26, Richard Wang wrote:

R: You can place order there and don't do the domain validation, 4 months 
later, you finished the domain control validation, then issue the certificate. 
Please try it by yourself here: https://buy.wosign.com/free/


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



Kurt

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

Re: Incidents involving the CA WoSign

[Gervase Markham]

On 24/08/16 14:08, 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. 

I have recently updated
https://wiki.mozilla.org/CA:WoSign_Issues
to draw some conclusions for some of the issues, so I wanted to re-draw
the group's attention to this document. Investigations are continuing,
however, and this is not the last word on some of the matters listed.

Gerv



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

RE: Incidents involving the CA WoSign

[Richard Wang]

Hi Gerv,

See below inline, thanks.

Regards,

Richard

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

Hi Richard,

Thanks for the additional information.

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

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

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

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

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

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

Re: Incidents involving the CA WoSign

[Gervase Markham]

Hi Richard,

Thanks for the additional information.

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

I have examined the spreadsheet you sent (note: may not be available to
mozilla.dev.security.policy participants due to lack of attachment
support). The "Categrory 4 - 3:  12 Normal FREE DV SSL Certificates"
contains 12 certificates, which have no cost associated with them, and
no identity vetting other than domain control. Why did each of these
take over a month, and in some cases nearly 4 months, to be issued? What
was the hold-up?

> I think there are many reasons to stop to sign it due to double 
> check, for EV order, it must pass at least 6 person’s check:

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

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

I would expect none of these things to happen until all checks are
completed. We know from previous conversations that your step 7 (next
day review) happens after C) and D). Where do those four events fit into
your seven steps, exactly?

> Not the case, only one simple bug from CT Post system. I try to say 
> more clearly.
> https://crt.sh/?serial=6D24E483E27F55479C5C555B37745353 is ordered in
> 19th Dec. 2015, and system pre-signed the pre-cert using SHA-1, no
> any problem. But it is stopped due to some more check. At 4th Jan.
> 2016, this order finished the final check and go to signing server,
> signing server generated a new SHA-2 pre-cert to post to CT log
> server since SHA-1 is not allowed, and get SCT data to the
> certificate, this is the second certificate: 
> https://crt.sh/?serial=31742a2b12809bfca04cffc050903837, also no any 
> problem. The problem is the CT post system have a bug that posted
> the two related pre-cert to CT log server (SHA-1 pre-cert is the
> original one, and SHA-2 pre-cert is the new copied one), then get
> two certificates one signed with SHA-1 and one is SHA-2.  We also
> posted the two issued certificates to CT log server later.

But that's not how CT works. You don't sent the CT server a pre-cert and
get a cert back. You send it a pre-cert, and it sends SCTs back. You
then need to get those SCTs, incorporate them into a new certificate
which has the SCTs but not the poison extension, and then sign that
using your signing server, and then store it in your database. All that
happened by mistake, due to a single bug? You stored the certificate in
your system for a number of months because you still had it in September
when you uploaded it to CT.

> The six certificates are revoked after someone pointed it out in the
> email discussion, then we try to find out the reason and know that
> this is a bug from CT Post system, then we revoked the six
> certificate, 

So you discovered the bug in January and fixed it, but did not look to
see if it had led to any misissued certificates until the bug was
discussed in August/September?

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

RE: Incidents involving the CA WoSign

[Richard Wang]

See below inline, thanks.



Best Regards,



Richard



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



Hi Richard,



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

> Hi Gerv,

>

> This is the final report:

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

>

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



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



Issue H: Duplicate Serial Numbers



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



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

---

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

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

--



Issue S: Backdated SHA-1 Certs



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

-

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





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

---

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

---



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

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

---

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

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

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

--



Issue S, Category 1



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



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

Re: Incidents involving the CA WoSign

[Peter Bowen]

On Tue, Sep 20, 2016 at 12:23 AM, 谭晓生 <tanxiaosh...@360.cn> wrote:
> I’m Xiaosheng Tan, the Chief Security Officer of Qihoo 360, on the inquiry of 
> the disclosure of Wosign deal, we are not obligated to disclose it under the 
> SEC regulation

I apologize if I implied that you were.  I am sure that WoSign is too
small of an interest to require disclosure.

> Even Richard is the CEO of Wosign, he is not authorized to do any comments to 
> Qihoo 360 legally, thanks for the understanding.

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

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

2) Does Qihoo 360, a Qihoo 360 subsidiary, a Qihoo 360 VIE, or a Qihoo
360 VIE subsidiary, or a combination of those own or control a
majority of shares in WoSign?

Thanks,
Peter


>
> Thanks,
> Xiaosheng
>
> Xiaosheng Tan, Chief Security Officer
> Qihoo 360
> E-Mail: tanxiaosh...@360.cn
> Web: www.360.cn <http://www.360.cn/>
> Address: Bldg 2, 6 Haoyuan, Jiuxianqiao Rd, Chaoyang Dist, Beijing, China 
> 100015
>
>
> 在 16/9/20 下午2:05，“dev-security-policy 代表 
> Percy”<dev-security-policy-bounces+tanxiaosheng=360...@lists.mozilla.org 代表 
> percyal...@gmail.com> 写入:
>
> On Monday, September 19, 2016, Richard Wang <rich...@wosign.com> 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 <javascript:;>]
>     > Sent: Tuesday, September 20, 2016 10:18 AM
> > To: Richard Wang <rich...@wosign.com <javascript:;>>
> > Cc: Nick Lamb <tialara...@gmail.com <javascript:;>>;
> > mozilla-dev-security-pol...@lists.mozilla.org <javascript:;>
> > Subject: Re: Incidents involving the CA WoSign
> >
> > Richard,
> >
> > As someone pointed out on Twitter this morning, it seems that the PSC
> > notification for Startcom UK was filed recently:
> > https://s3-eu-west-1.amazonaws.com/document-api-images-prod/docs/
> > UdxHYAlFj6U9DNs6VBJdnIDv4IQAWd4YKYomMERO_2o/application-pdf
> >  Were you unaware of this filing?
> >
> > Additionally, companies that register to trade on the New York Stock
> > Exchange have to file reports with the US Security and Exchange
> > Commission.  Qihoo 360 filed a report that included a list of their
> > variable interest entities and Qihoo's percent of economic interest in 
> each
> > (https://www.sec.gov/Archives/edgar/data/1508913/
> > 000114420413022823/v341745_20f.htm
> > page F-10).  It also describes all the ways in which Qihoo 360 controls
> > these entities, including assuring that Qihoo has decision making 
> authority
> > over the entities.
> >
> > I agree that Mozilla does not require reporting that multiple Root CAs 
> are
> > Affiliates.  Perhaps it should.  However, as you know, the CA/Browser 
> Forum
> > does require such.  So I don't think it would be a stretch for Mozilla 
> to
> > do so.  It is something that should probably be added to the 2.3 policy
> > discussion.
> >
> > Thanks,
> > Peter
> >
> >
> > On Mon, Sep 19, 2016 at 6:51 PM, Richard Wang <rich...@wosign.com
> > <javascript:;>> 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 

Re: Incidents involving the CA WoSign

[Gervase Markham]

On 21/09/16 11:10, Kurt Roeckx wrote:
> I didn't read it like that, and that the assets they have in WoSign
> should be more than 10% of the total assets.  So that WoSign would be
> more than 10% of the USD$9.99B.

Oops. You are right. My apologies! I thought the benchmark was the size
of the subsidiary, not the size of the registrant.

Anyway, as I said, no wrongdoing has been suggested by Mozilla.

Gerv

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

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

On 2016-09-21 12:11, Richard Wang wrote:

Please check the first 313 certificate serial is 
“56D1570DA645BF6B44C0A7077CC6769” and the second 27 certificate is 
“D3BBDC3A0175E38F9D0070CD050986A” that only 31 bytes. But our serial number 
rule is 32 bytes.


This is a little misleading. The hex encoding is 31 / 32 characters. 
It's probably more useful to say that it has 128 bit, and you had a 
problem is the top 4 bits where all a 0.



the signing system has a bug that don’t know how to deal with this kind of 
serial and locked to use this same serial number to sign the certificate.


That's a rather weird failure mode. But it was perfectly able to sign 
it, it just didn't generate a new one. And I'm a little concerned that 
this failure mode can happen again.



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


Why is the SHA-1 blocked at the Buy level and not at the PKI level?


Kurt

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

RE: Incidents involving the CA WoSign

[Richard Wang]

See below inline, thanks.

Best Regards,

Richard

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

Hi Richard,

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

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

Issue H: Duplicate Serial Numbers

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

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

Issue S: Backdated SHA-1 Certs

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


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

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

Issue S, Category 1

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

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

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

On 2016-09-21 11:16, Gervase Markham wrote:

Hi Xiaosheng,

On 20/09/16 16:31, 谭晓生 wrote:

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


Well, if we were using a dictionary definition of "significant" as used
in normal English conversation, that would make sense :-) However, the
SEC's definition is not related to the size of the company compared to
its parent, or related to whether the parent company's employees start
running the subsidiary company, or whether the company's activities are
supporting the parent's key business areas. The SEC cares about what
percentage of the subsidiary company is owned or controlled by the
parent. And 84%, which appears to be the correct figure here, is much
more than the minimum thresholds set out in the part of the regulations
you helpfully quoted.


I didn't read it like that, and that the assets they have in WoSign 
should be more than 10% of the total assets.  So that WoSign would be 
more than 10% of the USD$9.99B.



Kurt

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

Re: Incidents involving the CA WoSign

[Gervase Markham]

Hi Xiaosheng,

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

Well, if we were using a dictionary definition of "significant" as used
in normal English conversation, that would make sense :-) However, the
SEC's definition is not related to the size of the company compared to
its parent, or related to whether the parent company's employees start
running the subsidiary company, or whether the company's activities are
supporting the parent's key business areas. The SEC cares about what
percentage of the subsidiary company is owned or controlled by the
parent. And 84%, which appears to be the correct figure here, is much
more than the minimum thresholds set out in the part of the regulations
you helpfully quoted.

But again, this is for you and the SEC to sort out :-)

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

Re: Incidents involving the CA WoSign

[Erwann Abalea]

Bonjour,

Qihoo 360 is already a CABForum member in the "Internet Browser Software 
Vendors" category.

Le mardi 20 septembre 2016 17:55:03 UTC+2, 谭晓生 a écrit :
> Yes, you are correct, we also invested in Opera, but just a smaller share 
> holders, not a majority one.
> 
> Thanks，
> Xiaosheng Tan
> Sent from 360 Q5 Mobile Phone
> 
> 发件人： Kurt Roeckx <k...@roeckx.be>
> 发送时间： 2016年9月20日 23:45
> 收件人： mozilla-dev-security-pol...@lists.mozilla.org
> 主题： Re: Incidents involving the CA WoSign
> 
> On 2016-09-20 17:31, 谭晓生 wrote:
> > Dear Gerv and all,
> >
> > Qihoo 360 is a company valued at USD$9.99B as it finished the privatization 
> > on July 15th 2016, we have invested in more than 200 companies across the 
> > world, Wosign is just a very small one and we even do not have any people 
> > sent to this company after the investment, the major businesses of Qihoo 
> > 360 are security software for consumer, we are the largest player of 
> > anti-virus software in China, No.2 search engine in China and one of the 
> > top gaming platform in China, No.1 PC browser in China, the total revenue 
> > is about USD$1.6B last year, that’s might help to understand that why the 
> > layers don’t think Wosign is a "significant subsidiary".
> 
> I don't know much about the CAB rules, but from what I understand of
> that is that Qihoo 360 has both a browser and a CA.
> 
> 
> Kurt
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

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

Re: Incidents involving the CA WoSign

[谭晓生]

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

Thanks，
Xiaosheng Tan
Sent from 360 Q5 Mobile Phone

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

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

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


Kurt

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

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

On 2016-09-20 17:31, 谭晓生 wrote:

Dear Gerv and all,

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


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



Kurt

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

Re: Incidents involving the CA WoSign

[谭晓生]

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

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

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

Thanks,
Peter


>
> Thanks,
> Xiaosheng
>
> Xiaosheng Tan, Chief Security Officer
> Qihoo 360
> E-Mail: tanxiaosh...@360.cn
> Web: www.360.cn <http://www.360.cn/>
> Address: Bldg 2, 6 Haoyuan, Jiuxianqiao Rd, Chaoyang Dist, Beijing, China 
100015
>
>
> 在 16/9/20 下午2:05，“dev-security-policy 代表 
Percy”<dev-security-policy-bounces+tanxiaosheng=360...@lists.mozilla.org 代表 
percyal...@gmail.com> 写入:
>
> On Monday, September 19, 2016, Richard Wang <rich...@wosign.com> 
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 <javascript:;>]
> > Sent: Tuesday, September 20, 2016 10:18 AM
> > To: Richard Wang <rich...@wosign.com <javascript:;>>
> > Cc: Nick Lamb <tialara...@gmail.com <javascript:;>>;
> > mozilla-dev-security-pol...@lists.mozilla.org <javascript:;>
> > Subject: Re: Incidents involving the CA WoSign
> >
> > Richard,
> >
> > As someone pointed out on Twitter this morning, it seems that the 
PSC
> > notification for Startcom UK was filed recently:
> > https://s3-eu-west-1.amazonaws.com/document-api-images-prod/docs/
> > UdxHYAlFj6U9DNs6VBJdnIDv4IQAWd4YKYomMERO_2o/application-pdf
> >  Were you unaware of this filing?
> >
> > Additionally, companies that register to trade on the New York Stock
> > Exchange have to file reports with the US Security and Exchange
> > Commission.  Qihoo 360 filed a report that included a list of their
> > variable interest entities and Qihoo's percent of economic interest 
in each
> > (https://www.sec.gov/Archives/edgar/data/1508913/
> > 000114420413022823/v341745_20f.htm
> > page F-10).  It also describes all the ways in which Qihoo 360 
controls
> > these entities, including assuring that Qihoo has decision making 
authority
> > over the entities.
> >
> > I agree that Mozilla does not require reporting that multiple Root 
CAs are
> > Affiliates.  Perhaps it should.  However, as you know, the 
CA/Browser Forum
> > does require such.  So I don't think it would be a stretch for 
Mozilla to
> > do so.  It is something that should probably be added to the 2.3 
policy
> > discussion.
> >
> > Thanks,
> > Peter
> >
> >
> > On Mon, Sep 19, 2016 at 6:51 PM, Richard Wang <rich...@wosign.com
> > <javascript:;>> 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

Re: Incidents involving the CA WoSign

[谭晓生]

Dear Gerv and all,

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

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

Hello Xiaosheng,

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

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

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

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

Gerv


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

Re: Incidents involving the CA WoSign

[Gervase Markham]

Hi Richard,

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

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

Issue H: Duplicate Serial Numbers
-

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

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

Issue S: Backdated SHA-1 Certs
--

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

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

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

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

Issue S, Category 1

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

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

6) Taking as an example these two certs:
https://crt.sh/?serial=6D24E483E27F55479C5C555B37745353
and their SHA-256 counterparts:
https://crt.sh/?serial=31742a2b12809bfca04cffc050903837

On January 4th 2016, you CT-logged a SHA-1 pre-cert, got some SCTs from
the CT server, and then (mistakenly) created the SHA-1 cert and stored
it in your internal log. (Later, you uploaded it to CT as part of your
batch upload.) On the same day, January 4th 2016, you also CT-logged a
SHA-256 pre-cert, got some SCTs back from the CT server, and then
created a SHA-256 cert, to send to the customer. These two processes
seem very similar, so I would expect the certificate contents to be very
similar. Why, then, does the SHA-1 cert have a notBefore of 2015-12-19,
whereas the SHA-256 cert has a notBefore of 2016-01-04?

7) You say these certificates were misissued due to a bug. It seems that
the effect of the bug was such that it incorrectly retained the SHA-1
pre-cert version of the cert (created before 2016-01-01), sent it to CT
(on 4th Jan), received the SCTs, incorporated them into the cert, signed
the cert using SHA-1 (after 2016-01-01), and then stored it in your
internal systems? That seems like quite an extensive bug.

8) You say that the six certs in category 1 are all now revoked. When
did you revoke them? If this was not at the time you discovered and
fixed the bug which created them (around 18th January 2016), why not?


I may have some more questions later, as I am still working through the
report. However, I thought I'd give you a chance to get started on these
ones :-) Thanks for any additional information you can provide,

Gerv

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

Re: Incidents involving the CA WoSign

[Gervase Markham]

Hello Xiaosheng,

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

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

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

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

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

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

[Peter Gutmann]

Peter Bowen  writes:

>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

So if I'm reading that correctly, Startcom UK is majority- or entirely owned
(both are > 25%, <= 50%) by Jianming Dong and Xianghong Shi?

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

Re: Incidents involving the CA WoSign

[Percy]

On Monday, September 19, 2016, Richard Wang <rich...@wosign.com> 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 <javascript:;>]
> Sent: Tuesday, September 20, 2016 10:18 AM
> To: Richard Wang <rich...@wosign.com <javascript:;>>
> Cc: Nick Lamb <tialara...@gmail.com <javascript:;>>;
> mozilla-dev-security-pol...@lists.mozilla.org <javascript:;>
> Subject: Re: Incidents involving the CA WoSign
>
> Richard,
>
> As someone pointed out on Twitter this morning, it seems that the PSC
> notification for Startcom UK was filed recently:
> https://s3-eu-west-1.amazonaws.com/document-api-images-prod/docs/
> UdxHYAlFj6U9DNs6VBJdnIDv4IQAWd4YKYomMERO_2o/application-pdf
>  Were you unaware of this filing?
>
> Additionally, companies that register to trade on the New York Stock
> Exchange have to file reports with the US Security and Exchange
> Commission.  Qihoo 360 filed a report that included a list of their
> variable interest entities and Qihoo's percent of economic interest in each
> (https://www.sec.gov/Archives/edgar/data/1508913/
> 000114420413022823/v341745_20f.htm
> page F-10).  It also describes all the ways in which Qihoo 360 controls
> these entities, including assuring that Qihoo has decision making authority
> over the entities.
>
> I agree that Mozilla does not require reporting that multiple Root CAs are
> Affiliates.  Perhaps it should.  However, as you know, the CA/Browser Forum
> does require such.  So I don't think it would be a stretch for Mozilla to
> do so.  It is something that should probably be added to the 2.3 policy
> discussion.
>
> Thanks,
> Peter
>
>
> On Mon, Sep 19, 2016 at 6:51 PM, Richard Wang <rich...@wosign.com
> <javascript:;>> 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 <javascript:;>
> =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 <javascript:;>
> > Subject: Re: Incidents involving the CA WoSign
> >
> > On Tuesday, 20 September 2016 01:25:59 UTC+1, Richard Wang  wrote:
> >> This case is WoSign problem, you found out all related subordinate
> companies and all related parent companies that up to nine generations! I
> think this is NOT the best practice in the modern law-respect society.
> >
> > It seems the governments of the European Union countries (including the
> UK where one of the mentioned companies is located) disagree with you about
> whether this is best practice.
> >
> > Identifying individual human persons behind a company is a key plank of
> their anti-money laundering and anti-tax evasion policies. To identify
> these human persons it is necessary to look through any number (even more
> than nine) of layers of corporate ownership. In the UK the legal term is
> Persons with Significant Control and PSC registration is mandatory since
> this summer, a company registered in the UK is obliged to figure out if
> there are such Persons and if so list them in its routine filings. Failing
> to properly investigate, or concealing the truth about control of the
> company is punishable by forfeiture, ie the state would seize the company's
> assets.
>


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

RE: Incidents involving the CA WoSign

[Richard Wang]

Thanks for your pointing out one of the very important evidence for the 
transaction is NOT completed till yesterday that we released the news after it 
is finished at the first phase. We just finished the UK company investment.

For Qihoo 360, I don't know anything and I don’t have the right to do any 
comment. Sorry.

Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Tuesday, September 20, 2016 10:18 AM
To: Richard Wang <rich...@wosign.com>
Cc: Nick Lamb <tialara...@gmail.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Richard,

As someone pointed out on Twitter this morning, it seems that the PSC 
notification for Startcom UK was filed recently:
https://s3-eu-west-1.amazonaws.com/document-api-images-prod/docs/UdxHYAlFj6U9DNs6VBJdnIDv4IQAWd4YKYomMERO_2o/application-pdf
 Were you unaware of this filing?

Additionally, companies that register to trade on the New York Stock Exchange 
have to file reports with the US Security and Exchange Commission.  Qihoo 360 
filed a report that included a list of their variable interest entities and 
Qihoo's percent of economic interest in each 
(https://www.sec.gov/Archives/edgar/data/1508913/000114420413022823/v341745_20f.htm
page F-10).  It also describes all the ways in which Qihoo 360 controls these 
entities, including assuring that Qihoo has decision making authority over the 
entities.

I agree that Mozilla does not require reporting that multiple Root CAs are 
Affiliates.  Perhaps it should.  However, as you know, the CA/Browser Forum 
does require such.  So I don't think it would be a stretch for Mozilla to do 
so.  It is something that should probably be added to the 2.3 policy discussion.

Thanks,
Peter


On Mon, Sep 19, 2016 at 6:51 PM, Richard Wang <rich...@wosign.com> wrote:
> Thanks for your detail info.
> No worry about this, all companies must be complied with local law.
>
> But I really don't care who is my company's shareholder's shareholder's 
> shareholder, you need to find out this by yourself if you care.
>
> If you think Mozilla must require this, please add to the Mozilla policy that 
> require all CA disclose its nine generation including all subordinate 
> companies and all parent companies.
>
>
> Best Regards,
>
> Richard
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign.com@lists.mozilla.o
> rg] On Behalf Of Nick Lamb
> Sent: Tuesday, September 20, 2016 9:06 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Incidents involving the CA WoSign
>
> On Tuesday, 20 September 2016 01:25:59 UTC+1, Richard Wang  wrote:
>> This case is WoSign problem, you found out all related subordinate companies 
>> and all related parent companies that up to nine generations! I think this 
>> is NOT the best practice in the modern law-respect society.
>
> It seems the governments of the European Union countries (including the UK 
> where one of the mentioned companies is located) disagree with you about 
> whether this is best practice.
>
> Identifying individual human persons behind a company is a key plank of their 
> anti-money laundering and anti-tax evasion policies. To identify these human 
> persons it is necessary to look through any number (even more than nine) of 
> layers of corporate ownership. In the UK the legal term is Persons with 
> Significant Control and PSC registration is mandatory since this summer, a 
> company registered in the UK is obliged to figure out if there are such 
> Persons and if so list them in its routine filings. Failing to properly 
> investigate, or concealing the truth about control of the company is 
> punishable by forfeiture, ie the state would seize the company's assets.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Peter Bowen]

Richard,

As someone pointed out on Twitter this morning, it seems that the PSC
notification for Startcom UK was filed recently:
https://s3-eu-west-1.amazonaws.com/document-api-images-prod/docs/UdxHYAlFj6U9DNs6VBJdnIDv4IQAWd4YKYomMERO_2o/application-pdf
 Were you unaware of this filing?

Additionally, companies that register to trade on the New York Stock
Exchange have to file reports with the US Security and Exchange
Commission.  Qihoo 360 filed a report that included a list of their
variable interest entities and Qihoo's percent of economic interest in
each 
(https://www.sec.gov/Archives/edgar/data/1508913/000114420413022823/v341745_20f.htm
page F-10).  It also describes all the ways in which Qihoo 360
controls these entities, including assuring that Qihoo has decision
making authority over the entities.

I agree that Mozilla does not require reporting that multiple Root CAs
are Affiliates.  Perhaps it should.  However, as you know, the
CA/Browser Forum does require such.  So I don't think it would be a
stretch for Mozilla to do so.  It is something that should probably be
added to the 2.3 policy discussion.

Thanks,
Peter


On Mon, Sep 19, 2016 at 6:51 PM, Richard Wang <rich...@wosign.com> wrote:
> Thanks for your detail info.
> No worry about this, all companies must be complied with local law.
>
> But I really don't care who is my company's shareholder's shareholder's 
> shareholder, you need to find out this by yourself if you care.
>
> If you think Mozilla must require this, please add to the Mozilla policy that 
> require all CA disclose its nine generation including all subordinate 
> companies and all parent companies.
>
>
> Best Regards,
>
> Richard
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
> Behalf Of Nick Lamb
> Sent: Tuesday, September 20, 2016 9:06 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Incidents involving the CA WoSign
>
> On Tuesday, 20 September 2016 01:25:59 UTC+1, Richard Wang  wrote:
>> This case is WoSign problem, you found out all related subordinate companies 
>> and all related parent companies that up to nine generations! I think this 
>> is NOT the best practice in the modern law-respect society.
>
> It seems the governments of the European Union countries (including the UK 
> where one of the mentioned companies is located) disagree with you about 
> whether this is best practice.
>
> Identifying individual human persons behind a company is a key plank of their 
> anti-money laundering and anti-tax evasion policies. To identify these human 
> persons it is necessary to look through any number (even more than nine) of 
> layers of corporate ownership. In the UK the legal term is Persons with 
> Significant Control and PSC registration is mandatory since this summer, a 
> company registered in the UK is obliged to figure out if there are such 
> Persons and if so list them in its routine filings. Failing to properly 
> investigate, or concealing the truth about control of the company is 
> punishable by forfeiture, ie the state would seize the company's assets.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Richard Wang]

Thanks for your detail info.
No worry about this, all companies must be complied with local law.

But I really don't care who is my company's shareholder's shareholder's 
shareholder, you need to find out this by yourself if you care.

If you think Mozilla must require this, please add to the Mozilla policy that 
require all CA disclose its nine generation including all subordinate companies 
and all parent companies.
 

Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Nick Lamb
Sent: Tuesday, September 20, 2016 9:06 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

On Tuesday, 20 September 2016 01:25:59 UTC+1, Richard Wang  wrote:
> This case is WoSign problem, you found out all related subordinate companies 
> and all related parent companies that up to nine generations! I think this is 
> NOT the best practice in the modern law-respect society.

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

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

Re: Incidents involving the CA WoSign

[Nick Lamb]

On Tuesday, 20 September 2016 01:25:59 UTC+1, Richard Wang  wrote:
> This case is WoSign problem, you found out all related subordinate companies 
> and all related parent companies that up to nine generations! I think this is 
> NOT the best practice in the modern law-respect society.

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

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

RE: Incidents involving the CA WoSign

[Erwann Abalea]

Bonsoir Richard,

This info should probably be added to the thread "WoSign's ownership of 
StartCom", and then Peter's complementary questions are legitimate ones, being 
in line with Mozilla's concerns.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Richard Wang]

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

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

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


Regards,

Richard

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

Richard,

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

Thanks,
Peter

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

Re: Incidents involving the CA WoSign

[Peter Bowen]

Richard,

I'm still somewhat confused.  Can you review the following statements
and either confirm they are true or specify they are not true and
correct them?

On 15 December 2015:
1)  סטארט קומארשל בע"מ ("Start Commercial Limited" or StartCom IL) was
a registered company in Israel.
2) 王高华 ("Gaohua Wang" or "Richard Wang") was the sole corporate
director of Startcom IL.
3) Startcom CA Limited (Startcom UK) was a registered company in the
United Kingdom.
4) Richard Wang was the sole corporate director of Startcom UK.
5) Startcom CA Limited (Startcom HK) was a registered company in Hong Kong.
6) Richard Wang was the sole corporate director of Startcom HK.
7)  沃通电子认证服务有限公司 (WoSign) was a registered company in China.
8) Richard Wang was the CEO of WoSign.
9) 100% of shares of Startcom IL were owned by Startcom UK.
10) 100% of shares of Startcom UK were owned by Startcom HK.
11) 100% of the shares of Startcom HK were owned by WoSign.

On 1 September 2016:
1, 2, 3, 5, 6, 7, 8, 9, 10, and 11 were true

12) Richard Wang and Iñigo Barreira were only two corporate directors
of Startcom UK.
13) WoSign had five share holders, in the following percentages:
25.61% Qihoo 360 Software (Beijing) Co., Ltd.
29.77% Beijing Qifutong Technology Co., Ltd.
28.62% Beijing Yuan Tu Technology Co., Ltd.
12.00% Gaohua Wang (an individual)
 4.00% Ganfu Zhang (an individual)
14) Qihoo 360 Technology Co Ltd ("Qihoo 360") was a publicly traded
company on the New York Stock Exchange, listed under the symbol QIHU
15) Qihoo 360 Software (Beijing) Co., Ltd. and Beijing Qifutong
Technology Co., Ltd. were 100% controlled by Qihoo 360.
16) Beijing Yuan Tu Technology Co., Ltd. was 70% controlled by Qihoo 360.

I hope these are reasonably easy to confirm or for you to correct if
they are not true.

Thanks,
Peter

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

RE: Incidents involving the CA WoSign

[Richard Wang]

Hi Gerv,

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


Best Regards,

Richard

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

Hi Gerv,

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

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


Best Regards,

Richard Wang
CEO
WoSign CA Limited


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

Hi Richard,

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

Unfortunately, I think we may be only beginning.

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

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

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

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

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

With best wishes,

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

Re: Incidents involving the CA WoSign

[Florian Weimer]

* Richard Wang:

>> Thus, do you believe it was faithful and accurate for Management to
>> warrant that the CA was operated in compliance with the BRs, given
>> that Management was aware of incidents of non-compliance?
>
> This is my fault that I think it is not serious enough to state in
> the assertion letter, now I know and every related employee know how
> to do this in the future.

Richard,

do you think more precise communication from auditors could have
helped to avoid the incorrect representation?

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

Re: Incidents involving the CA WoSign

[Richard Wang]

Thank you very much for helping us.

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

Regards,

Richard

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

Re: Incidents involving the CA WoSign

[Richard Wang]

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


Regards,

Richard

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


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

Re: Incidents involving the CA WoSign

[Vincent Lynch]

On Friday, September 16, 2016 at 6:07:56 AM UTC-4, Richard Wang wrote:
> Hi Gerv,
> 
> This is the final report: 
> https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf 
> 
> Please let me if you have any questions about the report, thanks.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 

Hi Richard,

Thank you for you and your team's hard work on the report. As an observer, I 
found it very informative.

I do have a follow up question regarding Issue P. I'm curious as to why this 
test ever took place with publicly trusted certificates given that the SM2 
algorithm is not allowed by the CA/B Forum.

Say this test was "successful". Whats next? Since SM2 is not allowed, was 
WoSign planning on introducing a ballot to the CA/B Forum to approve SM2?

Sincerely,

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

Re: Incidents involving the CA WoSign

[Han Yuwei]

在 2016年9月16日星期五 UTC+8下午6:07:56，Richard Wang写道：
> Hi Gerv,
> 
> This is the final report: 
> https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf 
> 
> Please let me if you have any questions about the report, thanks.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -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

About mis-issued alicdn.com and github.com, is the whitelist a acceptable 
solution? I thought it is a serve problem that possible hijacks on CA's 
validation host to the server. Lots of vulnerablity could be used by hackers 
such as DNS poisoning and TCP hijacks. This time the alicdn noticed this 
problem because it is a big company. If this happened to a relatively small 
company can we notice this in time? I am very doubt about that. Anything we can 
do to prevent this from happening?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Richard Wang]

Hi Gerv,

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

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


Best Regards,

Richard Wang
CEO
WoSign CA Limited


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

Hi Richard,

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

Unfortunately, I think we may be only beginning.

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

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

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

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

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

With best wishes,

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

Re: Incidents involving the CA WoSign

[Peter Bowen]

On Sat, Sep 10, 2016 at 6:43 PM, Richard Wang  wrote:
> We will publish a more comprehensive report in the next several days that 
> will attempt to cover most / all issues.
> Thanks for your patience.

Richard,

Thank you in advance for working on a comprehensive report.  I
appreciate it takes signifiant time to research and write it.  Do you
expect to publish this week or will it be some time next week?

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

Re: Incidents involving the CA WoSign

[Richard Wang]

Hi all,

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

Regards,

Richard

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


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

Re: Incidents involving the CA WoSign

[Kyle Hamilton]

I do have to ask this, though:  WoSign has at least one EV issuer.  I do
not know if there is an issuer with EV permissions in NSS, but WoSign
does have an EV code signing issuer in the Microsoft root program.  Has
this issuer been checked to ensure that it could not have misissued
certificates?  (Yes, it's probably out of scope for mozilla's process. 
However, it's still something I'm curious about.)

Also, on #2: Will this audit apply to all WoSign issuers included in
NSS, or just a single one?  I count at least 4.

And finally, where does this leave StartCom?  Is there a need for
inquiries regarding StartCom's operations?

-Kyle H

On 9/7/2016 03:06, 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.
>
> 2. Mozilla can assign a WebTrust auditor to WoSign office to check and 
> inspect every incident, check every relevant issued certificate, and record a 
> report with:  what happened, why this happened and what is being done to 
> prevent this in the future etc., WoSign will pay the audit cost.
>
> I’d like to make some supplements about 1. (4) above, this term means WoSign 
> will only issue SSL certificates to China subscribers. 
> WoSign issued about 120K SSL certificates for websites in China including 
> many central government websites like MIIT and many other local province 
> government websites, many university websites, many online banking websites, 
> 6 of the Top 10 ecommerce websites, big supermarket online store like 
> Walmart, 4 of the Top 5 cloud service in China, and many big companies that 
> listed in NYSE and Nasdaq, and many subsidiaries of foreign countries big 
> companies. 
> Those customers like to use WoSign certificate especially our support of 
> Chinese, local support and customer service. And some of them paid up to 
> 10-year certificate fee in advance, we need to renew their certificate for 
> free once it is about to expire at every three years for OV SSL.
>
> I wish Mozilla could accept my suggestion, and I am sure WoSign will do it 
> better after getting this so big lesson. 
> Thank you.
>
>
> Best Regards,
>
> Richard Wang
> CEO
> WoSign CA Limited
>
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
> Behalf Of Richard Wang
> Sent: Sunday, September 4, 2016 5:49 PM
> To: Gervase Markham <g...@mozilla.org>; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Incidents involving the CA WoSign
>
> Hi all,
>
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
>
> This report has 20 pages, please let me if you still have any questions, 
> thanks.
>
> This report is just for Incident 0-2, we will release a separate report for 
> another incident X soon.
>
>
> Best Regards,
>
> Richard Wang
> CEO
> WoSign CA Limited
>
>
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org] 
> Sent: Wednesday, August 24, 2016 9:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Richard Wang <rich...@wosign.com>
> Subject: Incidents involving the CA WoSign
>
> Dear m.d.s.policy,
>
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these 
> incidents. This email sets out our understanding of the situation.
>
> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> Enforcement Policy[0] says: "When a serious security concern is noticed, such 
> as a major root compromise, it should be treated as a security-sensitive bug, 
> and the Mozilla Policy for Handling Security Bugs should be

Re: Incidents involving the CA WoSign

[Jakob Bohm]

On 07/09/2016 16:01, Thijs Alkemade wrote:

On 07 Sep 2016, at 14:52, Rob Stradling  wrote:


On 06/09/16 19:12, Thijs Alkemade wrote:


Hello,

We obtained 2 certificates from the StartEncrypt API which had SHA-1 signatures 
and which were backdated to December 20, 2015.

After WoSign announced that all certificates issued in 2015 were logged to 
their Certificate Transparency server, I analyzed them to check if any other 
certificates using SHA-1 signatures show signs of being backdated. Using the 
Python tools from Google’s Certificate Transparency repository I downloaded all 
certificates from the log and then queried them from an sqlite database. 
Considering this is the first time I’m working with Certificate Transparency 
logs, it might be better if someone else tries to reproduce my results. I’ve 
generated a table here: 
https://gist.github.com/anonymous/72920ff1b4450d38893dfa1b4863af52 (timestamps 
are in UTC).

I found 1204 certificates with a SHA-1 signature issued after December 1, 2015. 
53 of them included embedded SCT data, so can be dated more accurately.

The most interesting pattern I noticed was from sorting the certificates based 
on the ID they have in WoSign’s Certificate Transparency log. Up to ID 109149 
(https://crt.sh/?q=6d8665951cf6d8743200393a1085e0f6eb226270cc1f1402507d61faae93256a),
 the notBefore values are (approximately) chronologically ordered. Those which 
have embedded SCTs have timestamps which are about 2 hours later than the 
notBefore date.


Hi Thijs.  I agree that this pattern is interesting (and it'd be nice to
see an explanation), but I'm not convinced that it proves everything you
think it proves.


But after that follow 64 certificates which are all dated on December 20, 2015 
(CST, UTC+8), including our two test certificates. Six of these have embedded 
SCT data, but they have a large discrepancy between the notBefore and the 
earliest SCT: 3 have a SCT of December 31 (11 days later) and 1 even has a SCT 
of January 18, 2016, almost a full month after the notBefore. (Unless I 
misunderstand the use of pre-certificates, this by itself already implies the 
certificate was signed using SHA-1 on or after January 18, 2016.)


Yes.  A certificate that has embedded SCTs cannot have been issued any
earlier than any of the timestamps in those embedded SCTs (assuming
those timestamps are accurate, of course).

Of course, "implies...was signed...after" is only demonstrably true when
you have a copy of both the precertificate and the corresponding
certificate.  You can't prove it if you only have a copy of the
precertificate; the signature on a precertificate "indicates the
certificate authority's intent to issue a certificate" [RFC6962 section
3.1], but this doesn't mean the CA is required to issue the certificate.


Hi Rob,

That makes sense, thanks.


Aside from the 3 embedded SCTs on December 31, none of these certificates have 
been logged to a Certificate Transparency server before January 1, 2016.


When a precertificate is logged, there is no need for the corresponding
certificate to be logged.  If the corresponding certificate does get
logged at some point later, so what?
Let's look at one of your examples:
aceeccdbb17b9096251dd11a84041ec75fe7a92e903ffe07c6d6b0a0c980d399
The fact that the certificate (https://crt.sh/?id=12367098) wasn't
logged until late January 2016 is uninteresting, because the
precertificate (https://crt.sh/?id=11751158) was logged on (and has a
notBefore date of) 31st December 2015.

Except for EV, certificates issued by WoSign aren't required (by Chrome)
to be logged.  If a certificate (for which there is no corresponding
precertificate) does get logged at some point long after its issuance
date, so what?
Let's look at one of your examples:
61b6289b1d3786e8f362e4049a4c5e24bb1356c0776fadb3a8a569f99d071a98
I see no evidence to suggest that this certificate was not issued on
30th December 2015, as suggested by its notBefore date.


Both of these are not examples of the certificates which I consider suspicious. 
To be precise, the suspicious certificates have:

- A SHA-1 signature from WoSign.
- A notBefore date on December 20, 2015 (CST).
- An ID in the WoSign Certificate Transparency log ≥ 109153.

In the gist which I posted, this is line 4 up to 65.

The fact that these certificates weren’t logged to public Certificate 
Transparency servers soon after is not suspicious and I did not intend it as 
such. It was only meant to indicate the lack of evidence that could have proven 
their timestamps.

What is suspicious is:

- Twice as many SHA-1 certificates being issued on a specific Sunday in 
December than the daily average that month. (Which also happens to be the date 
on the certificates which I personally got from the StartEncrypt API.)
- The long difference between the notBefore and the embedded SCTs, if any.
- Some of these certificates having an almost identical copy issued using 
SHA-256 on a date in January. 

Re: Incidents involving the CA WoSign

[Richard Wang]

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

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


Regards,

Richard

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

Re: Incidents involving the CA WoSign

[Ming]

在 2016年9月7日星期三 UTC+8下午6:08:33，Richard Wang写道：
> Hi Gerv, Kathleen and Richard,
> 
> This discuss has been lasting two weeks, I think it is time to end it, it 
> doesn’t worth to waste everybody’s precious time.
> I make my confession that our system and management do have some problems 
> which lead to the misissuance of some certificates. And I am very sorry that 
> WoSign don’t notify all browsers after the incident happened and even after 
> the problem fixed.
> 
> I’d like to give my suggestion action for Mozilla as below:
> 1. Mozilla will trust those SSL certificates only:
> (1) The certificate notBefore date is before Jan. 1st 2015;
> (2) The certificate notBefore date is from Jan. 1st 2015 to July 4th 2016 
> that listed in the Google CT log server;
> (3) The certificate notBefore date is from July 5th 2016 to Sept xx 2016 
> that embedded SCT data in the certificate;
> (4) The certificate notBefore date is from Sept xx 2016 that embedded SCT 
> data in the certificate and must have the “C=CN” in the certificate subject.
> 
> 2. Mozilla can assign a WebTrust auditor to WoSign office to check and 
> inspect every incident, check every relevant issued certificate, and record a 
> report with:  what happened, why this happened and what is being done to 
> prevent this in the future etc., WoSign will pay the audit cost.
> 
> I’d like to make some supplements about 1. (4) above, this term means WoSign 
> will only issue SSL certificates to China subscribers. 
> WoSign issued about 120K SSL certificates for websites in China including 
> many central government websites like MIIT and many other local province 
> government websites, many university websites, many online banking websites, 
> 6 of the Top 10 ecommerce websites, big supermarket online store like 
> Walmart, 4 of the Top 5 cloud service in China, and many big companies that 
> listed in NYSE and Nasdaq, and many subsidiaries of foreign countries big 
> companies. 

Richard,I check the  top 10 e-commerce websites in China, ONLY suning.com and 
yhd.com are your subscribers; and ZERO of the top 5 cloud service companies in 
China use WoSign.

I have reason to doubt the authenticity of the data you provided. 

there is the top 10 e-commerce websites in China:
taobao.com
jd.com
tmall.com
amazon.cn
vip.com
meituan.com
suning.com
dangdang.com
jumei.com
yhd.com

the top 5 cloud service companies in China:
aliyun.com
qcloud.com
qingcloud.com
ucloud.cn
hwclouds.com


> Those customers like to use WoSign certificate especially our support of 
> Chinese, local support and customer service. And some of them paid up to 
> 10-year certificate fee in advance, we need to renew their certificate for 
> free once it is about to expire at every three years for OV SSL.
> 
> I wish Mozilla could accept my suggestion, and I am sure WoSign will do it 
> better after getting this so big lesson. 
> Thank you.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
> Behalf Of Richard Wang
> Sent: Sunday, September 4, 2016 5:49 PM
> To: Gervase Markham <g...@mozilla.org>; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Incidents involving the CA WoSign
> 
> Hi all,
> 
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
> 
> This report has 20 pages, please let me if you still have any questions, 
> thanks.
> 
> This report is just for Incident 0-2, we will release a separate report for 
> another incident X soon.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org] 
> Sent: Wednesday, August 24, 2016 9:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Richard Wang <rich...@wosign.com>
> Subject: Incidents involving the CA WoSign
> 
> Dear m.d.s.policy,
> 
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these 
> incidents. This email sets out our understanding of the situation.
> 
> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> Enforcement Policy[0] says: "When a serious security concern is noticed, such 
> as a major root compromise, it should be treated as a security-sensitive bug, 
> and the Mozilla Policy for Handling Security Bugs should be followed." It is 
> clear to us, and appears to be clear to other CAs based on their actions, 
> that misi

Re: Incidents involving the CA WoSign

[Vincent Lynch]

On Wednesday, September 7, 2016 at 7:00:54 AM UTC-4, Gervase Markham wrote:
> Hi Richard,
> 
> On 07/09/16 11:06, Richard Wang wrote:
> > This discuss has been lasting two weeks, I think it is time to end
> > it, it doesn’t worth to waste everybody’s precious time.
> 
> Unfortunately, I think we may be only beginning.
> 
> I have prepared a list of the issues we are tracking with WoSign's
> certificate issuance process and business:
> 
> https://wiki.mozilla.org/CA:WoSign_Issues
> 
> 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

Richard,

When you provide additional details about Issue P, can you specifically comment 
on why two of the certificates were issued for 4 years (48 months)?

Section 6.3.2 of the BRs states "Subscriber Certificates issued after 1 April 
2015 MUST have a Validity Period no greater than 39 months."

That section DID allow for an exception to that 39 month maximum if the CA 
documents that the certificate is being used in a case that satisfies a set of 
5 requirements (too lengthy to provide here). If this was the case, this would 
have been allowable until 30 June 2016 and these certificates' validity period 
would not be a violation. 

Can you comment on if these certificates satisfied the exception? And if so, 
can you provide WoSign's documentation of this?

In my opinion, this is one of the more concerning violations because it may 
show that it is trivially easy for WoSign's issuance software to issue 
certificates that violate the BRs.

(My understanding is that these certificates qualify as a Subscriber 
Certificate, the fact that the subject CN = wosign.net is irrelevant.)

Citation:
https://wiki.mozilla.org/CA:WoSign_Issues#Issue_P:_Use_of_SM2_Algorithm_.28Nov_2015.29
___
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

[Gervase Markham]

On 08/09/16 11:39, Rob Stradling wrote:
> Consider https://crt.sh/?id=30629293, for example.  Are you really
> suggesting that this was issued on 2nd September 2016 but backdated to
> 20th December 2015?

For simplicity, I've removed this section from Issue S. I think the
evidence related there stands alone without any log-number-related
inferences.

Gerv

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

Re: Incidents involving the CA WoSign

[Rob Stradling]

On 07/09/16 17:02, Gervase Markham wrote:
> On 07/09/16 13:52, Rob Stradling wrote:
>> Hi Thijs.  I agree that this pattern is interesting (and it'd be nice to
>> see an explanation), but I'm not convinced that it proves everything you
>> think it proves.
> 
> Hi Rob,
> 
> My digest of Thijs's work (and that of others investigating the same
> issues) is here:
> https://wiki.mozilla.org/CA:WoSign_Issues#Issue_S:_Backdated_SHA-1_Certs_.28January_2016.29
> 
> Is every conclusion I draw justified from the data?

Hi Gerv.  I'd like to discuss this particular conclusion:

  "...up to ID 109149...But after that follow 64 certificates which are
   all dated on December 20, 2015 (CST, UTC+8). This suggests that
   these were logged at the actual time of issuance but that time is
   not reflected in their notBefore date - i.e. they were backdated."

ID 109153 (https://crt.sh/?id=30629275) is the first such certificate,
not 109150.  Also, these 64 certificates were not logged consecutively.
I've just posted details of the relevant range of log entries here:
https://gist.github.com/robstradling/129729531779dab448ca88049c49307c

These log entries were only created 5 or 6 days ago, and the majority
don't have corresponding precertificates.
Consider https://crt.sh/?id=30629293, for example.  Are you really
suggesting that this was issued on 2nd September 2016 but backdated to
20th December 2015?

The entry timestamps up to ID 109221 are all very close together
(several entries per second).  We know that WoSign were at that time
submitting all of the certs they issued in 2015, so this is not surprising.

I think it's unreasonable to assume that WoSign attempted to log the
certs they issued in 2015 in the order in which they were issued.

I look forward to reading WoSign's response to Issue S.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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 <g...@mozilla.org>; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Incidents involving the CA WoSign
> 
> Hi all,
> 
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
> 
> This report has 20 pages, please let me if you still have any questions, 
> thanks.
> 
> This report is just for Incident 0-2, we will release a separate report for 
> another incident X soon.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org] 
> Sent: Wednesday, August 24, 2016 9:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Richard Wang <rich...@wosign.com>
> Subject: Incidents involving the CA WoSign
> 
> Dear m.d.s.policy,
> 
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these 
> incidents. This email sets out our understanding of the situation.
> 
> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> Enforcement Policy[0] says: "When a serious security concern is noticed, such 
> as a major root compromise, it should be treated as a security-sensitive bug, 
> and the Mozilla Policy for Handling Security Bugs should be followed." It is 
> clear to us, and appears to be clear to other CAs based on their actions, 
> that misissuances where domain control checks have failed fall into the 
> category of "serious security concern".
> 
> Incident 0
> --
> 
> On or around April 23rd, 2015, WoSign's certificate issuance system for their

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

On Wed, Sep 07, 2016 at 02:08:24PM +0200, Kurt Roeckx wrote:
> On 2016-09-07 13:00, Gervase Markham wrote:
> > Hi Richard,
> > 
> > On 07/09/16 11:06, Richard Wang wrote:
> > > This discuss has been lasting two weeks, I think it is time to end
> > > it, it doesn’t worth to waste everybody’s precious time.
> > 
> > Unfortunately, I think we may be only beginning.
> > 
> > I have prepared a list of the issues we are tracking with WoSign's
> > certificate issuance process and business:
> > 
> > https://wiki.mozilla.org/CA:WoSign_Issues
> 
> Thanks for putting this all in a page because I already lost track of most
> of the issues.
> 
> This URL was posted, and at least seems to match the date range:
> https://crt.sh/?serial=056d1570da645bf6b44c0a7077cc6769=1662

So here are 27 others:
https://crt.sh/?serial=0d3bbdc3a0175e38f9d0070cd050986a=1672

There is this weird combination:
https://crt.sh/?id=12729072
https://crt.sh/?id=12728869

We also have:
https://crt.sh/?id=9318242
https://crt.sh/?id=7841622


Kurt

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

Re: Incidents involving the CA WoSign

[Jozef Izso]

Richard, why the report does not mention that the list of certs issued using 
high port validation is not complete and that you cannot properly find all the 
relevant information in your system?

> On 7. 9. 2016, at 4:08, Richard Wang <rich...@wosign.com> wrote:
> 
> We checked our system that this order is finished the website control 
> validation correctly. No any mistake.
> 
> Why this is not listed in the report list? This order is year 2015 order, 
> this is the event of 17 months ago, we can't find the info what port is used, 
> our CMS system just record this order is validated by website control 
> validation method, not record the used port at that time.
> 
> Why we can find out other 72 certificate? We try to search every validation 
> process evidence in many systems to analyze the related log to catch the 
> info. I can't guarantee all high port validation order are listed in the 
> report, but as we said in the report, each certificate is properly validated 
> using high port.
> 
> 
> Best Regards,
> 
> Richard
> 
> -Original Message-
> From: Julian Brost [mailto:jul...@0x4a42.net] 
> Sent: Wednesday, September 7, 2016 12:06 AM
> To: Richard Wang <rich...@wosign.com>; Gervase Markham <g...@mozilla.org>; 
> dev-security-policy@lists.mozilla.org
> Subject: Re: Incidents involving the CA WoSign
> 
> Hi,
> 
> section 1.4. Impact Analytics in the report contains a list of 72 
> certificates, for which the domain validation was done on a high port.
> 
> On 2015-04-20 I have obtained a certificate for a domain name that I 
> validated using port 8080 but that certificate is not listed in the report. 
> This is the certificate: https://crt.sh/?id=30335331
> 
> It seems like the certificate was posted to the CT logs by WoSign (at least I 
> never used the certificate anywhere) but not on August 26th like the other 
> certs and as stated in the report.
> 
> So I have doubts about the report and it really should be investigated why 
> this certificate is missing in the report.
> 
> Regards,
> Julian Brost
> 
>> On 04.09.2016 11:49, 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:ge...@mozilla.org]
>> Sent: Wednesday, August 24, 2016 9:08 PM
>> To: mozilla-dev-s...@lists.mozilla.org
>> Cc: Richard Wang <ric...@wosign.com>
>> Subject: Incidents involving the CA WoSign
>> 
>> Dear m.d.s.policy,
>> 
>> Several incidents have come to our attention involving the CA "WoSign".
>> Mozilla is considering what action it should take in response to these 
>> incidents. This email sets out our understanding of the situation.
>> 
>> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
>> Enforcement Policy[0] says: "When a serious security concern is noticed, 
>> such as a major root compromise, it should be treated as a 
>> security-sensitive bug, and the Mozilla Policy for Handling Security Bugs 
>> should be followed." It is clear to us, and appears to be clear to other CAs 
>> based on their actions, that misissuances where domain control checks have 
>> failed fall into the category of "serious security concern".
>> 
>> Incident 0
>> --
>> 
>> On or around April 23rd, 2015, WoSign's certificate issuance system for 
>> their free certificates allowed the applicant to choose any port for 
>> validation. Once validation had been completed, WoSign would issue 
>> certificates for that domain. A researcher was able to obtain a certificate 
>> for a university by opening a high-numbered port (>50,000) and getting 
>> WoSign to use that port for validation of control.
>> 
>> This problem was reported to Google, and thence to WoSign and resolved.
>> Mozilla only became aware of it recently.
>> 
>> * Before the recent passage of Ballot 169 in the CAB Forum, which limits the 
>> ports and paths which can be used, the Baseline Requirements said that one 
>> acceptable method of domain validation was "Having the Applicant demonstrate 
>> practical control over the FQD

Re: Incidents involving the CA WoSign

[dymutaos]

On Tuesday, September 6, 2016 at 10:10:44 PM UTC-4, Richard Wang wrote:
> ... we can't find the info what port is used, our CMS system just record this 
> order is validated by website control validation method, not record the used 
> port at that time.
> 
> Why we can find out other 72 certificate? We try to search every validation 
> process evidence in many systems to analyze the related log to catch the 
> info. I can't guarantee all high port validation order are listed in the 
> report, but as we said in the report, each certificate is properly validated 
> using high port.
> 
> 
> Best Regards,
> 
> Richard
> 

My trust in this CA has dropped even more. Even if all non-standard port 
validations were otherwise issued correctly, it does not bode well that 
WoSign's system failed to record enough information in its logs. If people are 
manually looking through logs for suspicious certificates, we can never be sure 
that they caught them all, and there may be false positives as well.

If the logs didn't store even the simple port information, what else isn't it 
storing? You say you'll do better in the future, but you have to be able to 
account for current and future bugs. In order to do that, you need accurate and 
verbose logs, or else a future vulnerability may be unable to be contained.
___
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

[Gervase Markham]

On 07/09/16 13:52, Rob Stradling wrote:
> Hi Thijs.  I agree that this pattern is interesting (and it'd be nice to
> see an explanation), but I'm not convinced that it proves everything you
> think it proves.

Hi Rob,

My digest of Thijs's work (and that of others investigating the same
issues) is here:
https://wiki.mozilla.org/CA:WoSign_Issues#Issue_S:_Backdated_SHA-1_Certs_.28January_2016.29

Is every conclusion I draw justified from the data?

Gerv

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

Re: Incidents involving the CA WoSign

[Rob Stradling]

On 07/09/16 15:01, Thijs Alkemade wrote:

> What is suspicious is:
> 
> - Twice as many SHA-1 certificates being issued on a specific Sunday in 
> December than the daily average that month. (Which also happens to be the 
> date on the certificates which I personally got from the StartEncrypt API.)

There could be an entirely innocent explanation for this.  Lots of
people were stockpiling SHA-1 certs during December 2015.  Daily
certificate issuance rates do vary.

> - The long difference between the notBefore and the embedded SCTs, if any.
> - Some of these certificates having an almost identical copy issued using 
> SHA-256 on a date in January. If the SHA-1 cert has embedded SCTs, then the 
> SHA-256 cert has them too and the SCTs of both certs are less than a minute 
> apart.
> 
> Of course, I can’t present hard cryptographic evidence that these 
> certificates did not exist then, but I fear nothing can.

Indeed.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed.  If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
___
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

[Rob Stradling]

On 06/09/16 19:12, Thijs Alkemade wrote:

> Hello,
> 
> We obtained 2 certificates from the StartEncrypt API which had SHA-1 
> signatures and which were backdated to December 20, 2015.
> 
> After WoSign announced that all certificates issued in 2015 were logged to 
> their Certificate Transparency server, I analyzed them to check if any other 
> certificates using SHA-1 signatures show signs of being backdated. Using the 
> Python tools from Google’s Certificate Transparency repository I downloaded 
> all certificates from the log and then queried them from an sqlite database. 
> Considering this is the first time I’m working with Certificate Transparency 
> logs, it might be better if someone else tries to reproduce my results. I’ve 
> generated a table here: 
> https://gist.github.com/anonymous/72920ff1b4450d38893dfa1b4863af52 
> (timestamps are in UTC).
> 
> I found 1204 certificates with a SHA-1 signature issued after December 1, 
> 2015. 53 of them included embedded SCT data, so can be dated more accurately.
> 
> The most interesting pattern I noticed was from sorting the certificates 
> based on the ID they have in WoSign’s Certificate Transparency log. Up to ID 
> 109149 
> (https://crt.sh/?q=6d8665951cf6d8743200393a1085e0f6eb226270cc1f1402507d61faae93256a),
>  the notBefore values are (approximately) chronologically ordered. Those 
> which have embedded SCTs have timestamps which are about 2 hours later than 
> the notBefore date.

Hi Thijs.  I agree that this pattern is interesting (and it'd be nice to
see an explanation), but I'm not convinced that it proves everything you
think it proves.

> But after that follow 64 certificates which are all dated on December 20, 
> 2015 (CST, UTC+8), including our two test certificates. Six of these have 
> embedded SCT data, but they have a large discrepancy between the notBefore 
> and the earliest SCT: 3 have a SCT of December 31 (11 days later) and 1 even 
> has a SCT of January 18, 2016, almost a full month after the notBefore. 
> (Unless I misunderstand the use of pre-certificates, this by itself already 
> implies the certificate was signed using SHA-1 on or after January 18, 2016.)

Yes.  A certificate that has embedded SCTs cannot have been issued any
earlier than any of the timestamps in those embedded SCTs (assuming
those timestamps are accurate, of course).

Of course, "implies...was signed...after" is only demonstrably true when
you have a copy of both the precertificate and the corresponding
certificate.  You can't prove it if you only have a copy of the
precertificate; the signature on a precertificate "indicates the
certificate authority's intent to issue a certificate" [RFC6962 section
3.1], but this doesn't mean the CA is required to issue the certificate.

> Aside from the 3 embedded SCTs on December 31, none of these certificates 
> have been logged to a Certificate Transparency server before January 1, 2016.

When a precertificate is logged, there is no need for the corresponding
certificate to be logged.  If the corresponding certificate does get
logged at some point later, so what?
Let's look at one of your examples:
aceeccdbb17b9096251dd11a84041ec75fe7a92e903ffe07c6d6b0a0c980d399
The fact that the certificate (https://crt.sh/?id=12367098) wasn't
logged until late January 2016 is uninteresting, because the
precertificate (https://crt.sh/?id=11751158) was logged on (and has a
notBefore date of) 31st December 2015.

Except for EV, certificates issued by WoSign aren't required (by Chrome)
to be logged.  If a certificate (for which there is no corresponding
precertificate) does get logged at some point long after its issuance
date, so what?
Let's look at one of your examples:
61b6289b1d3786e8f362e4049a4c5e24bb1356c0776fadb3a8a569f99d071a98
I see no evidence to suggest that this certificate was not issued on
30th December 2015, as suggested by its notBefore date.



-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: Incidents involving the CA WoSign

[Richard Wang]

We posted all 2015 certificates, total 109,405

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

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


Regards,

Richard

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


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

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

On 2016-09-07 13:00, Gervase Markham wrote:

Hi Richard,

On 07/09/16 11:06, Richard Wang wrote:

This discuss has been lasting two weeks, I think it is time to end
it, it doesn’t worth to waste everybody’s precious time.


Unfortunately, I think we may be only beginning.

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

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


Thanks for putting this all in a page because I already lost track of 
most of the issues.


This URL was posted, and at least seems to match the date range:
https://crt.sh/?serial=056d1570da645bf6b44c0a7077cc6769=1662

It currently only has 314 of the mentioned 392 duplicates.  I don't know 
if there are other duplicate serials we need to look for, or if they 
failed to publish all 392.  It's at least my understanding that all 
certificates for 2015 should already have been submitted to CT.


Related to issue F, we've been told that all 2015 certificates should 
have been published to CT.  We got a mail saying that with "Date: Fri, 2 
Sep 2016 07:37:52 +".  I added the https://crt.sh/?id=30736090 to 
aviator later, and it's now in their log too.


I guess it could be useful for everybody to go over this page and see if 
all the issues that were raised are on that page.



Kurt

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

Re: Incidents involving the CA WoSign

[Richard Wang]

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

Regards,

Richard

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


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

Re: Incidents involving the CA WoSign

[Gervase Markham]

Hi Richard,

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

Unfortunately, I think we may be only beginning.

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

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

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

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

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

With best wishes,

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

RE: Incidents involving the CA WoSign

[Richard Wang]

Hi Gerv, Kathleen and Richard,

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

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

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

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

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


Best Regards,

Richard Wang
CEO
WoSign CA Limited


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

Hi all,

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

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

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


Best Regards,

Richard Wang
CEO
WoSign CA Limited


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

Dear m.d.s.policy,

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

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

Incident 0
--

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

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

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

Re: Incidents involving the CA WoSign

[Rob Stradling]

On 06/09/16 11:11, Rob Stradling wrote:

> "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!)

These cross-certs (https://crt.sh/?q=UTN+-+DATACorp+SGC=1) are now
in OneCRL.  Thanks Gerv.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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

[Jakob Bohm]

On 06/09/2016 19:49, Jonathan Rudenberg wrote:



On Sep 5, 2016, at 16:25, hanyuwe...@gmail.com wrote:

I thought Wosign's report is not very convincible. The bug of subdomain have 
existed for a long time and it made me feel it is a feature not a bug. It's not 
a secret among the admin of personal or small sites. I am not very similar to 
CA stuff that time,just a subscriber of Wosign's free certificates.I have also 
signed subdomain certificate without validating root domain control. But I 
controlled both of them so I didn't think it is very serve problem.

So I think it is very important to audit how many certificates mis-issued by 
Wosign. Because this bug is used widely when I am running websites for Wosign 
provide FREE 3 year multi-domain certificates that time. ( We dont have Let's 
encrypt that time and Startcom just issue single domain.)


Do you believe that you have certificates issued by WoSign that include 
unvalidated domains that are not on the list in Figure 14 of the report[0]?

To clarify: validating a subdomain and issuing a certificate for it is fine, 
however it is incorrect to issue a certificate for a domain below the level 
that was validated. For example, if control of subdomain.example.com is the 
only thing validated, it would be incorrect to issue a certificate that 
included example.com or any other domains that did not end in 
.subdomain.example.com.

[0] https://www.wosign.com/report/wosign_incidents_report_09042016.pdf



Because of what hanyuwei70 wrote, I think it would be prudent to treat
two cases different *for this case only*:

1. The validated domain was www.foo.bar and the certificate was for
www.foo.bar and foo.bar.  This case should be treated more leniently.

2. The validated domain was baz.foo.bar and the certificate was for
baz.foo.bar and foo.bar.  In this case there is no reason to believe
that the certificate customer has any right to get a certificate for
foo.bar and the certificates must be revoked instantly with no delay.

If a customer paid money for a baz.foo.bar certificate and can now
prove that they do in fact control foo.bar in addition to baz.foo.bar,
the certificate should be reissued at no extra cost, since only the
WoSign validation work was wrong, not the result.

If a customer paid money for a baz.foo.bar certificate and did not
request or use the included foo.bar certification, that customer should
be offered a baz.foo.bar-only certificate at no extra charge, provided
they can still prove control of baz.foo.bar.

If a customer actually asked for a combined baz.foo.bar + foo.bar
certificate or used the foo.bar portion of such a certificate despite
having no rights to the foo.bar domain itself, then that customer
should not be able to get a new certificate at all, since they
deliberately acted fraudulently and took advantage of WoSign's
incompetence.  This includes the security researcher(s) who requested
such certificates only to prove that WoSign's systems don't work.



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

[Thijs Alkemade]

On 01 Sep 2016, at 18:00, Ryan Sleevi  wrote:
> 
> Incident 2: July, 2016 - At least 1 backdated SHA-1 certificate (was this
> the only one? I wasn't clear from
> https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ
>  
> 
> )

Hello,

We obtained 2 certificates from the StartEncrypt API which had SHA-1 signatures 
and which were backdated to December 20, 2015.

After WoSign announced that all certificates issued in 2015 were logged to 
their Certificate Transparency server, I analyzed them to check if any other 
certificates using SHA-1 signatures show signs of being backdated. Using the 
Python tools from Google’s Certificate Transparency repository I downloaded all 
certificates from the log and then queried them from an sqlite database. 
Considering this is the first time I’m working with Certificate Transparency 
logs, it might be better if someone else tries to reproduce my results. I’ve 
generated a table here: 
https://gist.github.com/anonymous/72920ff1b4450d38893dfa1b4863af52 (timestamps 
are in UTC).

I found 1204 certificates with a SHA-1 signature issued after December 1, 2015. 
53 of them included embedded SCT data, so can be dated more accurately.

The most interesting pattern I noticed was from sorting the certificates based 
on the ID they have in WoSign’s Certificate Transparency log. Up to ID 109149 
(https://crt.sh/?q=6d8665951cf6d8743200393a1085e0f6eb226270cc1f1402507d61faae93256a),
 the notBefore values are (approximately) chronologically ordered. Those which 
have embedded SCTs have timestamps which are about 2 hours later than the 
notBefore date.

But after that follow 64 certificates which are all dated on December 20, 2015 
(CST, UTC+8), including our two test certificates. Six of these have embedded 
SCT data, but they have a large discrepancy between the notBefore and the 
earliest SCT: 3 have a SCT of December 31 (11 days later) and 1 even has a SCT 
of January 18, 2016, almost a full month after the notBefore. (Unless I 
misunderstand the use of pre-certificates, this by itself already implies the 
certificate was signed using SHA-1 on or after January 18, 2016.) Aside from 
the 3 embedded SCTs on December 31, none of these certificates have been logged 
to a Certificate Transparency server before January 1, 2016.

Then I checked crt.sh to look for the SANs used for these certificates, and 
found even more signs. For the domain “mail.gd.gov.cn”, two certificates have 
been logged recently:

https://crt.sh/?id=12356371 SHA-1 signature and notBefore December 20, 2015.
https://crt.sh/?id=12362293 SHA-256 signature and notBefore January 26, 2016.

Both were first logged to Certificate Transparency by Google on January 28, 
2016.

For “ebank.pcnkbank.com”, similar:

https://crt.sh/?id=30773634 SHA-1 signature and notBefore December 20, 2015.
https://crt.sh/?id=15425430 SHA-256 signature and notBefore January 28, 2016.

For “congfubao.com”:

https://crt.sh/?id=30773528 SHA-1 signature, notBefore December 20, 2015 and 3 
embedded SCTs for January 5, 2016.
https://crt.sh/?id=11900532 SHA-256 signature, notBefore January 5, 2016 and 3 
embedded SCTs for January 5, 2016. These SCTs were issued approximately 17 
seconds later than those on the other cert.

And many other examples exist within these 62 certs for which a SHA-256 
certificate was issued in January/February and a SHA-1 certificate was “issued” 
on December 20, but not logged to Certificate Transparency (until last week) or 
just after the SHA-256 certificate was issued.

All of this together strongly suggests WoSign was generating SHA-1 and SHA-256 
certificates at the same time (not uncommon in 2015 to maximise compatibility, 
I think), but continued doing this on December 31, 2015 for at least a month by 
intentionally backdating the SHA-1 certificate.



Best regards,
Thijs Alkemade

Computest • Pine Digital Security
E: talkem...@computest.nl • I: www.computest.nl  
A: Signaalrood 25 • 2718 SH Zoetermeer

Pine Digital Security is part of Computest



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

Re: Incidents involving the CA WoSign

[Gervase Markham]

On 05/09/16 23:58, Peter Bowen wrote:
> 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".

After consultation, Mozilla's CA team agrees with your views.

Gerv


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

Re: Incidents involving the CA WoSign

[Jonathan Rudenberg]

> On Sep 5, 2016, at 16:25, hanyuwe...@gmail.com wrote:
> 
> I thought Wosign's report is not very convincible. The bug of subdomain have 
> existed for a long time and it made me feel it is a feature not a bug. It's 
> not a secret among the admin of personal or small sites. I am not very 
> similar to CA stuff that time,just a subscriber of Wosign's free 
> certificates.I have also signed subdomain certificate without validating root 
> domain control. But I controlled both of them so I didn't think it is very 
> serve problem.
> 
> So I think it is very important to audit how many certificates mis-issued by 
> Wosign. Because this bug is used widely when I am running websites for Wosign 
> provide FREE 3 year multi-domain certificates that time. ( We dont have Let's 
> encrypt that time and Startcom just issue single domain.)

Do you believe that you have certificates issued by WoSign that include 
unvalidated domains that are not on the list in Figure 14 of the report[0]?

To clarify: validating a subdomain and issuing a certificate for it is fine, 
however it is incorrect to issue a certificate for a domain below the level 
that was validated. For example, if control of subdomain.example.com is the 
only thing validated, it would be incorrect to issue a certificate that 
included example.com or any other domains that did not end in 
.subdomain.example.com.

[0] https://www.wosign.com/report/wosign_incidents_report_09042016.pdf
___
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

[xcrailfans]

On Saturday, September 3, 2016 at 1:31:17 PM UTC-4, Andy Ligg 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.

Thanks for pointing me to MR. GUOHUA WANG's name[1], and beware of your NDA 
too. Meh.

[1]: 
http://wayback.archive.org/web/20160903185601/https://companycheck.co.uk/company/09744347/STARTCOM-CA-LIMITED/companies-house-data#
___
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

[Will Hughes]

Hello,

First of all let me state that I am in no way involved in the operation of
a certificate authority, nor am I involved in setting CA policy for any
organisation; I am merely an interested observer. I am a user of Mozillas'
trust store, both directly through Firefox and Thunderbird, and indirectly
by using pieces of software that rely on NSS. I have previously been a
customer of WoSign[0], but am not currently.

Addressing Mozillas' response to WoSigns' breach:

* Surely there is precedent from previous violations by other CAs that can be
  used to inform this decision? How did Mozilla handle the October 2015
  incident[1] in which Symantec mis-issued over 2500 certificates? While the
  scale appears to be different, the facts of that incident are not too
  dissimilar to this one; a CA mis-issued a number of certificates, and
  failed to adequately notify trust store operators of this.

* While there doesn't seem to be a great deal of dispute over the facts of
  this incident, it seems to me that in the very short term (ie, the next
  fortnight) it would be useful if WoSign were required to produce an incident
  report detailing:
- The precise extent of the incident, detailing every certificate that was
  mis-issued and to whom, to reassure the community that these bugs are not
  being used maliciously
- The current status (revocation, CT presence) of all mis-issued
  certificates.
- An assessment as to the cause of the incident[2]
- Details as to the measures already undertaken to rectify the defects
- Details of future measures that will be undertaken to prevent further
  problems
  The purpose of this is to re-establish some small amount of trust that WoSign
  can be permitted to continue operating while a longer-term plan is discussed

* I do not know what should be done in the longer term, but I suggest that the
  focus of this discussion be on finding ways to permit WoSign to prove that
  they are fit to participate in the Root Trust programme, so long as WoSign
  are willing to engage and proactively work to restore trust. If WoSign do
  not wish to work to restore trust, then removal from the programme would
  have to be considered. Care must be taken to not unduly punish WoSigns'
  customers, while at the same to the safety of the wider internet community
  must be assured.

Addressing this issue in general; WoSign have claimed that their failure to
report this incident came about from a misunderstanding of the English
language documents by their staff who do not all speak English. While this
is clearly not a valid excuse, is this something Mozilla needs to consider
to prevent similar incidents in the future? Surely a significant
proportion of CA operators face a similar language barrier?

Thank you all for your time,
Will Hughes

[0] I issued two certificate via WoSign in May 2016 for hosts that were
not internet facing, because it was impractical for me to issue LetsEncrypt
certs for those hosts. I have since updated my tooling, issued LetsEncrypt
certs and revoked the WoSign certs. I note that neither of the WoSign certs
appear on crt.sh

[1] 
https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html

[2] I understand that in the short timeframe, a full post-mortem may not
be practical, but an initial assesment of the causes of the incident
should have already been completed

On Thursday, 25 August 2016 01:09:02 UTC+12, Gervase Markham  wrote:
> 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 

Re: Incidents involving the CA WoSign

[moonbingbing]

For page 19 of the report, I have one question: If the subscriber MUST transfer 
the payment from his company bank account, why subscriber fake the company seal 
as figure 20?
And from figure 21's information, one fraud company transfered the payment from 
alipay, NOT his company bank!

在 2016年9月4日星期日 UTC+8下午5:51:26，Richard Wang写道：
> Hi all,
> 
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
> 
> This report has 20 pages, please let me if you still have any questions, 
> thanks.
> 
> This report is just for Incident 0-2, we will release a separate report for 
> another incident X soon.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org] 
> Sent: Wednesday, August 24, 2016 9:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Richard Wang <rich...@wosign.com>
> Subject: Incidents involving the CA WoSign
> 
> Dear m.d.s.policy,
> 
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these 
> incidents. This email sets out our understanding of the situation.
> 
> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> Enforcement Policy[0] says: "When a serious security concern is noticed, such 
> as a major root compromise, it should be treated as a security-sensitive bug, 
> and the Mozilla Policy for Handling Security Bugs should be followed." It is 
> clear to us, and appears to be clear to other CAs based on their actions, 
> that misissuances where domain control checks have failed fall into the 
> category of "serious security concern".
> 
> Incident 0
> --
> 
> On or around April 23rd, 2015, WoSign's certificate issuance system for their 
> free certificates allowed the applicant to choose any port for validation. 
> Once validation had been completed, WoSign would issue certificates for that 
> domain. A researcher was able to obtain a certificate for a university by 
> opening a high-numbered port (>50,000) and getting WoSign to use that port 
> for validation of control.
> 
> This problem was reported to Google, and thence to WoSign and resolved.
> Mozilla only became aware of it recently.
> 
> * Before the recent passage of Ballot 169 in the CAB Forum, which limits the 
> ports and paths which can be used, the Baseline Requirements said that one 
> acceptable method of domain validation was "Having the Applicant demonstrate 
> practical control over the FQDN by making an agreed‐upon change to 
> information found on an online Web page identified by a uniform resource 
> identifier containing the FQDN". This method therefore did not violate the 
> letter of the BRs. However, Mozilla considers the basic security knowledge 
> that ports over 1024 are unprivileged should have led all CAs not to accept 
> validations of domain control on such ports, even when not documented in the 
> BRs.
> 
> * The misissuance incident was not reported to Mozilla by WoSign as it should 
> have been (see above).
> 
> * This misissuance incident did not turn up on WoSign's subsequent BR 
> audit[1].
> 
> Incident 1
> --
> 
> In June 2015, an applicant found a problem with WoSign's free certificate 
> service, which allowed them to get a certificate for the base domain if they 
> were able to prove control of a subdomain.
> 
> The reporter proved the problem in two ways. They accidentally discovered it 
> when trying to get a certificate for med.ucf.edu and mistakenly also applied 
> for www.ucf.edu, which was approved. They then confirmed the problem by using 
> their control of theiraccount.github.com/theiraccount.github.io to get a cert 
> for github.com, github.io, and www.github.io.
> 
> They reported this to WoSign, giving only the Github certificate as an 
> example. That cert was revoked and the vulnerability was fixed. However 
> recently, they got in touch with Google to note that the ucf.edu cert still 
> had not been revoked almost a year later.
> 
> * The lack of revocation of the ucf.edu certificate (still unrevoked at time 
> of writing, although it may have been by time of posting) strongly suggests 
> that WoSign either did not or could not search their issuance databases for 
> other occurrences of the same problem. Mozilla considers such a search a 
> basic part of the response to disclosure of a vulnerability which causes 
> misissuance, and expects CAs to keep records detailed enough to make it 
> possible.
> 
> * This misissuance incide

Re: Incidents involving the CA WoSign

[Julian Brost]

Hi,

section 1.4. Impact Analytics in the report contains a list of 72
certificates, for which the domain validation was done on a high port.

On 2015-04-20 I have obtained a certificate for a domain name that I
validated using port 8080 but that certificate is not listed in the
report. This is the certificate: https://crt.sh/?id=30335331

It seems like the certificate was posted to the CT logs by WoSign (at
least I never used the certificate anywhere) but not on August 26th like
the other certs and as stated in the report.

So I have doubts about the report and it really should be investigated
why this certificate is missing in the report.

Regards,
Julian Brost

On 04.09.2016 11:49, 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:ge...@mozilla.org] 
> Sent: Wednesday, August 24, 2016 9:08 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Cc: Richard Wang <ric...@wosign.com>
> Subject: Incidents involving the CA WoSign
> 
> Dear m.d.s.policy,
> 
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these 
> incidents. This email sets out our understanding of the situation.
> 
> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> Enforcement Policy[0] says: "When a serious security concern is noticed, such 
> as a major root compromise, it should be treated as a security-sensitive bug, 
> and the Mozilla Policy for Handling Security Bugs should be followed." It is 
> clear to us, and appears to be clear to other CAs based on their actions, 
> that misissuances where domain control checks have failed fall into the 
> category of "serious security concern".
> 
> Incident 0
> --
> 
> On or around April 23rd, 2015, WoSign's certificate issuance system for their 
> free certificates allowed the applicant to choose any port for validation. 
> Once validation had been completed, WoSign would issue certificates for that 
> domain. A researcher was able to obtain a certificate for a university by 
> opening a high-numbered port (>50,000) and getting WoSign to use that port 
> for validation of control.
> 
> This problem was reported to Google, and thence to WoSign and resolved.
> Mozilla only became aware of it recently.
> 
> * Before the recent passage of Ballot 169 in the CAB Forum, which limits the 
> ports and paths which can be used, the Baseline Requirements said that one 
> acceptable method of domain validation was "Having the Applicant demonstrate 
> practical control over the FQDN by making an agreed‐upon change to 
> information found on an online Web page identified by a uniform resource 
> identifier containing the FQDN". This method therefore did not violate the 
> letter of the BRs. However, Mozilla considers the basic security knowledge 
> that ports over 1024 are unprivileged should have led all CAs not to accept 
> validations of domain control on such ports, even when not documented in the 
> BRs.
> 
> * The misissuance incident was not reported to Mozilla by WoSign as it should 
> have been (see above).
> 
> * This misissuance incident did not turn up on WoSign's subsequent BR 
> audit[1].
> 
> Incident 1
> --
> 
> In June 2015, an applicant found a problem with WoSign's free certificate 
> service, which allowed them to get a certificate for the base domain if they 
> were able to prove control of a subdomain.
> 
> The reporter proved the problem in two ways. They accidentally discovered it 
> when trying to get a certificate for med.ucf.edu and mistakenly also applied 
> for www.ucf.edu, which was approved. They then confirmed the problem by using 
> their control of theiraccount.github.com/theiraccount.github.io to get a cert 
> for github.com, github.io, and www.github.io.
> 
> They reported this to WoSign, giving only the Github certificate as an 
> example. That cert was revoked and the vulnerability was fixed. However 
> recently, they got in touch with Google to note that the ucf.edu cert still 
> had not been revoked almost a year later.
> 
> * The lack of revocation of the ucf.edu certificate (still unrevoked at time 
> of writing, although it may have been by time of posting) strongly suggest

Re: Incidents involving the CA WoSign

[hanyuwei70]

I thought Wosign's report is not very convincible. The bug of subdomain have 
existed for a long time and it made me feel it is a feature not a bug. It's not 
a secret among the admin of personal or small sites. I am not very similar to 
CA stuff that time,just a subscriber of Wosign's free certificates.I have also 
signed subdomain certificate without validating root domain control. But I 
controlled both of them so I didn't think it is very serve problem.

So I think it is very important to audit how many certificates mis-issued by 
Wosign. Because this bug is used widely when I am running websites for Wosign 
provide FREE 3 year multi-domain certificates that time. ( We dont have Let's 
encrypt that time and Startcom just issue single domain.)
___
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

[Eddy Nigg]

On 09/05/2016 10:54 AM, Gervase Markham wrote:

Hi Eddy,

On 04/09/16 09:51, Eddy Nigg wrote:

I don't want to extend this discussion unnecessarily, but as a side note
you don't know which agreements this employee has signed with StartCom
and/or WoSign and hence you can't make a judgement on it either. Lets
leave this to the professionals dealing with it.

If he has signed an agreement with StartCom and/or WoSign which prevents
him from pointing out, after leaving employment, facts which are in the
public domain, then I suggest that those clauses in the agreement are an
unconscionable[0] restriction on his freedoms and you should not be
enforcing them.


Again, I don't think we can and will solve this in public, however I 
believe it's the complete right of a company (and employer) to decide 
how and when it wants to make an official public announcement about its 
business (and being just in order to complete a currently ongoing 
transaction first).


Not every employee is authorized to represent the company and inform 
third parties (at his/her convenient timing and consideration) even if 
he/she knows about it and/or some information has been placed into 
(partly) public domain as part of a business process.


I hope my explanation makes it clear that this ex-employee was not 
authorized to provide any information about StartCom or WoSign.


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. 
XMPP:   start...@startcom.org 

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

Percy Alpha(PGP
)


On Tue, Sep 6, 2016 at 8:19 AM, Peter Gutmann 
wrote:

> Nick Lamb  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
> Network, WebSpace-Forum e.K., and Wotone Communications.  Getting a whole
> pile
> of other cross-certifications from additional CAs seems a bit redundant,
> and
> has the flipside that once you've got a sufficiently complex mesh of cross-
> certifications you've established 

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

[Peter Gutmann]

Nick Lamb  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
Network, WebSpace-Forum e.K., and Wotone Communications.  Getting a whole pile
of other cross-certifications from additional CAs seems a bit redundant, and
has the flipside that once you've got a sufficiently complex mesh of cross-
certifications you've established such a level of fault-tolerance that it's
difficult to untrust a CA because there'll always be another cross-
certification somewhere leading to a trusted root.

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

[Nick Lamb]

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?

Acceptance into root trust stores is slow. Glacial in some cases. Mozilla has a 
published process. Microsoft, Apple and Oracle all say basically "email this 
address with your details" and beyond that all is opaque, other trust stores 
are worse / slower.

Let's Encrypt was announced in 2014, with its intention from the outset being 
to operate as a public CA. The ISRG Root (ISRG is the actual 501(c)3 entity 
behind Let's Encrypt formally) was self-signed in June 2015. In September 2015 
they formally applied to all major root trust stores including Mozilla.

In October 2015 they received a cross-certification from IdenTrust for Let's 
Encrypt Authority X1 (and its backup X2) and soon after began "beta" issuance, 
making real working leaf certificates for the web PKI, obeying the BRs and so 
on, initially for subscribers who had been pre-vetted and then for the general 
public.

By June 2016, with all major root trust stores still deliberating (Mozilla 
publicly, everyone else behind closed doors) Let's Encrypt was one of the 
biggest issuers on the entire World Wide Web. Officially, they were merely a 
subCA of IdenTrust as far as every trust store is concerned. In practice they 
were now bigger than almost all the directly trusted public CAs (Symantec and 
Comodo are bigger by most measures).

In July 2016 Mozilla signalled that future Firefox versions would add ISRG Root 
X1 to their trust store. No word yet from any other major trust store. This is 
not at all unusual.

So, cross signatures are the difference between being able to actually "enter 
the market" in reasonable time and being stalled out essentially indefinitely.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy