Re: Something About CFCA (China Financial Certification Authority)

[Han Yuwei]

在 2016年10月31日星期一 UTC+8上午9:35:04，jonath...@gmail.com写道：
> Please see 6.1.7 which describes these content.

In version 3.2 I see that "证书最长期限（年）" (maxium validity period) about "SSL服务器证书" 
(SSL Server Certficates) is 5.

And I don't see any other informations about SM2 usage
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Something About CFCA (China Financial Certification Authority)

[jonathansshn]

Please see 6.1.7 which describes these content.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Matt Palmer]

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

And you've already been told that there is nothing that the Mozilla
community can do, at this time, to influence Qihoo 360 into tightening their
certificate validation code, so there's no reason to keep on about it on
this list, at this time.

- Matt

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

Re: StartCom & Qihoo Incidents

[Percy]

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

Re: WoSign: updated report and discussion

[Percy]

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

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

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

Re: StartCom & Qihoo Incidents

[He]

On October 30, 2016 8:39:55 PM GMT+08:00, "谭晓生"  wrote:
>Nothing compelled by the gov to trust the self-issued certificates.
>
>It is because some very large website like 12306.cn(the only one online
>entry to buy rail way tickets in China) and some government websites,
>they still using self-issued certificates, even we tried to offer free
>trusted certificates to them, they rejected.
>If a local browser try to block the access to these websites, user will
>force the browser to trust the self-issued certificates and complain,
>for the behavior training to end users, it is also an issue, user will
>used to trust the certificates which have a warning message by
>browsers, even there is a MITM attack, they still could not identify
>it.
>
>That’s the dilemma we have:
>Block the access to self-issued certificates, user will ignore and
>force trust the certificated, bad behavior training, user might change
>to competitor’s product.
>Do not block the access, there are possibility to do the MITM attack,
>the community complains.
>
>We already worked on a solution for a while and will release a report
>soon, hopefully to find a tradeoff between user experience and
>security.
>
>Thanks，
>Xiaosheng Tan
Hi, Tan.

I once visited my college webvpn website which is use self-signed certs, but 
360 browser continued load which was shocked me. It is not a **government 
website**(like your said 12306.cn), and I need know certs error.

As a Chinese netizen,  I don't think that browser should not tell users 
something serious happened which some users may not know how to operate. 

Sincerely,
He

PGP key-id=0x12f3d9a31960c4d4
PGP key Fingerprint=C793 674B 8F3D A78E 5600 834D 408C 9364 0A6D 0519


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

Re: Something About CFCA (China Financial Certification Authority)

[Han Yuwei]

在 2016年10月30日星期日 UTC+8下午10:26:57，jonath...@gmail.com写道：
> 1，It’s not true. CFCA's RSA root that included in Mozilla is not able to 
> issue sm2 certificate with sm3 hash. CFCA do have sm2 root that issue sm2 
> certificate but that root is not included in Mozilla or any other root store 
> such as Apple, Microsoft or Google. And our CPS never indicate that our RSA 
> root is able to issue sm2 certificate. It is impossible.
> 2，The signing key and encrypting key issue is a standard relate to 
> Chinese double certificate, which is different from ssl, codesigning and 
> email certificate. CFCA's root that included in Mozilla, Google and Apple is 
> never able to issue this kind of certificate. 
> 3，CFCA OV certificate have a longest valid period of 3 years. EV 
> certificate have a longest valid of 2 years. There is no root of CFCA that 
> included in Mozilla, Google and Apple can issue 5 year long certificate. 
> Please note that the sub root that use to be able to issue 5 year long 
> certificate is the GT root, which is a sha1 root that we already turned off. 
> This root issue 0 certificate after 2016 Jan 1, and this root is never 
> included in Mozilla, Apple and Google.

So why I didn't see these statements in the CPS or in the website?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Han Yuwei]

在 2016年10月30日星期日 UTC+8下午8:40:37，谭晓生写道：
> Nothing compelled by the gov to trust the self-issued certificates.
> 
> It is because some very large website like 12306.cn(the only one online entry 
> to buy rail way tickets in China) and some government websites, they still 
> using self-issued certificates, even we tried to offer free trusted 
> certificates to them, they rejected.
> If a local browser try to block the access to these websites, user will force 
> the browser to trust the self-issued certificates and complain, for the 
> behavior training to end users, it is also an issue, user will used to trust 
> the certificates which have a warning message by browsers, even there is a 
> MITM attack, they still could not identify it.
> 
> That’s the dilemma we have:
> Block the access to self-issued certificates, user will ignore and force 
> trust the certificated, bad behavior training, user might change to 
> competitor’s product.
> Do not block the access, there are possibility to do the MITM attack, the 
> community complains.
> 
> We already worked on a solution for a while and will release a report soon, 
> hopefully to find a tradeoff between user experience and security.
> 
> Thanks，
> Xiaosheng Tan
> 
> 
> 发件人: Percy 
> 日期: 2016年10月30日 星期日 下午4:01
> 至: 晓生 谭 
> 抄送: "mozilla-dev-security-pol...@lists.mozilla.org" 
> 
> 主题: Re: StartCom & Qihoo Incidents
> 
> As we observed the large scale MITM against iCloud, Outlook, Google and 
> Github carried out on the backbone router with self-signed certs, and that 
> the browsers are explicitly loads self-signed certs, I think it's clear that 
> browsers in China are compelled by the gov to enable insecure cryptography by 
> default.
> 
> Percy 
> Alpha(PGP)
> 
> 
> On Sat, Oct 29, 2016 at 11:36 PM, 谭晓生 
> > wrote:
> Is there anybody thought about why it happens in China? Why the local browser 
> did not block the self-issued certificates?
> 
> Thanks，
> Xiaosheng Tan
> 
> 
> 
> 在 2016/10/30 
> 下午1:17，“Percy”> 写入:
> 
> On Saturday, October 29, 2016 at 5:54:10 PM UTC-7, Matt Palmer wrote:
> > On Sat, Oct 29, 2016 at 02:59:07PM -0700, Percy wrote:
> > > Perhaps not. However, Qihoo 360's behavior calls the trustworthiness 
> of the
> > > entire company into question. And such trust, in my view, should be
> > > evaluated when WoSign/StartCom submit their re-inclusion requests in 
> the
> > > future.
> >
> > You can make that argument when WoSign/StartCom's reinclusion 
> discussions
> > take place on this list.  Now is not the appropriate time for that.
> >
> > - Matt
> WoSign/StartCom's re-inclusion request might be a year from now. In the 
> meanwhile, those 400 million users will be exposed to MITM. That's why I'm 
> bringing it up now, rather than one year later.
> ___
> dev-security-policy mailing list
> 
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

I think that you can maintain a list to preload self-signed certificates, 
something like HSTS preload. For me the 12306's certficate has a securtiy 
exception for a long time and it still works.

And there's any other government sites using self-signed certs? Who?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Something About CFCA (China Financial Certification Authority)

[jonathansshn]

1，  It’s not true. CFCA's RSA root that included in Mozilla is not able to 
issue sm2 certificate with sm3 hash. CFCA do have sm2 root that issue sm2 
certificate but that root is not included in Mozilla or any other root store 
such as Apple, Microsoft or Google. And our CPS never indicate that our RSA 
root is able to issue sm2 certificate. It is impossible.
2，  The signing key and encrypting key issue is a standard relate to 
Chinese double certificate, which is different from ssl, codesigning and email 
certificate. CFCA's root that included in Mozilla, Google and Apple is never 
able to issue this kind of certificate. 
3，  CFCA OV certificate have a longest valid period of 3 years. EV 
certificate have a longest valid of 2 years. There is no root of CFCA that 
included in Mozilla, Google and Apple can issue 5 year long certificate. Please 
note that the sub root that use to be able to issue 5 year long certificate is 
the GT root, which is a sha1 root that we already turned off. This root issue 0 
certificate after 2016 Jan 1, and this root is never included in Mozilla, Apple 
and Google.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Gervase Markham]

On 30/10/16 12:39, 谭晓生 wrote:
> That’s the dilemma we have:
> Block the access to self-issued certificates, user will ignore and force 
> trust the certificated, bad behavior training, user might change to 
> competitor’s product.
> Do not block the access, there are possibility to do the MITM attack, the 
> community complains.

These are not your only two options. You could build a system which was
the opposite of Mozilla's OneCRL, or the equivalent of Microsoft's root
list - i.e. a Qihoo-curated list of self-signed certificates which were
to be trusted, which was dynamically downloaded by the browser on a
regular basis. That way, you could enable these big sites without
enabling all self-signed certificates.

Why did 12306.cn and other sites actively reject using a
publicly-trusted cert?

Gerv

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

Re: WoSign: updated report and discussion

[Gervase Markham]

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

Well, that statement is either false or very misleading, because in
order for an SM2 certificate to be useful "globally", there needs to be
wide browser support. I don't know exactly which browsers support SM2,
but I know that Firefox, Chrome, Safari, IE and Edge do not.

> This means that WoSign is not only signing SM2 certs for testing but
> also signing SM2 from the globally trusted roots in production. I
> suspect that there are SM2 certs from trusted root WoSign certs used
> in the wild.

Can you find one?

Gerv


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

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

[Gervase Markham]

On 29/10/16 22:23, Han Yuwei wrote:
> Is SM2 acceptable in publicy-trusted CAs? I don't think so.

No; the BRs list the permitted algorithms, and SM2 is not one of them.

> Maybe Gerv could explain more about this. And I am wondering what can
> CA do if government requirement conflicts with Mozilla's policy?

It may well be a government requirement that Chinese CAs be able to
issue SM2 certificates. However, no-one has yet demonstrated that it's a
requirement that they do so from specific roots (i.e. the ones trusted
by the major root stores).

Gerv



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

Re: StartCom & Qihoo Incidents

[谭晓生]

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

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

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

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

Thanks，
Xiaosheng Tan


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

主题: Re: StartCom & Qihoo Incidents

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

Percy 
Alpha(PGP)


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

Thanks，
Xiaosheng Tan



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

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

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


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

Something About CFCA (China Financial Certification Authority)

[Han Yuwei]

According to their CPS (Chinese version 3.2 Jul.2016),

1. All CAs can issue SM2 certificates and uses SM3 Hash.

2. There is a "signing key" generated by subscriber and "encryption key" 
generated by CFCA which transmitted to subscriber.

3. For SSL certificate, the longest vaild duration is 5 years, which is much 
more than 39 months.

Are those conflicting with Mozilla's policy?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Han Yuwei]

在 2016年10月30日星期日 UTC+8上午5:30:23，Peter Bowen写道：
> > On Oct 29, 2016, at 2:23 PM, Han Yuwei  wrote:
> > 
> > 在 2016年10月28日星期五 UTC+8下午9:23:01，wangs...@gmail.com写道：
> >> We are not intended to cover-up anything since we had disclosed every 
> >> change to the Chinese version CP/CPS at once after the auditor reviewed.
> >> The “ROOTCA(SM2)” CA in $1.1.3 of CPS ver4.3 is equivalent to the “SM2 
> >> ROOT Certificate” CA in $1.1.3 of CPS ver4.1. The “Guangdong Certificate 
> >> Authority(SM2) ” CA in $1.1.3 of CPS ver4.3 is equivalent to the “SM2 CA 
> >> Certificate” CA in $1.1.3 of CPS ver4.1. We change these names in diagram 
> >> in this revision in order to show the actual CN of these certificates. 
> >> Furthermore, we only issue SM2 subscriber certificates from the subCA of 
> >> “ROOTCA(SM2)” CA.
> > 
> > Is SM2 acceptable in publicy-trusted CAs? I don't think so.
> > 
> > Maybe Gerv could explain more about this. And I am wondering what can CA do 
> > if government requirement conflicts with Mozilla's policy?
> 
> It is acceptable to have a single CPS that covers CAs that are included the 
> Mozilla list of trust anchors and CAs that are not trusted by Mozilla.  The 
> CPS should make clear which portions apply to which CA when there are 
> portions that do not apply to all CAs.
> 
> In this case, I would expect that the ROOTCA(SM2) CA is not proposed for 
> inclusion in Mozilla.  As long as the CPS does not allow issuance of SM2 
> signed certificates or certificates with SM2 subject public keys from the CAs 
> proposed for inclusion in Mozilla, I do not seen an issue.
> 
> Thanks,
> Peter

I don't see anything about this in Chinese CPS or Bugzilla. Could someone point 
out or GDCA explain about this?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Han Yuwei]

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

Re: [FORGED] Re: StartCom & Qihoo Incidents

[Peter Gutmann]

Percy  writes:

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

Is that really the government compelling them, or just the browser vendors
deciding to enable a free market and/or remove dependency on non-Chinese CAs?
If the browsers secretly trusted some government-run CA that'd be a different
matter, but I'm not sure whether simply chosing to trust self-signed certs is
a genuine smoking gun...

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

Re: StartCom & Qihoo Incidents

[Percy]

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

Percy Alpha(PGP
)


On Sat, Oct 29, 2016 at 11:36 PM, 谭晓生  wrote:

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

Re: StartCom & Qihoo Incidents

[谭晓生]

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

Thanks，
Xiaosheng Tan



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

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

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


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