Re: StartCom & Qihoo Incidents

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

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

Re: StartCom & Qihoo Incidents

2016-10-29 Thread Matt Palmer 
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

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

Re: StartCom & Qihoo Incidents

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

Percy Alpha(PGP
)


On Sat, Oct 29, 2016 at 2:38 PM, Peter Bowen  wrote:

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

Re: WoSign: updated report and discussion

2016-10-29 Thread Percy 
Gerv,
I believe I found the new updated report still has intentional deception. 

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

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

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

Re: StartCom & Qihoo Incidents

2016-10-29 Thread Peter Bowen 
On Sat, Oct 29, 2016 at 2:29 PM, Percy  wrote:
> So 400 million Chinese users[1] are left vulnerable to MITM by even a casual 
> attacker and we cannot do anything about it!?

As stated previously, it is not for one browser to tell another how to
behave and the CA/Browser Forum explicitly cannot set requirements on
members for a number of reasons, including anti-trust concerns.

While probably not equivalent, this is not all that different from
software licensing discussions.  Each author of software can set
licensing terms as permitted by law; these terms might mean the
software qualifies as Free/Libre/Open Source Software (FLOSS) or they
may have requirements that meet other needs.  As I’m sure you are
aware, there are viewpoints that say that the only ethical stance is
only FLOSS and there are viewpoints that FLOSS is almost always wrong.
It is not for Mozilla to say that all browsers must be FLOSS (nor for
the CAB Forum to say such), even if one could argue that the only
option for a secure browser is for it to be FLOSS.

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

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

2016-10-29 Thread 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

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



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

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

2016-10-29 Thread Han Yuwei 
在 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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New SHA-1 certificates issued in 2016

2016-10-29 Thread Gervase Markham 
On 28/10/16 16:11, Patrick Figel wrote:
> I found a number of SHA-1 certificates chaining up to CAs trusted by
> Mozilla that have not been brought up on this list or on Bugzilla yet.
> Apologies in case I missed prior discussion for any of these, and kudos
> to censys for making this search incredibly easy.

Thank you for reporting these. Bugs filed:

https://bugzilla.mozilla.org/show_bug.cgi?id=1313872 (DigiCert)
https://bugzilla.mozilla.org/show_bug.cgi?id=1313873 (DocuSign)
https://bugzilla.mozilla.org/show_bug.cgi?id=1313874 (Gov of Spain)

Gerv

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

Re: New SHA-1 certificates issued in 2016

2016-10-29 Thread Gervase Markham 
On 28/10/16 16:11, Patrick Figel wrote:
> #7
> Some non-TLS-Server-Auth SHA-1 certificates chaining up to "Certum CA"
> (Asseco Data Systems S.A.). Most appear to be S/MIME or TLS client auth
> certificates, but I don't think the intermediates have any relevant
> technical constraints. I'm not sure if they're in scope for BRs/Mozilla,
> but here's the list in any case:
> https://crt.sh/?id=26427662=cablint
> https://crt.sh/?id=32333872=cablint
> https://crt.sh/?id=19594797=cablint
> https://crt.sh/?id=24979702=cablint

The scope of the BRs is debateable. These certs are clearly in scope for
Mozilla policy, as they chain up to trusted roots; however Mozilla
policy does not (yet) ban SHA-1 issuance other than via the BRs. This
may be fixed in policy version 2.3.

Without tls-server-auth and with other EKUs, these certs would not be
trusted in Firefox. The systemic risks from SHA-1 issuance remain, however.

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

2016-10-29 Thread Gervase Markham 
On 27/10/16 23:43, Han Yuwei wrote:
> Since Mozilla's working language is English (Not sure about this),

That is true.

> it's your responsibility to provide an accurate translation of CPS.

That is also true. However, we don't require that the English version be
the master copy.

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