Re: Remediation Plan for WoSign and StartCom

[Rami Kogan]

Just came across the following Phishing site which is using a StartCom cert:

hXXps://serviices-intl.com/webapps/6fa9b/websrc







On 11/2/16, 6:32 PM, "dev-security-policy on behalf of Itzhak Daniel" 
 wrote:

>On Wednesday, November 2, 2016 at 5:22:30 PM UTC+2, Gervase Markham wrote:
>> Hi Daniel,
>>
>> On 02/11/16 14:11, Itzhak Daniel wrote:
>> As far as the DigiCert certs go, it is far too early to have an opinion
>> on what Mozilla is or isn't doing.
>
>I have to agree, the time span is too short (at least they didn't backdate).
>
>> I'm not sure what you mean by "ignoring Mozilla Security Community". I
>> am happy with the level of communication by Comodo about their incident.
>
>AFAIK they didn't include the TLD '.re' in their incident report [1] (the 
>certificate was probably issued on Jun 30th, 2014; Google CT 1st seen 
>timestamp: 2014-07-02 14:54:54 GMT [2]), they had the same mistake before the 
>'sb' incident, but did/do not acknowledge it officially [3].
>
>Links,
>1. 
>https://scanmail.trustwave.com/?c=4062=sZWa2NJm1b7zf0w12nNA5JOUrTfLuNXQPooKM1C0fA=5=https%3a%2f%2fwww%2email-archive%2ecom%2fdev-security-policy%40lists%2emozilla%2eorg%2fmsg04274%2ehtml
>2. 
>https://scanmail.trustwave.com/?c=4062=sZWa2NJm1b7zf0w12nNA5JOUrTfLuNXQPtwOMQDifg=5=https%3a%2f%2fcrt%2esh%2f%3fid%3d4467456
>3. 
>https://scanmail.trustwave.com/?c=4062=sZWa2NJm1b7zf0w12nNA5JOUrTfLuNXQPtpZZQXtKA=5=https%3a%2f%2fgroups%2egoogle%2ecom%2fforum%2f%23%21topic%2fmozilla%2edev%2esecurity%2epolicy%2fLQSrnPv2qOo
>___
>dev-security-policy mailing list
>dev-security-policy@lists.mozilla.org
>https://scanmail.trustwave.com/?c=4062=sZWa2NJm1b7zf0w12nNA5JOUrTfLuNXQPtpZZ1bsJg=5=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy



This transmission may contain information that is privileged, confidential, 
and/or exempt from disclosure under applicable law. If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, distribution, 
or use of the information contained herein (including any reliance thereon) is 
strictly prohibited. If you received this transmission in error, please 
immediately contact the sender and destroy the material in its entirety, 
whether in electronic or hard copy format.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Itzhak Daniel]

On Wednesday, November 2, 2016 at 5:22:30 PM UTC+2, Gervase Markham wrote:
> Hi Daniel,
> 
> On 02/11/16 14:11, Itzhak Daniel wrote:
> As far as the DigiCert certs go, it is far too early to have an opinion
> on what Mozilla is or isn't doing.

I have to agree, the time span is too short (at least they didn't backdate).

> I'm not sure what you mean by "ignoring Mozilla Security Community". I
> am happy with the level of communication by Comodo about their incident.

AFAIK they didn't include the TLD '.re' in their incident report [1] (the 
certificate was probably issued on Jun 30th, 2014; Google CT 1st seen 
timestamp: 2014-07-02 14:54:54 GMT [2]), they had the same mistake before the 
'sb' incident, but did/do not acknowledge it officially [3].

Links,
1. 
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg04274.html
2. https://crt.sh/?id=4467456
3. 
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/LQSrnPv2qOo
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

Hi Daniel,

On 02/11/16 14:11, Itzhak Daniel wrote:
> Interesting that Comodo and DigiCert are getting a different
> treatment, 

As far as the DigiCert certs go, it is far too early to have an opinion
on what Mozilla is or isn't doing. And let us remember, the WoSign
incident involved multiple instances of flat-out lying to Mozilla. I
would expect non-lying CAs to get a different treatment from lying ones.

> I wonder if WoSign/StartCom had ignored Mozilla Security
> Community at some degree, the same way Comodo and DigiCert are doing,
> would it saved them.

I'm not sure what you mean by "ignoring Mozilla Security Community". I
am happy with the level of communication by Comodo about their incident.
DigiCert are still working on theirs. (As are the Government of Spain
and DocuSign.)

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

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

Hi dracenmarx,

On 02/11/16 12:44, dracenm...@googlemail.com wrote:
> (1) I did find any public answer from Apple, Google or Mozilla in
> regards to the Remediation plan by StartCom. I have the feeling, that
> the sanctions were applied without considering this document. (
> https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf
> ) You didn't even reply to this document after it was mentioned here
> in this discussion.

StartCom were circulating this document to us before it was formally
published. We think their remediation plan is reasonable but it does not
change the decision, which was based on a determination about past
events rather than future promises.

> (2) I am a bit upset about the cuttling line Mozilla set (and which
> was adopted by Chrome yesterday)
> 
> Mozilla announced on October, 24th, that certificates signed on 22
> October or later will be not verified by their future browser
> versions. 

Both StartCom and WoSign were aware in advance that this was the
deadline we were proposing. How they communicated that to their
customers (or not) is up to them. If you are unhappy with them for
selling you a cert which will not meet your requirements, you need to
take it up with them.

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

Re: Remediation Plan for WoSign and StartCom

[Itzhak Daniel]

Interesting that Comodo and DigiCert are getting a different treatment, I 
wonder if WoSign/StartCom had ignored Mozilla Security Community at some 
degree, the same way Comodo and DigiCert are doing, would it saved them.

(I don't know if there are chatters in the back, maybe I missed something and 
these issue are already resolved.)

Comodo Links:
(Their incident report didn't include .re TLD)
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/PoMZvss_PRo

DigiCert Links:
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/xTKZTDKnNWg
https://bugzilla.mozilla.org/show_bug.cgi?id=1313874
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[dracenmarx]

I think that the steps against StartCom are too extreme and I would like to 
tell my personal opinion. First of all, I want to say that I don't have any 
benefits when I tell this opinion, since I personally already switched to a 
different CA.

(1) I did find any public answer from Apple, Google or Mozilla in regards to 
the Remediation plan by StartCom. I have the feeling, that the sanctions were 
applied without considering this document. ( 
https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf )
You didn't even reply to this document after it was mentioned here in this 
discussion.

(2) I am a bit upset about the cuttling line Mozilla set (and which was adopted 
by Chrome yesterday)

Mozilla announced on October, 24th, that certificates signed on 22 October or 
later will be not verified by their future browser versions. Are you aware that 
this is really unfair to all customers who have ordered certificates in the 
time frame between 22 and 24 October (without including the time it takes until 
the press spread the news)? They had no chance to base their buying decision on 
the sanction, because the sanction was not published at this time, or published 
by the press / news pages. Correct would have been if Mozilla set the cutting 
line to a future date, after the sanction was announced, for example 1 November.

You, the browser vendors, are not punishing the CAs with this unfortunate 
deadline - you are affecting the webmasters who paid for certificates they 
ordered between 22-24 October, who didn't had any chance to know Mozilla's 
decision.

(3) Since I have read a few variant forms of Mozilla's sanction plan (probably 
some of them were just beta), I have read that it was/is cosidered, that there 
will be a 1 year phase of distrust, before the re-inclusion can happen again. 
Somewhere else I read that the re-inclusion can be July 2017. In any case, 
that's unrealistic and hilarious; If the second largest browser vendor 
(Mozilla) will distrust a CA, then the CA will most likely become bankrupt a 
few months later. I don't think they could survive 1 year. DigiNotar, for 
example, fell into insolvency just a few weeks after they lost the trust by the 
vendors.

(4) I am also a bit upset about Google's decision. They not only also used that 
unfair cutting line date (22 October), but also ruled out every chance in 
rescuing the trust and finding a compromise. I do think every person or company 
should get a second chance. From what I have read and heared, I do think that 
StartCom is now willing to do drastic changes and won't make the same mistakes 
again.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 24/10/16 06:55, Samuel Pinder wrote:
> There's some good questions there, actually. OEM SSL, does that mean 
> another CA would be doing the validation and issuing using their own 
> infrastructure and team, which you would be reselling via a 
> constrained intermediate? 

I suspect he means that the other CA will do validation and issuance,
and WoSign will be a sales channel. But Richard is welcome to clarify.

Of course, if parts of WoSign's infrastructure are involved in the
certificate issuance or validation process, those parts would become
subject to the audits of the other CA.

Gerv

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

Re: Remediation Plan for WoSign and StartCom

[Samuel Pinder]

There's some good questions there, actually. OEM SSL, does that mean
another CA would be doing the validation and issuing using their own
infrastructure and team, which you would be reselling via a
constrained intermediate? I don't think it'd be a good idea at present
to be gaining effectively a new CA certificate that is cross-signed,
only to be using the existing infrastructure that is currently meant
to be undergoing remediation. That'd probably be put under the same
restrictions too if that's the case.
Samuel Pinder


On Mon, Oct 24, 2016 at 6:43 AM, Richard Wang <rich...@wosign.com> wrote:
> For Q1:  This is a OEM SSL from other trusted CA;
> For Q2:  We stopped the free SSL certificate after Apple announcement, it is 
> announced in our free SSL website;
> For Q3:  I am the Acting CEO now till the new CEO arrives.
>
>
> Best Regards,
>
> Richard
>
> From: Eric Mill [mailto:e...@konklone.com]
> Sent: Monday, October 24, 2016 12:05 PM
> To: Richard Wang <rich...@wosign.com>
> Cc: Kathleen Wilson <kwil...@mozilla.com>; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Remediation Plan for WoSign and StartCom
>
> Hi Richard,
>
> A few questions -
>
> 1) Your post says "There will be new SSL certificates issued by a new WoSign 
> intermediate CA which is signed by the one of global trusted root CA, it 
> supports all the browsers (including Firefox). This will be done within one 
> months."
>
> How will this WoSign intermediate CA be different from the 4 affected roots? 
> Will it use the same WoSign issuance infrastructure used by the 4 roots that 
> Mozilla has decided to distrust?
>
> 2) Your announcement to customers only discusses Mozilla's action. Are you 
> planning to inform customers of how Apple's decision to distrust WoSign's 
> roots will affect WoSign operations?
>
> 3) A previous Qihoo 360 document said that you are being removed as WoSign 
> CEO. Are you still authorized by Qihoo 360 to make announcements like this?
>
> -- Eric
>
> On Sun, Oct 23, 2016 at 10:46 PM, Richard Wang 
> <rich...@wosign.com<mailto:rich...@wosign.com>> wrote:
> Hi Kathleen,
>
> WoSign released the news today since I just came back from USA CABF meeting.
>
> http://www.wosign.com/news/announcement_about_Mozilla_Action_20161024.htm (in 
> Chinese)
>
> https://www.wosign.com/english/News/announcement_about_Mozilla_Action_20161024.htm
>   (in English)
>
>
>
> Best Regards,
>
> Richard
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard<mailto:dev-security-policy-bounces%2Brichard>=wosign@lists.mozilla.org<mailto:wosign@lists.mozilla.org>]
>  On Behalf Of Kathleen Wilson
> Sent: Friday, October 21, 2016 10:43 AM
> To: 
> mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: Remediation Plan for WoSign and StartCom
>
> On Thursday, October 20, 2016 at 6:59:08 PM UTC-7, Percy wrote:
>> Kathleen,
>> As most users affected by this decision are Chinese, will you be able to 
>> make the blog post available in Chinese on the security blog as well? You 
>> can ask the Chinese firefox community or me to translate.
>>
>> As I stated earlier, there are almost no news of the distrust of 
>> WoSign/StartCom on the Chinese Internet and WoSign/StartCom has not posted 
>> anything related to this. I believe it's paramount to prepare Chinese 
>> website owners for the phasing out of the affected roots.
>
> Noted. I will look into how to get it translated into Chinese and how to make 
> that version available as well.
>
> Thanks,
> Kathleen
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org<mailto: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<mailto:dev-security-policy@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
>
> --
> konklone.com<https://konklone.com> | @konklone<https://twitter.com/konklone>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Remediation Plan for WoSign and StartCom

[Richard Wang]

For Q1:  This is a OEM SSL from other trusted CA;
For Q2:  We stopped the free SSL certificate after Apple announcement, it is 
announced in our free SSL website;
For Q3:  I am the Acting CEO now till the new CEO arrives.


Best Regards,

Richard

From: Eric Mill [mailto:e...@konklone.com]
Sent: Monday, October 24, 2016 12:05 PM
To: Richard Wang <rich...@wosign.com>
Cc: Kathleen Wilson <kwil...@mozilla.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Remediation Plan for WoSign and StartCom

Hi Richard,

A few questions -

1) Your post says "There will be new SSL certificates issued by a new WoSign 
intermediate CA which is signed by the one of global trusted root CA, it 
supports all the browsers (including Firefox). This will be done within one 
months."

How will this WoSign intermediate CA be different from the 4 affected roots? 
Will it use the same WoSign issuance infrastructure used by the 4 roots that 
Mozilla has decided to distrust?

2) Your announcement to customers only discusses Mozilla's action. Are you 
planning to inform customers of how Apple's decision to distrust WoSign's roots 
will affect WoSign operations?

3) A previous Qihoo 360 document said that you are being removed as WoSign CEO. 
Are you still authorized by Qihoo 360 to make announcements like this?

-- Eric

On Sun, Oct 23, 2016 at 10:46 PM, Richard Wang 
<rich...@wosign.com<mailto:rich...@wosign.com>> wrote:
Hi Kathleen,

WoSign released the news today since I just came back from USA CABF meeting.

http://www.wosign.com/news/announcement_about_Mozilla_Action_20161024.htm (in 
Chinese)

https://www.wosign.com/english/News/announcement_about_Mozilla_Action_20161024.htm
  (in English)



Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard<mailto:dev-security-policy-bounces%2Brichard>=wosign@lists.mozilla.org<mailto:wosign@lists.mozilla.org>]
 On Behalf Of Kathleen Wilson
Sent: Friday, October 21, 2016 10:43 AM
To: 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: Remediation Plan for WoSign and StartCom

On Thursday, October 20, 2016 at 6:59:08 PM UTC-7, Percy wrote:
> Kathleen,
> As most users affected by this decision are Chinese, will you be able to make 
> the blog post available in Chinese on the security blog as well? You can ask 
> the Chinese firefox community or me to translate.
>
> As I stated earlier, there are almost no news of the distrust of 
> WoSign/StartCom on the Chinese Internet and WoSign/StartCom has not posted 
> anything related to this. I believe it's paramount to prepare Chinese website 
> owners for the phasing out of the affected roots.

Noted. I will look into how to get it translated into Chinese and how to make 
that version available as well.

Thanks,
Kathleen

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



--
konklone.com<https://konklone.com> | @konklone<https://twitter.com/konklone>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Eric Mill]

Hi Richard,

A few questions -

1) Your post says "There will be new SSL certificates issued by a new
WoSign intermediate CA which is signed by the one of global trusted root
CA, it supports all the browsers (including Firefox). This will be done
within one months."

How will this WoSign intermediate CA be different from the 4 affected
roots? Will it use the same WoSign issuance infrastructure used by the 4
roots that Mozilla has decided to distrust?

2) Your announcement to customers only discusses Mozilla's action. Are you
planning to inform customers of how Apple's decision to distrust WoSign's
roots will affect WoSign operations?

3) A previous Qihoo 360 document said that you are being removed as WoSign
CEO. Are you still authorized by Qihoo 360 to make announcements like this?

-- Eric

On Sun, Oct 23, 2016 at 10:46 PM, Richard Wang <rich...@wosign.com> wrote:

> Hi Kathleen,
>
> WoSign released the news today since I just came back from USA CABF
> meeting.
>
> http://www.wosign.com/news/announcement_about_Mozilla_Action_20161024.htm
> (in Chinese)
>
> https://www.wosign.com/english/News/announcement_
> about_Mozilla_Action_20161024.htm  (in English)
>
>
>
> Best Regards,
>
> Richard
>
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-bounces+richard=
> wosign@lists.mozilla.org] On Behalf Of Kathleen Wilson
> Sent: Friday, October 21, 2016 10:43 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Remediation Plan for WoSign and StartCom
>
> On Thursday, October 20, 2016 at 6:59:08 PM UTC-7, Percy wrote:
> > Kathleen,
> > As most users affected by this decision are Chinese, will you be able to
> make the blog post available in Chinese on the security blog as well? You
> can ask the Chinese firefox community or me to translate.
> >
> > As I stated earlier, there are almost no news of the distrust of
> WoSign/StartCom on the Chinese Internet and WoSign/StartCom has not posted
> anything related to this. I believe it's paramount to prepare Chinese
> website owners for the phasing out of the affected roots.
>
> Noted. I will look into how to get it translated into Chinese and how to
> make that version available as well.
>
> Thanks,
> Kathleen
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone <https://twitter.com/konklone>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Remediation Plan for WoSign and StartCom

[Richard Wang]

Hi Kathleen,

WoSign released the news today since I just came back from USA CABF meeting.

http://www.wosign.com/news/announcement_about_Mozilla_Action_20161024.htm (in 
Chinese)

https://www.wosign.com/english/News/announcement_about_Mozilla_Action_20161024.htm
  (in English)



Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Kathleen Wilson
Sent: Friday, October 21, 2016 10:43 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Remediation Plan for WoSign and StartCom

On Thursday, October 20, 2016 at 6:59:08 PM UTC-7, Percy wrote:
> Kathleen,
> As most users affected by this decision are Chinese, will you be able to make 
> the blog post available in Chinese on the security blog as well? You can ask 
> the Chinese firefox community or me to translate. 
> 
> As I stated earlier, there are almost no news of the distrust of 
> WoSign/StartCom on the Chinese Internet and WoSign/StartCom has not posted 
> anything related to this. I believe it's paramount to prepare Chinese website 
> owners for the phasing out of the affected roots.

Noted. I will look into how to get it translated into Chinese and how to make 
that version available as well.

Thanks,
Kathleen

___
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: Remediation Plan for WoSign and StartCom

[Erwann Abalea]

Bonjour,

Le vendredi 21 octobre 2016 12:48:21 UTC+2, marc@gmail.com a écrit :
[...]
> Just the opinion of a user who is securing services, websites and his mails 
> with certificates but is not capable of paying hundreds of Euros / Dollars 
> for achieving this goal every year.

DV certificates can be found for much less than that. Less than 5$ for a DV 
cert, less than 35$ for an OV cert, 11$ for an S/MIME cert (which nobody uses 
so far because it's a mess, but I digress).

It's nice to be able to have free certificates, but I don't consider 5$ a year 
for a DV to be expensive.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Peter Bowen]

On Thu, Oct 20, 2016 at 1:57 PM, Kathleen Wilson  wrote:
> 1) Distrust certificates with a notBefore date after October 21, 2016 which 
> chain up to the following affected roots. If additional back-dating is 
> discovered (by any means) to circumvent this control, then Mozilla will 
> immediately and permanently revoke trust in the affected roots.
> a) This change will go into the Firefox 51 release train.
> b) The code will use the following Subject Distinguished Names to identify 
> the root certificates, so that the control will also apply to 
> cross-certificates of these roots.
> i) CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
> ii) CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN
> iii) CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, 
> C=CN
> iv) CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
> v) CN=StartCom Certification Authority, OU=Secure Digital Certificate 
> Signing, O=StartCom Ltd., C=IL
> vi) CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL

According to the wiki, Asseco Certum has cross-signed at least one of
these roots.  Is it expected that Certum will take any action, or do
the above changes mean that Certum's cross-sign of WoSign will be
considered to not exist for the purpose of Mozilla policy?

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

Re: Remediation Plan for WoSign and StartCom

[Jernej Simončič]

On Sat, 22 Oct 2016 16:26:51 +0200, Jakob Bohm wrote:

> Thus the need for those who obtaind OV code
> signing certificates from StartCom to start looking for alternatives,
> and my suggestion, as a public service, that someone here might chime
> in with the names of small/individual developer friendly issuers of
> code signing certificates.

I'm currently using a Comodo-issued codesigning certificate for my
projects. While the reseller I bought it from (http://www.ksoftware.net/)
discouraged me from getting the certificate issued to me as an individual
(due to supposedly complicated checks required), the process wasn't really
that hard - it involved getting a notary-validated signature of Comodo's
document and notary-validated copies of a bank statement of mine and a
phone bill (while the requirements say you can use other utility bills, you
should use a phone bill if you don't have your phone number published in a
directory, since they use it for validation). It took about a week from
applying for the certificate to getting it issued.

When I was buying the certificate, I found a 25% discount code on some 3rd
party website.

-- 
begin  .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Jakob Bohm]

On 22/10/2016 14:59, Ryan Sleevi wrote:

On Saturday, October 22, 2016 at 5:11:29 AM UTC-7, Jakob Bohm wrote:

Talking of codesigning, which root store does Chrome use to validate
signatures on the PPAPI plug ins it is currently forcing developers to
switch to?


I've mentioned to you repeatedly that no one uses the code signing store of 
Mozilla. Chrome itself does not use a code signing store - as I've also 
mentioned, CA-mediated code-signing is largely a historical artifact of 
Microsoft's past decisions, and not something to be practiced or encouraged.



OK, I was unsure if Chrome required signing of PPAPI plugins
distributed outside the (being closed) store, and if so what the rules
were (I'll be researching that soon anyway for other reasons).


So such an action has no impact on anyone consuming the code signing certs, so 
there's no need to suggest alternatives.




While Microsoft code signing typically uses the Microsoft root store
(obviously), there are many other ecosystems using the object/code
signing trust logic, even though Mozilla is out of the game:

- Some Mozilla clones/forks have kept the broader approach to extension
 signature checks that Mozilla replaced by "all extensions must be
 signed by addons.mozilla.org", those obviously maintain their own code
 signing trust bits.

- Java applets that need extended access use either the Browser root
 store, the OS root store or the Oracle root store depending on
 circumstances, thus anyone signing Java applets need a CA chaining to
 all those stores.

- iOS apps need a signature that chains to the Apple code signing root
 store, which currently only trusts Apple's own root for this.

- Apps for some of Adobe's plugin systems use object signing with
 unknown root stores.

- PDF document signing tends to use the object signing trust bits
 rather than the e-mail signing trust bits.

- And Microsoft is still in business with their various code signature
 checks.

I find it somewhat likely that at least some of the above will use a
root store that follows in Mozilla's footsteps regarding distrust of
WoSign and StartCom.  Thus the need for those who obtaind OV code
signing certificates from StartCom to start looking for alternatives,
and my suggestion, as a public service, that someone here might chime
in with the names of small/individual developer friendly issuers of
code signing certificates.

In other words, my question was in the general context of this being
the only public forum about root store policies, rather than
specifically about the Mozilla store.


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: Remediation Plan for WoSign and StartCom

[Ryan Sleevi]

On Saturday, October 22, 2016 at 5:11:29 AM UTC-7, Jakob Bohm wrote:
> Talking of codesigning, which root store does Chrome use to validate
> signatures on the PPAPI plug ins it is currently forcing developers to
> switch to?

I've mentioned to you repeatedly that no one uses the code signing store of 
Mozilla. Chrome itself does not use a code signing store - as I've also 
mentioned, CA-mediated code-signing is largely a historical artifact of 
Microsoft's past decisions, and not something to be practiced or encouraged.

So such an action has no impact on anyone consuming the code signing certs, so 
there's no need to suggest alternatives.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Jakob Bohm]

On 22/10/2016 00:57, Jernej Simončič wrote:

On Fri, 21 Oct 2016 10:03:46 -0700 (PDT), Han Yuwei wrote:


I am also a StartCom's SSL & S/MIME certificate user. The only problem for me 
is that I must re-config nginx. S/MIME have a lot of alternatives for free. Code 
Signing may only works on Windows but Microsoft seems like don't care about this 
because CNNIC is still trusted.


In my experience, StartCom's non-EV codesigning certificates were never
actually useful - they explicitly disable timestamping, so after the
certificate expires, the signature is rendered invalid.



That stinks.

While Mozilla doesn't care about code signing and Microsoft's root
store may be lax, I think there are probably a lot of (current)
StartCom low cost OV codesigning customers who will need a suggestion
for an alternative.

Talking of codesigning, which root store does Chrome use to validate
signatures on the PPAPI plug ins it is currently forcing developers to
switch to?

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: Remediation Plan for WoSign and StartCom

[Samuel Pinder]

Following on from my previous posting, I have found that Startcom are
still issuing certificates past the 21st of October that should be
subject to blocking in an upcoming version of Firefox
https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 . I have
therefore obtained such a certificate via my active account and
decided to create the following test URL so that anyone trying new
builds of Firefox have a URL to test the proposed blocking against:
https://notbefore-after-21st-test.samspin.net/
I do not have an equivalent for WoSign as a I do not have a
subscription there and they no longer issue free certificates anyway.
I hope this helps in some way!
Samuel Pinder
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Percy]

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

Re: Remediation Plan for WoSign and StartCom

[Samuel Pinder]

I have been reading into this discussion for quite some time since my
initial posting, and as a Startcom customer even I wholeheartedly
agree with the measures being taken. I think I am one of the lucky
ones, as I have got my set of certificates before the cut-off deadline
and intend to look after them very carefully as they are valid for two
years that I would otherwise not be able to afford elsewhere. I am
absolutely furious to hear that Richard Wang attempted to cover up
mis-issued SHA-1 certificates among other things. It is a perfectly
reasonable thing to expect- browser makers remember the debacle when
MD5 collisions became possible and are probably quite rightly
terrified of such a scenario happening again as it took years to
migrate away from all use of MD5, long after forged MD5-based
certificates became possible. I would hope that Startcom learn from
this and, although I do see their model as rather unique and have
quite a position in the market, they must realise that they are not
too big to fail. With any luck the measures taken will ensure that
more competent management takes place that avoid these issues ever
happening again. I am very concerned that neither Startcom nor WoSign
are publicly announcing these measures on their websites, I have even
contacted Startcom about this via live chat. Their only responses seem
to be that they are waiting for 'upper management' to make an
announcement, despite me directly sending links to the filed bug
reports clearly showing Mozilla's plans. Well, that's rather like
burying their heads in the sand, as the deadline is today and other
customers whom do not follow these security forums will have no idea
that newly certificates after today will not be valid in Firefox until
it is too late. Hopefully once the management of Startcom has changed
hands away from WoSign (their very well hidden incident report link
suggests this will happen around December), one can expect much more
expeditious and honest communication.
Samuel Pinder


On Fri, Oct 21, 2016 at 7:29 PM,   wrote:
> Isn't that something you should take up with StartCom? Bottom line you payed 
> them for your certificate, didn't you. Not Mozilla. Perhaps StartCom should 
> have been a bit more careful so they could keep serving their customers.
>
> CU Hans
> ___
> 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: Remediation Plan for WoSign and StartCom

[okaphone . elektronika]

Isn't that something you should take up with StartCom? Bottom line you payed 
them for your certificate, didn't you. Not Mozilla. Perhaps StartCom should 
have been a bit more careful so they could keep serving their customers.

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

Re: Remediation Plan for WoSign and StartCom

[Han Yuwei]

在 2016年10月21日星期五 UTC+8下午6:48:21，marc@gmail.com写道：
> Am Freitag, 21. Oktober 2016 03:59:08 UTC+2 schrieb Percy:
> > Kathleen,
> > As most users affected by this decision are Chinese, will you be able to 
> > make the blog post available in Chinese on the security blog as well? You 
> > can ask the Chinese firefox community or me to translate. 
> Hi,
> 
> only the distrust of Wosign affects mostly chinese Users.
> 
> The distrust of StartCom affects individuals, non profit organizations and 
> small companies worldwirde. StartCom was the only CA where these people and 
> groups could get ov,dv,s/mime and code signing certificates for a reasonable 
> price. Of course the incidents needed clarification and ofcourse actions are 
> to be taken to prevent such behaviour in future. But Gerv stated that the 
> main reasons for the harsh punishment are the lies and deceptions. The 
> responsible person is no longer in charge, StartCom has to pay a lot of money 
> to make the changes required by Mozilla. This is OK and fine from the view of 
> a customer / user.
> 
> But with distrusting StartCom roots Mozilla isn't increasing security for 
> their users and the web, Mozilla will decreasing the security.
> 
> A lot of people which have secured their services and code will lose this 
> possibility. From the view of a user not really understandable.
> 
> 
> Just the opinion of a user who is securing services, websites and his mails 
> with certificates but is not capable of paying hundreds of Euros / Dollars 
> for achieving this goal every year.
> 
> Greetings
> 
> Marc

I am also a StartCom's SSL & S/MIME certificate user. The only problem for me 
is that I must re-config nginx. S/MIME have a lot of alternatives for free. 
Code Signing may only works on Windows but Microsoft seems like don't care 
about this because CNNIC is still trusted.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Nick Lamb]

On Friday, 21 October 2016 11:48:21 UTC+1, marc@gmail.com  wrote:
> Just the opinion of a user who is securing services, websites and his mails 
> with certificates but is not capable of paying hundreds of Euros / Dollars 
> for achieving this goal every year.

This is the "too big to fail" argument and I think we've addressed why that's 
not acceptable previously.

For DV TLS certificates, Let's Encrypt will be an admirable replacement for 
StartCom as far as most subscribers are concerned. There will inevitably be 
scenarios where StartCom were able to offer cheap or free certificates that 
aren't possible with Let's Encrypt because their validation strategy is 
different, but I think the addition of IDNs this week means Let's Encrypt now 
covers the vast majority of normal scenarios.

The pressure of "competing" with Let's Encrypt means Comodo and at least one 
other major CA (I want to say Symantec?) also now have offers which may be 
applicable for some subscribers. Comodo, through cPanel, gives away 
certificates to many people using bulk hosting, and the other CA has a deal 
with ISPs where free certificates are a loss leader to drive potential 
customers into an upsell - ie DV certificates are free, but you're gently 
encouraged to pay them for OV or EV instead.

So, that leaves S/MIME and Code Signing. Code Signing is no longer really 
Mozilla's concern as I understand it, they deprecated the Code Signing trust 
bits in their store. For S/MIME certificates I believe there are other options 
out there, which are either free or very affordable but I don't use S/MIME 
certificates so I might be wrong.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[marc . reitz]

Am Freitag, 21. Oktober 2016 03:59:08 UTC+2 schrieb Percy:
> Kathleen,
> As most users affected by this decision are Chinese, will you be able to make 
> the blog post available in Chinese on the security blog as well? You can ask 
> the Chinese firefox community or me to translate. 
Hi,

only the distrust of Wosign affects mostly chinese Users.

The distrust of StartCom affects individuals, non profit organizations and 
small companies worldwirde. StartCom was the only CA where these people and 
groups could get ov,dv,s/mime and code signing certificates for a reasonable 
price. Of course the incidents needed clarification and ofcourse actions are to 
be taken to prevent such behaviour in future. But Gerv stated that the main 
reasons for the harsh punishment are the lies and deceptions. The responsible 
person is no longer in charge, StartCom has to pay a lot of money to make the 
changes required by Mozilla. This is OK and fine from the view of a customer / 
user.

But with distrusting StartCom roots Mozilla isn't increasing security for their 
users and the web, Mozilla will decreasing the security.

A lot of people which have secured their services and code will lose this 
possibility. From the view of a user not really understandable.


Just the opinion of a user who is securing services, websites and his mails 
with certificates but is not capable of paying hundreds of Euros / Dollars for 
achieving this goal every year.

Greetings

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

Re: Remediation Plan for WoSign and StartCom

[Kathleen Wilson]

On Thursday, October 20, 2016 at 6:59:08 PM UTC-7, Percy wrote:
> Kathleen,
> As most users affected by this decision are Chinese, will you be able to make 
> the blog post available in Chinese on the security blog as well? You can ask 
> the Chinese firefox community or me to translate. 
> 
> As I stated earlier, there are almost no news of the distrust of 
> WoSign/StartCom on the Chinese Internet and WoSign/StartCom has not posted 
> anything related to this. I believe it's paramount to prepare Chinese website 
> owners for the phasing out of the affected roots.

Noted. I will look into how to get it translated into Chinese and how to make 
that version available as well.

Thanks,
Kathleen

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

Re: Remediation Plan for WoSign and StartCom

[Percy]

Kathleen,
As most users affected by this decision are Chinese, will you be able to make 
the blog post available in Chinese on the security blog as well? You can ask 
the Chinese firefox community or me to translate. 

As I stated earlier, there are almost no news of the distrust of 
WoSign/StartCom on the Chinese Internet and WoSign/StartCom has not posted 
anything related to this. I believe it's paramount to prepare Chinese website 
owners for the phasing out of the affected roots.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Kathleen Wilson]

All,

I have filed the following two bugs.

WoSign Action Items:
https://bugzilla.mozilla.org/show_bug.cgi?id=1311824 

StartCom Action Items:
https://bugzilla.mozilla.org/show_bug.cgi?id=1311832

I will work on a security blog that will probably get posted early next week. 
It will point to these two bugs, and list the actions Mozilla plans to take.

As we have been discussing, Mozilla plans to take the following actions:

1) Distrust certificates with a notBefore date after October 21, 2016 which 
chain up to the following affected roots. If additional back-dating is 
discovered (by any means) to circumvent this control, then Mozilla will 
immediately and permanently revoke trust in the affected roots.
a) This change will go into the Firefox 51 release train.
b) The code will use the following Subject Distinguished Names to identify the 
root certificates, so that the control will also apply to cross-certificates of 
these roots.
i) CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN 
ii) CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN 
iii) CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, 
C=CN 
iv) CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN 
v) CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, 
O=StartCom Ltd., C=IL 
vi) CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL 

2) Add the previously identified backdated SHA-1 certificates chaining up to 
these affected roots to OneCRL.

3) No longer accept audits carried out by Ernst & Young Hong Kong.

4) Remove these affected root certificates from Mozilla’s root store at some 
point in the future. If the CA's new root certificates are accepted for 
inclusion, then Mozilla may coordinate the removal date with the CA’s plans to 
migrate their customers to the new root certificates. Otherwise, Mozilla may 
choose to remove them at any point after March 2017.

5) Mozilla reserves the right to take further or alternative action.


This discussion is still open, and I will still continue to appreciate your 
input on this topic.

Thanks,
Kathleen


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

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 19/10/16 15:13, okaphone.elektron...@gmail.com wrote:
> Perhaps "haste" is not what you want here. How about "urgency"?

I was using it in the sense of the English phrase "more haste, less speed":
http://dictionary.cambridge.org/dictionary/english/more-haste-less-speed

But yes, urgency is fine.

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

Re: Remediation Plan for WoSign and StartCom

[Kathleen Wilson]

On Wednesday, October 19, 2016 at 3:13:50 PM UTC-7, okaphone.e...@gmail.com 
wrote:
> Perhaps "haste" is not what you want here. How about "urgency"?
> 

Yep. Changed in the wiki page.

Thanks,
Kathleen

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

Re: Remediation Plan for WoSign and StartCom

[okaphone . elektronika]

Perhaps "haste" is not what you want here. How about "urgency"?

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

Re: Remediation Plan for WoSign and StartCom

[Kathleen Wilson]

On Wednesday, October 19, 2016 at 11:50:55 AM UTC-7, Gervase Markham wrote:
> 
> Today at the CAB Forum I outlined some of Mozilla's thinking on how we
> rate the severity of incidents. It might be helpful to reproduce that
> here. This is what I said:
> 

Thanks, Gerv!

I added that text to the wiki page:
https://wiki.mozilla.org/CA:MaintenanceAndEnforcement#Potential_Problems.2C_Prevention.2C_Response

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

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 19/10/16 11:35, longol...@gmail.com wrote:
> Hey Kathleen, hey list,
> 
> I really don't get why Mozilla is pushing so hard on the Chinese and
> at the same time let others get away. For example the Comodo case
> from today. Isn't that a much worse incident than what has happened
> here. 

Today at the CAB Forum I outlined some of Mozilla's thinking on how we
rate the severity of incidents. It might be helpful to reproduce that
here. This is what I said:


Many CAs may have been looking at Mozilla’s actions a little nervously,
conscious that they have had an issue or two in the past, and wondering
where the tipping point is which might lead to the production of a
WoSign-style “issue list”, and if they will ever hit it. It might
therefore be worth noting that while CA incidents have differing levels
of seriousness, there are some components which every CA should be able
to avoid which are red flags for Mozilla in terms of a continued trust
relationship, and which would lead to an investigation. They are:

* Deliberate violation of Mozilla or other applicable policy
* Lying or deception

Mozilla will also assess how concerned we are about an issue in part
based on how the CA reacts to that issue, and previous ones. In incident
response, Mozilla is looking for the following factors:

* A CA takes responsibility for their own actions.
* Incidents are taken with an appropriate level of seriousness.
* Incidents are handled with haste.
* Root cause analysis is performed.
* Any questions posed, by anyone, are answered quickly and in detail.
* A reasonably-detailed report is made public on what happened, why,
  and how things have changed to make sure it won’t happen again.

The recent issue experienced by Comodo was a good (albeit small) example
of this being done.

If people have further questions about this, they should feel free to
ask, either now or privately.


> People were able to issue certs for other people domains. When
> I read the WoSign answer to the current case
> (https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf)
> I personally felt, that they completely understood the seriousness of
> the situation. 

If you compare WoSign's responses over the entire period of
investigation to the criteria above, I hope you can see how the two
incidents are not comparable. In particular, they engaged in deliberate
violations of Mozilla policy and lied to cover it up.

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

Re: Remediation Plan for WoSign and StartCom

[Ryan Hurst]

On Wednesday, October 19, 2016 at 12:58:49 AM UTC-7, Kurt Roeckx wrote:
> I at least have some concerns about the current gossip draft and talked 
> a little to dkg about this. I should probably bring this up on the trans 
> list.
> 

Please do, we would like to see this brought to closure soon and we want to 
make sure all feedback is considered.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Tom Ritter]

On 19 October 2016 at 02:58, Kurt Roeckx  wrote:
> On 2016-10-19 01:37, Rob Stradling wrote:
>>
>> On 18/10/16 23:49, Gervase Markham wrote:
>>>
>>> On 18/10/16 15:42, Ryan Hurst wrote:

 I do not understand the desire to require StartCom / WoSign to not
 utilize their own logs as part of the associated quorum policy.
>>>
>>>
>>> My original logic was that it could be seen that the log owner is
>>> trustworthy. However, you are right that CT does not require this.
>>
>>
>> A log operator could offer a split view of their log, and this might go
>> undetected.  That's why we need CT gossip to exist.
>
>
> I at least have some concerns about the current gossip draft and talked a
> little to dkg about this. I should probably bring this up on the trans list.


Please do!  For those not aware, the CT Gossip draft is in 'pre-final
review' in the sense that (we think) we're pretty much done but need
people to finally read it now.  Draft is at:
https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/


Because we're talking about a CA which used their private keys to get
around baseline requirements/prohibitions by backdating, I would not
be comfortable trusting them with operating a log where they could do
the same thing. The addition of the Google log prevents this to some
degree. So I would prefer the requirement either be 'one google and
one non-google/non-self-operated log' or just 'one google log'.

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

Re: Remediation Plan for WoSign and StartCom

[Kurt Roeckx]

On 2016-10-19 01:37, Rob Stradling wrote:

On 18/10/16 23:49, Gervase Markham wrote:

On 18/10/16 15:42, Ryan Hurst wrote:

I do not understand the desire to require StartCom / WoSign to not
utilize their own logs as part of the associated quorum policy.


My original logic was that it could be seen that the log owner is
trustworthy. However, you are right that CT does not require this.


A log operator could offer a split view of their log, and this might go
undetected.  That's why we need CT gossip to exist.


I at least have some concerns about the current gossip draft and talked 
a little to dkg about this. I should probably bring this up on the trans 
list.



Kurt

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

Re: Remediation Plan for WoSign and StartCom

[Ryan Hurst]

It is true, that without gossip, CT is dependent on browsers monitoring the log 
ecosystem, this is one reason why in the Chrome policy the one Google log is 
required.

I would argue, with the monitoring Google does and the one Google log policy 
that this risk is mitigated sufficiently, even without gossip.

Gossip is needed, as is Firefox's own implementation of CT verification, which 
is actively in the works, but given the above mitigations I still believe this 
extra requirement is not necessary.

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

Re: Remediation Plan for WoSign and StartCom

[Adrian R.]

Kurt Roeckx  wrote:

> Since the previous audit wasn't one that covered a whole year, I
> expect the new audit to start where the previous one stopped and
> have it a year from that point.

this might be more of a question for cabforum but why do audits have to be 
non-overlapping?


i would think that a new audit would at least look at a random small period 
from the last audit (let's say one month, either at middle or end or around 
important event dates, like the SHA1 issuance ending on Dec 31st) and re-audit 
again that small period just to check that the previous auditor didn't miss any 
glaring issues.

If the audit report must cover a non-overlapping time period then have a 
separate section in the report for this small overlapped period and report it 
as such but at least it provides some checks that the previous auditor didn't 
miss  obvious stuff.


This should be especially true (IMHO) for the case of E HK where Gerv said 
for CNNIC:

"I think the fairest thing is to allow them to proceed with the inclusion
application, get them in the queue, and follow through all the steps,
expecting that by the time they get to the end, their new audit (by
another auditor) will be completed. Assuming it is good, we can include
them."

I'm ok with that but i'd like to also see that the new auditor looks at (and 
reports on) a random sample time period that's covered by the the previous 
audit.



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

Re: Remediation Plan for WoSign and StartCom

[Andrew Ayer]

On Tue, 18 Oct 2016 15:49:26 -0700
Gervase Markham  wrote:

> On 18/10/16 15:42, Ryan Hurst wrote:
> > I do not understand the desire to require StartCom / WoSign to not
> > utilize their own logs as part of the associated quorum policy.
> 
> My original logic was that it could be seen that the log owner is
> trustworthy. However, you are right that CT does not require this.

This is true only as long as TLS clients are auditing logs for correct
operation by demanding inclusion proofs for SCTs (or alternatively,
gossiping them to someone who will).  Otherwise, CT logs are just
another trusted third party and could easily claim a certificate is
logged when it really isn't.  What are Mozilla's plans for implementing
inclusion proof checking or SCT gossip (not just SCT signature
validation) in Firefox?

That said,  I think a much more important question is not whether
StartCom/WoSign can be trusted to operate a CT log, but whether they
can be trusted to operate a CA.

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

Re: Remediation Plan for WoSign and StartCom

[Rob Stradling]

On 18/10/16 23:49, Gervase Markham wrote:
> On 18/10/16 15:42, Ryan Hurst wrote:
>> I do not understand the desire to require StartCom / WoSign to not
>> utilize their own logs as part of the associated quorum policy.
> 
> My original logic was that it could be seen that the log owner is
> trustworthy. However, you are right that CT does not require this.

A log operator could offer a split view of their log, and this might go
undetected.  That's why we need CT gossip to exist.

Is that a concern here?

-- 
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: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 18/10/16 16:04, Han Yuwei wrote:
> For the CT support, is there any plan to implement it into effect in
> Firefox? And if implemented, what would happen if server's
> certificate don't have enough SCTs?

The mechanism is being implemented. When it's closer to being
implemented, there will be a discussion of the policy (what logs to
trust, how many SCTs to require etc.)

Gerv


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

Re: Remediation Plan for WoSign and StartCom

[Han Yuwei]

在 2016年10月19日星期三 UTC+8上午6:42:18，Ryan Hurst写道：
> All,
> 
> I do not understand the desire to require StartCom / WoSign to not utilize 
> their own logs as part of the associated quorum policy. 
> 
> Certificate Transparency's idempotency is for not dependent on the practices 
> of the operator. By requiring the use of a third-party log (in this case 
> Google's) and requiring that the logs are public,  CT "works" as expected.
> 
> There appears to be an argument being made that this restriction comes from 
> the fact that Firefox does not yet have CT support, I would argue that this 
> is not material. My justification for this argument is that today, Firefox 
> depends on SafeBrowsing, this is a Google-provided service and Firefox uses 
> it to protect users from malicious sites.
> 
> This is not significantly different from the way Chrome (and others) rely on 
> the wonderful Mozilla Trusted Root Program.
> 
> Based on this it seems reasonable to allow them to use the same logs they use 
> for EV.
> 
> Ryan

Could you explain what "idempotency" means? Because I am not a native English 
speaker and I can't lookup a good meaning about this word.

For the StartCom/Wosign's log, I think maybe Mozilla's logic is that they are 
not trustworthy when ther are appling CAs, so their CT logs can't be 
trusted.But I don't think that's right because there's a Google log also 
monitoring this.What I am interested in is why some CT log operator rejected 
the including request from StartCom. Performance is not persuading reason.

For the CT support, is there any plan to implement it into effect in Firefox? 
And if implemented, what would happen if server's certificate don't have enough 
SCTs?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 18/10/16 15:42, Ryan Hurst wrote:
> I do not understand the desire to require StartCom / WoSign to not
> utilize their own logs as part of the associated quorum policy.

My original logic was that it could be seen that the log owner is
trustworthy. However, you are right that CT does not require this.

If the consensus of the group is that it's OK for StartCom/WoSign to run
their own CT servers for the 2nd log, we can drop that part of the
requirement.

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

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 18/10/16 14:33, Ryan Sleevi wrote:
> I think there's some confusion there. CNNIC's audits "expire" on Feb
> "29" 2017 (I say "29" because of ambiguity on "1 year"). That is,
> within 3 months of Feb "29", 2017, CNNIC would be expected to provide
> a new audit, which covers February 29, 2016 (the end of the previous
> audit period) until February "29", 2017. This would then be delivered
> to Mozilla within 3 months - May 29, 2017.

Ah, OK. Thanks :-)

Gerv

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

Re: Remediation Plan for WoSign and StartCom

[Ryan Hurst]

All,

I do not understand the desire to require StartCom / WoSign to not utilize 
their own logs as part of the associated quorum policy. 

Certificate Transparency's idempotency is for not dependent on the practices of 
the operator. By requiring the use of a third-party log (in this case Google's) 
and requiring that the logs are public,  CT "works" as expected.

There appears to be an argument being made that this restriction comes from the 
fact that Firefox does not yet have CT support, I would argue that this is not 
material. My justification for this argument is that today, Firefox depends on 
SafeBrowsing, this is a Google-provided service and Firefox uses it to protect 
users from malicious sites.

This is not significantly different from the way Chrome (and others) rely on 
the wonderful Mozilla Trusted Root Program.

Based on this it seems reasonable to allow them to use the same logs they use 
for EV.

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

Re: Remediation Plan for WoSign and StartCom

[Kurt Roeckx]

On Tue, Oct 18, 2016 at 01:35:59PM -0700, Gervase Markham wrote:
> On 18/10/16 12:46, Kurt Roeckx wrote:
> > Are you saying you're expecting an audit report from November 2015
> > to November 2016, and so have the period from November to March
> > covered twice?
> 
> There seems to be a persistent misunderstanding here.
> 
> https://cert.webtrust.org/SealFile?seal=2092=pdf
> https://cert.webtrust.org/SealFile?seal=2091=pdf
> both say that the period when the auditors were examining CNNIC was
> November 2, 2015 to February 29, 2016. Obviously, it then took them time
> to write up their report and get it published and so on, but that's not
> relevant for this.

It does not say when the audit was performed. It says which period
of activity has been audited. Some reports also indicate when they
did the audit, but that's really not important.

Somewhere between 2016-03-01 and 2016-04-05 E went to CNNIC
to audit them for what CNNIC did between 2015-11-02 and 2016-02-29.

If they have an audit that covers a year now, I expect the period to
be covered from 2016-03-01 to 2017-02-28. The auditor would then
have 3 months to perform the audit of that period and write a new
report. The new report (according to the BR rules) should be in by
2017-05-28 (or 2017-05-31, depending on how you want to count
months.) But I think Mozilla starts to count the 3 months from
date of the last report, so they would actually have until
2016-07-05.


Kurt

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

Re: Remediation Plan for WoSign and StartCom

[Peter Bowen]

On Tue, Oct 18, 2016 at 2:33 PM, Ryan Sleevi  wrote:
>
> I think there's some confusion there. CNNIC's audits "expire" on Feb "29" 
> 2017 (I say "29" because of ambiguity on "1 year"). That is, within 3 months 
> of Feb "29", 2017, CNNIC would be expected to provide a new audit, which 
> covers February 29, 2016 (the end of the previous audit period) until 
> February "29", 2017. This would then be delivered to Mozilla within 3 months 
> - May 29, 2017.
>
> I'm not sure I understand your remark "last a year" - merely, there must be 
> an unbroken sequence of audits. The current sequence ends February 29, 2016. 
> The next sequence must not exceed a year, and must be delivered within 3 
> months of the full year period expiring.

There is also a requirement that each audit period may not be less than 60 days.

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

Re: Remediation Plan for WoSign and StartCom

[Ryan Sleevi]

On Tuesday, October 18, 2016 at 1:36:37 PM UTC-7, Gervase Markham wrote:
> On 18/10/16 12:46, Kurt Roeckx wrote:
> > Are you saying you're expecting an audit report from November 2015
> > to November 2016, and so have the period from November to March
> > covered twice?
> 
> There seems to be a persistent misunderstanding here.
> 
> https://cert.webtrust.org/SealFile?seal=2092=pdf
> https://cert.webtrust.org/SealFile?seal=2091=pdf
> both say that the period when the auditors were examining CNNIC was
> November 2, 2015 to February 29, 2016. Obviously, it then took them time
> to write up their report and get it published and so on, but that's not
> relevant for this.
> 
> Therefore, as WebTrust audits last a year, I would expect CNNIC to begin
> being re-examined on or about November 2nd 2016, one year after the
> previous examination started.
> 
> Unless I've misunderstood what that date range means. If it means the
> period of audit validity, then the audits have already expired, so we
> shouldn't rely on them. So it can't be that, otherwise they wouldn't
> have submitted them.
> 
> Gerv

Gerv,

I think there's some confusion there. CNNIC's audits "expire" on Feb "29" 2017 
(I say "29" because of ambiguity on "1 year"). That is, within 3 months of Feb 
"29", 2017, CNNIC would be expected to provide a new audit, which covers 
February 29, 2016 (the end of the previous audit period) until February "29", 
2017. This would then be delivered to Mozilla within 3 months - May 29, 2017.

I'm not sure I understand your remark "last a year" - merely, there must be an 
unbroken sequence of audits. The current sequence ends February 29, 2016. The 
next sequence must not exceed a year, and must be delivered within 3 months of 
the full year period expiring.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 18/10/16 12:46, Kurt Roeckx wrote:
> Are you saying you're expecting an audit report from November 2015
> to November 2016, and so have the period from November to March
> covered twice?

There seems to be a persistent misunderstanding here.

https://cert.webtrust.org/SealFile?seal=2092=pdf
https://cert.webtrust.org/SealFile?seal=2091=pdf
both say that the period when the auditors were examining CNNIC was
November 2, 2015 to February 29, 2016. Obviously, it then took them time
to write up their report and get it published and so on, but that's not
relevant for this.

Therefore, as WebTrust audits last a year, I would expect CNNIC to begin
being re-examined on or about November 2nd 2016, one year after the
previous examination started.

Unless I've misunderstood what that date range means. If it means the
period of audit validity, then the audits have already expired, so we
shouldn't rely on them. So it can't be that, otherwise they wouldn't
have submitted them.

Gerv

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

Re: Remediation Plan for WoSign and StartCom

[Kurt Roeckx]

On Tue, Oct 18, 2016 at 10:02:00AM -0700, Gervase Markham wrote:
> On 18/10/16 09:03, Kurt Roeckx wrote:
> > You said the period was until February 29, 2016. I assume the next
> > period starts on March 1, 2016 and is for 1 year. I don't expect it to
> > from from March to November, it would be an 8 month period.
> 
> Surely if audits last one year, one would be auditing the CA at the same
> time each year? And the last audit was Nov -> Feb. That's certainly what
> my neighbour here in the CAB Forum meeting room is suggesting is true.

Are you saying you're expecting an audit report from November 2015
to November 2016, and so have the period from November to March
covered twice?

Since the previous audit wasn't one that covered a whole year, I
expect the new audit to start where the previous one stopped and
have it a year from that point.


Kurt

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

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 18/10/16 06:02, Peter Bowen wrote:
> I think making it clear which entries in certdata.txt have additional
> constraints would be very helpful. 

Here's a start:
https://wiki.mozilla.org/CA:Root_Store_Trust_Mods

I believe the ANSSI root has now been removed and so CNNIC is the only
one (leaving aside WoSign/StartCom) which should appear on the list. Am
I right?

Gerv

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

Re: Remediation Plan for WoSign and StartCom

[okaphone . elektronika]

Measure with a micrometer, mark with chalk and cut with an axe... it's the best 
you can do.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

Hi Peter,

On 18/10/16 06:02, Peter Bowen wrote:
> I think making it clear which entries in certdata.txt have additional
> constraints would be very helpful.  Is it maybe possible to do so by
> adding new attributes to the NSS_TRUST object instead of simply
> putting it on a webpage?  That way it is in the same place and is
> machine readable.  Even if the attribute are not processed when
> creating libckfw, others can use them.

We could have a flag saying "this root is special", so people could
detect when new "special" roots had appeared so they could check the
wiki page, but I think it would be hard to programmatically encode the
restrictions such that they are machine-readable, because there are such
a wide variety of restrictions which one could imagine making.

Gerv


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

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 18/10/16 09:03, Kurt Roeckx wrote:
> You said the period was until February 29, 2016. I assume the next
> period starts on March 1, 2016 and is for 1 year. I don't expect it to
> from from March to November, it would be an 8 month period.

Surely if audits last one year, one would be auditing the CA at the same
time each year? And the last audit was Nov -> Feb. That's certainly what
my neighbour here in the CAB Forum meeting room is suggesting is true.

Gerv


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

Re: Remediation Plan for WoSign and StartCom

[Kurt Roeckx]

On 2016-10-18 17:26, Gervase Markham wrote:

On 18/10/16 07:17, Kurt Roeckx wrote:

On 2016-10-18 14:51, Gervase Markham wrote:


The audit report CNNIC has submitted covers the period from November 2,
2015 to February 29, 2016. Therefore, we would expect them to be
starting the process of getting another yearly audit in about 2 weeks
anyway, although it won't be done until next year.


If they now are on a yearly audit, I would expect the audit to start
somewhere in March 2017.


Help me understand how you get to that figure, given that their previous
audit started on November 2nd, 2015?


You said the period was until February 29, 2016. I assume the next 
period starts on March 1, 2016 and is for 1 year. I don't expect it to 
from from March to November, it would be an 8 month period.



Kurt

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

Re: Remediation Plan for WoSign and StartCom

[Han Yuwei]

在 2016年10月18日星期二 UTC+8下午10:38:07，Inigo Barreira写道：
> Hi all,
> 
> 
> I´ve been reading some emails that need clarification form both sides.
> 
> Firstly I´d like to remind, if I´m not wrong, that Kathleen proposed an 
> action plan for distrusting StartCom, which has been taken as the final 
> decission, but with a small option to regain the trust for StartCom in 
> Mozilla if we can make her recover the confidance in StartCom.
> 
> Two weeks ago, there was a meeting between StartCom and Mozilla that 
> everybody was aware and on friday of that week, StartCom published the 
> outcome of that meeting, having this last week to set specific dates and 
> tasks for making it real. The surprise came when Kathleen droped the 
> email with the sanctions plan. In any case, StartCom published on 
> friday, at 10:30 CET, a remediation plan (it was already done by 
> thursday that week, but it´s difficult to coordinate with so many hours 
> of difference) on StartCom´s website. Surprisingly, there hasn´t been 
> any comment, in this mailing list, to that message (I even had to ask 
> Gerv if I posted correctly) in which there is more detailed information 
> on the next steps to be done.
> 
> Here´s the link again: 
> https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf
> 
> So, regarding the situation of StartCom I think that some people has 
> lost what happened and it´s considering Wosign and Startcom the same.
> 
> Let´s focus on the 3 issues for which StartCom has been proposed to a 
> sanction (hopefully we can change that), and these are:
> 
> 1.- Bad coding of a new solution called startencrypt, which basically 
> was barely used and not affected StartCom
> 
> 2.- Issues with serial numbers, not able to generate serial numbers 
> starting with zero and the reuse of some. Those were bugs fixed on time 
> and were because of a software and hardware upgrading as explained 
> before, due to the acquisiton of Wosign because the PKI was cloned. This 
> is also indicated in the plan
> 
> 3.- Backdating 2 certs for Tyro. I think this is the issue that has made 
> Mozilla to include Startcom in the equation and fine it. But as also 
> explained this is not a security issue (same as other SHA1 certs 
> legitimacy issued on time) but a bad practice
> 
> In any case, this mailing list is called mozilla.dev._security_.policy, 
> and for these 3 issues, imho there´s no security problem. We can talk 
> about how things have been done, there´s been some cheating, hidden 
> info, bad practices, etc. That´s totally true but as Mozilla always 
> remembers about their users base, these have not been affected by any 
> security problem. Recently some emails remembered the comodogate, the 
> diginotar, etc. back in 2011, and those were different because the 
> attacker had control over the issuance process and some certificates 
> were issued without knowledge and/or consent of the CA, and this is not 
> what has happened to StartCom in which all the cryptographic material 
> was under control of the companies (including wosign)
> 
> Of course, there has been bad decissions, bad practices and procedures, 
> etc. but if you see the plan, there you can find all the actions that 
> are taking place to avoid this situation again.
> 
> In any case, taking as examples the recent issues affecting Comodo and 
> Globalsign (I´m just mention these because have been published at the 
> same time) it makes me feel with a strange feeling. Comodo issue was an 
> unintentionally or unauthorized issuance of a certificate for a ".sb", 
> can´t remember now, (could be compared to the 2 backdated certificates) 
> and globalsign revoked an intermediate certificate and later un-revoked 
> it (I don´t know if this is allowed in the RC 6960, but in ETSI once a 
> certificate is revoked, you can´t reisntate it status). Again, those are 
> examples and the only concern for me, it´s that the bar in the case of 
> StartCom is not the same in the case of others, again, taking into 
> account what has mentioned above and the control over the keys has not 
> been lost. The price for StartCom is too high.
> 
> For some specific questions that are around this issue, for example, 
> those related to communicate the end users, I have to say that:
> 
> - Mozilla runs a root program on a voluntary basis. So any CA may join, 
> stay or leave on its own discretion. If the CA decides to join, then it 
> shall follow the root program requirements
> 
> - Every CA must have its own procedures and practices for doing its 
> business, independently if decides to join a specific root program or not
> 
> - Mozilla and other root programs can impose its rules to the CAs that 
> voluntary decide to adhere to the programs but can´t have any decission 
> on what a CA decides or not related to its business. Of course comments, 
> suggestions, etc. are welcome in the comunity
> 
> - StartCom has made publicly this report in which they explain what are 
> going to 

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

Hi Inigo,

On 18/10/16 07:34, Inigo Barreira wrote:
> So, regarding the situation of StartCom I think that some people has
> lost what happened and it´s considering Wosign and Startcom the same.

Kathleen may also respond, but my understanding is that (based on her
consideration of the arguments put forth in this forum) her decision was
that the right approach was to treat WoSign and StartCom in mostly the
same way, based on the fact of their shared ownership, management etc.
over the past 10 months or so. As you know, this is not entirely how I
saw it, but I was at pains to make it clear to you that I was not the
final decision-maker, and I respect the decision which has been made.

> Let´s focus on the 3 issues for which StartCom has been proposed to a
> sanction (hopefully we can change that), and these are:

This line of argument starts from the position that StartCom and WoSign
can be treated separately. But Kathleen has decided that this is not so.

In addition, the three issues you list are not the only issues with
StartCom - while I have not compiled a formal list like the one for
WoSign, Ryan does point out several more.

> In any case, this mailing list is called mozilla.dev._security_.policy,

It's called that because when I asked for it to be created, I thought it
was logically a sub-part of mozilla.dev.security, which was the existing
discussion forum for these topics. You should not read too much into the
group name.

The issue of who is trusted in Mozilla's root program is an issue of
trust, which includes but is not limited to whether a CA is behaving
securely.

> In any case, taking as examples the recent issues affecting Comodo and
> Globalsign (I´m just mention these because have been published at the
> same time) it makes me feel with a strange feeling. Comodo issue was an
> unintentionally or unauthorized issuance of a certificate for a ".sb",
> can´t remember now, (could be compared to the 2 backdated certificates)
> and globalsign revoked an intermediate certificate and later un-revoked
> it (I don´t know if this is allowed in the RC 6960, but in ETSI once a
> certificate is revoked, you can´t reisntate it status). 

I don't think it's helpful to go into a detailed comparison of CAs and
issues and rating their relative severity, but I would note that there
are two components to how Mozilla views an incident - firstly what
happened, and secondly how the CA reacts. (I will say more about this in
Browser News at the CAB Forum tomorrow.)

> In any case, StartCom follows the google rule of one google and one
> non-google log (which of course this does not have to be the same rule
> in case of Mozilla but as Firefox does not support it, will be
> contradictory to have some other rules) and don´t understand the
> reasoning of not using the StartCom one, when ALL of them have to pass
> the same requirements.

To fulfil the non-Google log server requirement, it is not necessary
that you use a log server which is included in Chrome. Therefore there
is no formal uptime requirement (although clearly you'd want a decent
uptime as you were using it). The only requirement is that it not be
controlled by you.

> Finally, I´d like to ask Mozilla if the remediation plan released by
> StartCom last friday can make Mozilla regain the confidence and trust in
> StartCom with the current roots.

This is a question for Kathleen but, as you know, her current decision
is to require new roots.

> I´d also like to know if we are forced to set up new roots to be
> admitted because that will make us need some more time and in any case,
> need to know the auditor Mozilla is suggesting to contact them asap for
> arranging agendas.

For WebTrust and other normal CA audits, Mozilla has no requirements on
who the auditor should be other than it should not be E HK. You may
choose.

For the security auditing of your infrastructure, you may suggest a firm
but Mozilla retains the right to approve your choice or ask you to make
another. However, I suspect you are not at that stage yet?

> information to provide to the root programs, but it will be good to have
> also another one listing the issues and the penalties. 

I don't think it's either possible to helpful to make a list of all the
possible forms of CA mistake and the penalty to be applied in each case.
This would only work if it happened a lot. With it being so relatively
uncommon, I think every situation must be taken on its particular
circumstances. This is a benefit to you, because it allows for Mozilla
discretion where there are mitigating circumstances.

Gerv

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

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 18/10/16 07:17, Kurt Roeckx wrote:
> On 2016-10-18 14:51, Gervase Markham wrote:
>>
>> The audit report CNNIC has submitted covers the period from November 2,
>> 2015 to February 29, 2016. Therefore, we would expect them to be
>> starting the process of getting another yearly audit in about 2 weeks
>> anyway, although it won't be done until next year.
> 
> If they now are on a yearly audit, I would expect the audit to start
> somewhere in March 2017.

Help me understand how you get to that figure, given that their previous
audit started on November 2nd, 2015?

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

Re: Remediation Plan for WoSign and StartCom

[Inigo Barreira]

Hi all,


I´ve been reading some emails that need clarification form both sides.

Firstly I´d like to remind, if I´m not wrong, that Kathleen proposed an 
action plan for distrusting StartCom, which has been taken as the final 
decission, but with a small option to regain the trust for StartCom in 
Mozilla if we can make her recover the confidance in StartCom.


Two weeks ago, there was a meeting between StartCom and Mozilla that 
everybody was aware and on friday of that week, StartCom published the 
outcome of that meeting, having this last week to set specific dates and 
tasks for making it real. The surprise came when Kathleen droped the 
email with the sanctions plan. In any case, StartCom published on 
friday, at 10:30 CET, a remediation plan (it was already done by 
thursday that week, but it´s difficult to coordinate with so many hours 
of difference) on StartCom´s website. Surprisingly, there hasn´t been 
any comment, in this mailing list, to that message (I even had to ask 
Gerv if I posted correctly) in which there is more detailed information 
on the next steps to be done.


Here´s the link again: 
https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf


So, regarding the situation of StartCom I think that some people has 
lost what happened and it´s considering Wosign and Startcom the same.


Let´s focus on the 3 issues for which StartCom has been proposed to a 
sanction (hopefully we can change that), and these are:


1.- Bad coding of a new solution called startencrypt, which basically 
was barely used and not affected StartCom


2.- Issues with serial numbers, not able to generate serial numbers 
starting with zero and the reuse of some. Those were bugs fixed on time 
and were because of a software and hardware upgrading as explained 
before, due to the acquisiton of Wosign because the PKI was cloned. This 
is also indicated in the plan


3.- Backdating 2 certs for Tyro. I think this is the issue that has made 
Mozilla to include Startcom in the equation and fine it. But as also 
explained this is not a security issue (same as other SHA1 certs 
legitimacy issued on time) but a bad practice


In any case, this mailing list is called mozilla.dev._security_.policy, 
and for these 3 issues, imho there´s no security problem. We can talk 
about how things have been done, there´s been some cheating, hidden 
info, bad practices, etc. That´s totally true but as Mozilla always 
remembers about their users base, these have not been affected by any 
security problem. Recently some emails remembered the comodogate, the 
diginotar, etc. back in 2011, and those were different because the 
attacker had control over the issuance process and some certificates 
were issued without knowledge and/or consent of the CA, and this is not 
what has happened to StartCom in which all the cryptographic material 
was under control of the companies (including wosign)


Of course, there has been bad decissions, bad practices and procedures, 
etc. but if you see the plan, there you can find all the actions that 
are taking place to avoid this situation again.


In any case, taking as examples the recent issues affecting Comodo and 
Globalsign (I´m just mention these because have been published at the 
same time) it makes me feel with a strange feeling. Comodo issue was an 
unintentionally or unauthorized issuance of a certificate for a ".sb", 
can´t remember now, (could be compared to the 2 backdated certificates) 
and globalsign revoked an intermediate certificate and later un-revoked 
it (I don´t know if this is allowed in the RC 6960, but in ETSI once a 
certificate is revoked, you can´t reisntate it status). Again, those are 
examples and the only concern for me, it´s that the bar in the case of 
StartCom is not the same in the case of others, again, taking into 
account what has mentioned above and the control over the keys has not 
been lost. The price for StartCom is too high.


For some specific questions that are around this issue, for example, 
those related to communicate the end users, I have to say that:


- Mozilla runs a root program on a voluntary basis. So any CA may join, 
stay or leave on its own discretion. If the CA decides to join, then it 
shall follow the root program requirements


- Every CA must have its own procedures and practices for doing its 
business, independently if decides to join a specific root program or not


- Mozilla and other root programs can impose its rules to the CAs that 
voluntary decide to adhere to the programs but can´t have any decission 
on what a CA decides or not related to its business. Of course comments, 
suggestions, etc. are welcome in the comunity


- StartCom has made publicly this report in which they explain what are 
going to do, dates and tasks, for everybody to check out the ongoing 
tasks. I will indicate periodically how these tasks are going


- The decission on what/how/when to communicate whatever to the StartCom 
customers is a 

Re: Remediation Plan for WoSign and StartCom

[Kurt Roeckx]

On 2016-10-18 14:51, Gervase Markham wrote:


The audit report CNNIC has submitted covers the period from November 2,
2015 to February 29, 2016. Therefore, we would expect them to be
starting the process of getting another yearly audit in about 2 weeks
anyway, although it won't be done until next year.


If they now are on a yearly audit, I would expect the audit to start 
somewhere in March 2017.



Kurt

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

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 17/10/16 16:26, Kathleen Wilson wrote:
> ones who use NSS validation. I’m not sure what we can do about other
> consumers of the NSS root store, other than publish what we are doing
> and hope those folks read the news and update their version of their
> root store as they see appropriate for their use.

We cannot fix everyone else's code, but I think it would be reasonable
for us to produce and maintain a wiki page which complements
certdata.txt which gives all the other restrictions Mozilla recommends
on the roots therein.

> It will also impact CNNIC. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1177209#c13 So, does
> CNNIC's audit get grandfathered in? Or does CNNIC have to get audited
> by a different auditor before they can re-apply for full inclusion?

The audit report CNNIC has submitted covers the period from November 2,
2015 to February 29, 2016. Therefore, we would expect them to be
starting the process of getting another yearly audit in about 2 weeks
anyway, although it won't be done until next year.

I think the fairest thing is to allow them to proceed with the inclusion
application, get them in the queue, and follow through all the steps,
expecting that by the time they get to the end, their new audit (by
another auditor) will be completed. Assuming it is good, we can include
them.

> ~~ I think we need to add an action item regarding making sure that
> all of the code and systems used by the CA are well-designed and
> updated, and fully meet the CA/Browser Forum’s Baseline
> Requirements.

Well, we already require that they meet the Baseline Requirements, and
"updated" is covered by the Network Security Requirements which, for all
their flaws, are included by reference in the BRs. So that seems like a
no-op. And I don't know how to define "well-designed".

> Are there tests that we could require the CA to run/pass that would
> satisfy our concerns about quality of the code and systems?

Not really :-(

Gerv

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

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

Hi Ryan,

Kathleen has responded, but here are my two cents:

On 14/10/16 13:21, Ryan Sleevi wrote:
> It seems to accomplish this, you're willing to continue to trust that
> WoSign will not demonstrate any of the past behaviours it already
> demonstrated - such as backdating and misissuance, but not to issue
> new certificates. Is that correct?

It is not that are we willing to blindly trust them on this; it is that
we believe that in practice it will be impossible for them to backdate
lots of certs to get around the block without it being detected. Such
certs, of course, would need to be CT-less, although both CAs have
committed to full CT from now on, and both have loaded "every" cert
since a certain date into CT. If loads of CT-less older WoSign or
StartCom certs with long lifetimes started turning up on their customers
sites, it would be fairly obvious.

> As a consequence of this - which,
> to be fair, is not a problem of Mozilla's creation - there exists the
> ecosystem risk that in order to minimize any incompatibilities, these
> applications will need to continue to trust WoSign and StartCom for
> as long as other popular programs - such as Mozilla - do. 

Everyone needs to make their own trust decisions, which will be affected
by what decisions their code lets them make. A while ago, Mozilla was in
this sort of position, but we did engineering work and now the situation
is not so bad.

I don't think any platform would have size or code constraints on
implementing our notBefore solution. A whitelist may have problems, but
we aren't proposing we use one.

> impact. For example, fully distrusting these certificates in, say, 6
> months, would allow other players in the ecosystem to take
> appropriate steps and block these certificates, without having to
> suffer the first-mover/only-mover problem.

See Kathleen's response.

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

Re: Remediation Plan for WoSign and StartCom

[Nick Lamb]

On Tuesday, 18 October 2016 00:27:09 UTC+1, Kathleen Wilson  wrote:
> I’m not sure what I could reasonably require (and enforce) of the CA in 
> regards to communicating with their customers. 

As I understand it QiHoo 360 says they intend to co-operate in order to 
eventually get the new StartCom CA trusted. If they are unwilling to 
communicate with existing subscribers of both existing CAs effectively, it 
seems to me this is evidence of bad faith and excludes the possibility of the 
new CA being trusted by Mozilla (or in my opinion any right-thinking person).

So, essentially I'd argue that explaining Mozilla's decision to existing 
subscribers is a pre-requisite of any future trust for the new StartCom and 
Mozilla should emphasise that to QiHoo 360. The communication needn't walk 
through all Mozilla's findings, but it should clearly say what will happen (new 
certificates won't be trusted) and that QiHoo 360/ WoSign/ StartCom accept this 
as legitimate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Percy]

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

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

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

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

Indeed, your announcement about CNNIC was censored in China. In fact, I 
monitored and broke this news.  However, WoSign is not a government agency and 
the announcement shouldn't be censored. I suggest Mozilla at least publish a 
blog post in Chinese about this, but preferably mandating WoSign/StartCom to 
publish on its official sites to inform users about its bad security practices.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Eric Mill]

Oh, I read too quickly and saw it as a list of certificates whose
expiration dates were within each month. In retrospect, that was not the
most likely way the numbers would be distributed -- apologies for causing
confusion.

On Sat, Oct 15, 2016 at 6:20 PM, Kurt Roeckx  wrote:

> On Sat, Oct 15, 2016 at 06:07:50PM -0400, Eric Mill wrote:
> > For the convenience of the thread -- assuming that a 1-year-oriented
> policy
> > covered the certs up to and including those listed as 2017-10-01, then
> > summing up Kurt's numbers:
> >
> > * Certs expiring by Oct 2017: 2,088,329
> > * Certs expiring after Oct 2017: 1,419,593
>
> I'm not sure where you get the numbers from, maybe they weren't
> clear.  But by 2017-10-01 the number of expired certifictes would
> be 196100 - 138156 = 57944
>
>
> Kurt
>
>


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

Re: Remediation Plan for WoSign and StartCom

[Kurt Roeckx]

On Sat, Oct 15, 2016 at 06:07:50PM -0400, Eric Mill wrote:
> For the convenience of the thread -- assuming that a 1-year-oriented policy
> covered the certs up to and including those listed as 2017-10-01, then
> summing up Kurt's numbers:
> 
> * Certs expiring by Oct 2017: 2,088,329
> * Certs expiring after Oct 2017: 1,419,593

I'm not sure where you get the numbers from, maybe they weren't
clear.  But by 2017-10-01 the number of expired certifictes would
be 196100 - 138156 = 57944


Kurt

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

Re: Remediation Plan for WoSign and StartCom

[Eric Mill]

For the convenience of the thread -- assuming that a 1-year-oriented policy
covered the certs up to and including those listed as 2017-10-01, then
summing up Kurt's numbers:

* Certs expiring by Oct 2017: 2,088,329
* Certs expiring after Oct 2017: 1,419,593

On Sat, Oct 15, 2016 at 4:28 AM, Kurt Roeckx  wrote:

> On Fri, Oct 14, 2016 at 11:23:55PM +0200, Hanno Böck wrote:
> > On Fri, 14 Oct 2016 13:21:32 -0700 (PDT)
> > Ryan Sleevi  wrote:
> >
> > > In particular, I'm hoping to expand upon the choice to allow existing
> > > certs to continue to be accepted and to not remove the affected roots
> > > until 2019.
> >
> > Hi,
> >
> > From my understanding the problem here is that the alternative of simply
> > whitelisting the existing certificates isn't feasible, because there
> > are too many of them.
> >
> > *however* from what I remember almost all the time the free options of
> > startcom/wosign were limited to one year. (I think there was a short
> > period of time when it was possible to get 3-year-certs from wosign for
> > free, but they removed that shortly afterwards.)
> >
> > Therefore there should be some middlegroupd option:
> > a) Keep the existing root for 1 year and trust that wosign won't
> > backdate certificates
> > b) After that the vast majority of wosign/startcom certificates will be
> > expired. The number of the remaining ones is probably low enough to
> > make whitelisting feasible.
> >
> > I haven't checked CT logs for expiration dates, so this is more a
> > guess, but given the history of cert issuance and the reasonable
> > assumption most certs used the free option this seems plausible.
>
> This is what I get for the number of valid certificates:
>  2016-10-01 | 196100
>  2016-11-01 | 185740
>  2016-12-01 | 175310
>  2017-01-01 | 168933
>  2017-02-01 | 166109
>  2017-03-01 | 162535
>  2017-04-01 | 157278
>  2017-05-01 | 154630
>  2017-06-01 | 151857
>  2017-07-01 | 147927
>  2017-08-01 | 144076
>  2017-09-01 | 139678
>  2017-10-01 | 138156
>  2017-11-01 | 137849
>  2017-12-01 | 137648
>  2018-01-01 | 132568
>  2018-02-01 | 126031
>  2018-03-01 | 120888
>  2018-04-01 | 110723
>  2018-05-01 |  98605
>  2018-06-01 |  82580
>  2018-07-01 |  69629
>  2018-08-01 |  55843
>  2018-09-01 |  42570
>  2018-10-01 |  37793
>  2018-11-01 |  37541
>  2018-12-01 |  37287
>  2019-01-01 |  35227
>  2019-02-01 |  32453
>  2019-03-01 |  29538
>  2019-04-01 |  25133
>  2019-05-01 |  21264
>  2019-06-01 |  17563
>  2019-07-01 |  14310
>  2019-08-01 |  10892
>  2019-09-01 |   5429
>  2019-10-01 |124
>  2019-11-01 | 71
>  2019-12-01 | 31
>  2020-01-01 |  2
>  2020-02-01 |  1
>
>
> Kurt
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



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

Re: Remediation Plan for WoSign and StartCom

[Kurt Roeckx]

On Fri, Oct 14, 2016 at 11:23:55PM +0200, Hanno Böck wrote:
> On Fri, 14 Oct 2016 13:21:32 -0700 (PDT)
> Ryan Sleevi  wrote:
> 
> > In particular, I'm hoping to expand upon the choice to allow existing
> > certs to continue to be accepted and to not remove the affected roots
> > until 2019.
> 
> Hi,
> 
> From my understanding the problem here is that the alternative of simply
> whitelisting the existing certificates isn't feasible, because there
> are too many of them.
> 
> *however* from what I remember almost all the time the free options of
> startcom/wosign were limited to one year. (I think there was a short
> period of time when it was possible to get 3-year-certs from wosign for
> free, but they removed that shortly afterwards.)
> 
> Therefore there should be some middlegroupd option:
> a) Keep the existing root for 1 year and trust that wosign won't
> backdate certificates
> b) After that the vast majority of wosign/startcom certificates will be
> expired. The number of the remaining ones is probably low enough to
> make whitelisting feasible.
> 
> I haven't checked CT logs for expiration dates, so this is more a
> guess, but given the history of cert issuance and the reasonable
> assumption most certs used the free option this seems plausible.

This is what I get for the number of valid certificates:
 2016-10-01 | 196100
 2016-11-01 | 185740
 2016-12-01 | 175310
 2017-01-01 | 168933
 2017-02-01 | 166109
 2017-03-01 | 162535
 2017-04-01 | 157278
 2017-05-01 | 154630
 2017-06-01 | 151857
 2017-07-01 | 147927
 2017-08-01 | 144076
 2017-09-01 | 139678
 2017-10-01 | 138156
 2017-11-01 | 137849
 2017-12-01 | 137648
 2018-01-01 | 132568
 2018-02-01 | 126031
 2018-03-01 | 120888
 2018-04-01 | 110723
 2018-05-01 |  98605
 2018-06-01 |  82580
 2018-07-01 |  69629
 2018-08-01 |  55843
 2018-09-01 |  42570
 2018-10-01 |  37793
 2018-11-01 |  37541
 2018-12-01 |  37287
 2019-01-01 |  35227
 2019-02-01 |  32453
 2019-03-01 |  29538
 2019-04-01 |  25133
 2019-05-01 |  21264
 2019-06-01 |  17563
 2019-07-01 |  14310
 2019-08-01 |  10892
 2019-09-01 |   5429
 2019-10-01 |124
 2019-11-01 | 71
 2019-12-01 | 31
 2020-01-01 |  2
 2020-02-01 |  1


Kurt

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

Re: Remediation Plan for WoSign and StartCom

[Ryan Sleevi]

On Friday, October 14, 2016 at 2:24:37 PM UTC-7, Hanno Böck wrote:
> From my understanding the problem here is that the alternative of simply
> whitelisting the existing certificates isn't feasible, because there
> are too many of them.

Well, there's a spectrum, right? That's been discussed on the list - whether a 
whitelist of a portion of certificates, as part of an overall phase down, is 
viable.

Clearly, there's a spectrum of options - which range from no impact whatsoever 
to clients (e.g. continue trusting indefinitely) to immediate impact (complete 
distrust). I was mostly trying to figure out what criteria were being weighted 
/ how the choice of where to end on the spectrum was chosen.

As it stands, it seems a little inconsistent with respect to security 
messaging, and seems to leave Mozilla clients at risk (of backdating), but it 
avoids any impact to sites/users. Alternatively, Mozilla might choose to more 
consistently/aggressively protect users, but with the corresponding impact to 
sites/users. And then there's the broader discussion of whether or not Mozilla 
feels it should strive to protect non-Mozilla users, or if that's an 
externality that cannot be accounted for, or somewhere in between.

I apologize if I wasn't clearer, but I was trying to communicate that there are 
a number of notable, non-Mozilla platforms, that don't support whitelisting. So 
the only viable solution for them is full trust or full distrust (these 
platforms have the ability to update trust, but not to add more nuanced 
options. This is the case for Windows and Android, for example). So a Mozilla 
option that leaves partial trust, these other players must consider either full 
trust or full distrust - and that's the ecosystem challenge.

> *however* from what I remember almost all the time the free options of
> startcom/wosign were limited to one year. (I think there was a short
> period of time when it was possible to get 3-year-certs from wosign for
> free, but they removed that shortly afterwards.)

It was quite some time, and outside of the free cert realm, it certainly was 
easier to get 3year certs. As noted elsewhere, the proposal would basically 
involve trusting for 3y.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Hanno Böck]

On Fri, 14 Oct 2016 13:21:32 -0700 (PDT)
Ryan Sleevi  wrote:

> In particular, I'm hoping to expand upon the choice to allow existing
> certs to continue to be accepted and to not remove the affected roots
> until 2019.

Hi,

From my understanding the problem here is that the alternative of simply
whitelisting the existing certificates isn't feasible, because there
are too many of them.

*however* from what I remember almost all the time the free options of
startcom/wosign were limited to one year. (I think there was a short
period of time when it was possible to get 3-year-certs from wosign for
free, but they removed that shortly afterwards.)

Therefore there should be some middlegroupd option:
a) Keep the existing root for 1 year and trust that wosign won't
backdate certificates
b) After that the vast majority of wosign/startcom certificates will be
expired. The number of the remaining ones is probably low enough to
make whitelisting feasible.

I haven't checked CT logs for expiration dates, so this is more a
guess, but given the history of cert issuance and the reasonable
assumption most certs used the free option this seems plausible.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgp3HxEEpd6Tt.pgp
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Ryan Sleevi]

On Thursday, October 13, 2016 at 9:50:02 AM UTC-7, Kathleen Wilson wrote:
> 1) Distrust certificates chaining up to Affected Roots with a notBefore date 
> after October 21, 2016. If additional back-dating is discovered (by any 
> means) to circumvent this control, then Mozilla will immediately and 
> permanently revoke trust in the Affected Roots.
> -- This change will go into the Firefox 51 release train [4]. 
> -- The code will use the subject key id (hash of public key) to identify the 
> Affected Roots, so that the control will also apply to cross-certs of the 
> Affected Roots.
> 2) Add the previously identified backdated SHA-1 certs chaining up to the 
> Affected Roots to OneCRL.
> 3) No longer accept audits carried out by Ernst & Young Hong Kong.
> 4) Remove the Affected Roots from NSS after the SSL certificates issued 
> before October 1, 2016, have expired or have been replaced.

Hi Kathleen,

I appreciate the thoughtfulness and time spent on reviewing and considering the 
feedback and the incident. At the risk of asking you to do even more work, 
would it possible to ask that you expand a bit more on the reasoning behind 
this proposal?

In particular, I'm hoping to expand upon the choice to allow existing certs to 
continue to be accepted and to not remove the affected roots until 2019.

>From an outsider perspective, it would appear the reasoning is to minimize any 
>negative impact on existing WoSign customers, which in turn minimizes any 
>impact on Firefox users, by assuming that all (but a few) of the existing 
>certificates were correctly issued and reamin trustworthy. Is that a fair 
>statement?

It seems to accomplish this, you're willing to continue to trust that WoSign 
will not demonstrate any of the past behaviours it already demonstrated - such 
as backdating and misissuance, but not to issue new certificates. Is that 
correct?

I ask because it seems to be a very challenging position - we don't necessarily 
trust that new certificates will abide by the policies, but at the same time, 
we need to trust that they'll abide by the new policies and not issue any new 
certificates. Is that a fair statement of the conflict?

Thinking back to Mozilla's core principles, I'm curious how you weigh the risk 
to Firefox users versus the overall ecosystem risk. For example, many consumers 
of NSS-based trust stores have only the logic to trust (by inclusion) or 
distrust (by omission or by distrust records). This is true for applications 
like OpenSSL-/GnuTLS-based applications, but also true for other root stores 
and programs (for example, both Windows and Android, in their mass-deployed 
versions, lack more extensive capabilities). As a consequence of this - which, 
to be fair, is not a problem of Mozilla's creation - there exists the ecosystem 
risk that in order to minimize any incompatibilities, these applications will 
need to continue to trust WoSign and StartCom for as long as other popular 
programs - such as Mozilla - do. If these applications/devices lack the 
capability to distrust new certificates, as Mozilla plans to implement, then it 
means they may face risk that Mozilla users may not.

While again, I want to emphasize this is not a problem of Mozilla's creation, 
I'm curious how considerations such as other applications' behaviour is 
weighted in such decisions. As a concrete example, if it was weighted 
particularly high (that is, ecosystem good were seen to be as-valuable-or-more 
than the individual good to Firefox/Mozilla users), then it might be more 
desirable to have an accelerated plan to move Firefox to full distrust, rather 
than minimizing Firefox impact. For example, fully distrusting these 
certificates in, say, 6 months, would allow other players in the ecosystem to 
take appropriate steps and block these certificates, without having to suffer 
the first-mover/only-mover problem.

I understand this is somewhat unique, as notable other programs have not fully 
announced what they're intending, perhaps because they're allowing Mozilla the 
opportunity to lead the public discussion and investigation, but if other 
programs were concerned about the trustworthiness of WoSign and the ability to 
abide with a requirement to not issue new certificates, would you consider a 
path that moved to a full distrust (of both new and existing) in a more 
accelerated fashion, if it was not Mozilla moving alone?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Percy]

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

WoSign and StartCom are still actively selling certs which cost one hundreds or 
more dollars. I think Mozilla should mandate that WoSign/StartCom inform their 
users of such incidents or at least the imminent distrust by Mozilla (and 
Apple). Now users are left in the dark for those trust decisions which violates 
the minimum disruption principle.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Rob Stradling]

On 14/10/16 15:46, Gervase Markham wrote:
> On 14/10/16 11:37, Rob Stradling wrote:
>> Sure, but aren't we talking about specifying criteria for which log(s)
>> StartCom/WoSign _can't_ use in future?
>>
>> If Mozilla would prefer to forbid StartCom/WoSign from using their own
>> or each other's logs, then ISTM that it would be best to specify
>> criteria that is conditional on the future state of the CT ecosystem:
>> e.g., "StartCom/WoSign must not use their own or each other's logs,
>> unless no other browser-accepted log accepts their roots"
> 
> I think the rule we are putting in place is that: "StartCom/WoSign
> SHOULD NOT fulfil the non-Google log requirement by using logs that they
> run themselves. For as long as they do so, they will need to demonstrate
> ongoing evidence of efforts to get other logs to take their volume, and
> why those efforts have not been successful."
> 
> Is that better?

SGTM.

-- 
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: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 14/10/16 11:37, Rob Stradling wrote:
> Sure, but aren't we talking about specifying criteria for which log(s)
> StartCom/WoSign _can't_ use in future?
> 
> If Mozilla would prefer to forbid StartCom/WoSign from using their own
> or each other's logs, then ISTM that it would be best to specify
> criteria that is conditional on the future state of the CT ecosystem:
> e.g., "StartCom/WoSign must not use their own or each other's logs,
> unless no other browser-accepted log accepts their roots"

I think the rule we are putting in place is that: "StartCom/WoSign
SHOULD NOT fulfil the non-Google log requirement by using logs that they
run themselves. For as long as they do so, they will need to demonstrate
ongoing evidence of efforts to get other logs to take their volume, and
why those efforts have not been successful."

Is that better?

Gerv

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

Re: Remediation Plan for WoSign and StartCom

[okaphone . elektronika]

99% uptime sounds good but it allows being down for three and half days in a 
year. It's not actually a very high availabillity. ;-)

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

Re: Remediation Plan for WoSign and StartCom

[Rob Stradling]

On 14/10/16 10:50, Gervase Markham wrote:
> On 14/10/16 10:41, Rob Stradling wrote:
>> Gerv, does Mozilla need to make a final decision on this point immediately?
>>
>> I very much hope that there will be more CT logs by the time StartCom
>> and/or WoSign are readmitted into Mozilla's trust list.  Why not delay
>> making this decision until nearer that time?
> 
> We don't have to make a decision, in that we are not going to mandate a
> particular log. We have just set some criteria. If those criteria are
> easier to meet by the time StartCom/WoSign have to meet them, then great
> :-)

Sure, but aren't we talking about specifying criteria for which log(s)
StartCom/WoSign _can't_ use in future?

If Mozilla would prefer to forbid StartCom/WoSign from using their own
or each other's logs, then ISTM that it would be best to specify
criteria that is conditional on the future state of the CT ecosystem:
e.g., "StartCom/WoSign must not use their own or each other's logs,
unless no other browser-accepted log accepts their roots"

If the criteria can't be conditional, then I think you'd end up with...
"StartCom/WoSign may use their own logs forever, because there was a
dearth of any other non-Google logs available to them in October 2016"

...that is, unless you say...
"StartCom/WoSign must not use their own or each other's logs.  This
policy may be revised in the future".

-- 
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: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 13/10/16 23:42, Nick Lamb wrote:
> Please can Mozilla ensure that both EY Hong Kong and the overarching
> parent organisation in the United Kingdom (in Southwark) are informed
> of this ban and get a copy of Mozilla's findings if they haven't
> already ?

This is a good idea; I will try and figure out who to tell.

Gerv

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

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 14/10/16 10:41, Rob Stradling wrote:
> Gerv, does Mozilla need to make a final decision on this point immediately?
> 
> I very much hope that there will be more CT logs by the time StartCom
> and/or WoSign are readmitted into Mozilla's trust list.  Why not delay
> making this decision until nearer that time?

We don't have to make a decision, in that we are not going to mandate a
particular log. We have just set some criteria. If those criteria are
easier to meet by the time StartCom/WoSign have to meet them, then great
:-)

Gerv

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

Re: Remediation Plan for WoSign and StartCom

[Rob Stradling]

On 13/10/16 20:52, Gervase Markham wrote:

> StartCom/WoSign have indicated ro me that they may have trouble
> complying with the non-Google log requirement because it's hard to find
> a non-Google log which can scale sufficiently. I suggest we allow them
> some leeway on this but they need to demonstrate evidence of efforts to
> meet the requirement.

Gerv, does Mozilla need to make a final decision on this point immediately?

I very much hope that there will be more CT logs by the time StartCom
and/or WoSign are readmitted into Mozilla's trust list.  Why not delay
making this decision until nearer that time?

Alternatively, why not just rely on the mechanisms built into CT for
detecting log misbehaviour?  ;-)

> If anyone reading controls a CT log which could accept their volume,
> even for payment, please contact StartCom/WoSign and let Mozilla know
> you have done so.

-- 
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: Remediation Plan for WoSign and StartCom

[Kurt Roeckx]

On 2016-10-14 10:19, Nick Lamb wrote:

On Friday, 14 October 2016 02:21:36 UTC+1, Matt Palmer  wrote:

Will there be any requirements around the qualification status of the logs,
or could anyone who wanted to be "nice" just stand up a log, and have these
CAs obtain precerts from them?


I don't think Mozilla has declared any specific requirements, but presumably 
they would expect to choose the same or similar criteria as Google's Chrome 
which you're already aware of but I'll link for anybody else

https://www.chromium.org/Home/chromium-security/certificate-transparency/log-policy

For the immediate purpose here (allowing broad oversight over what the new CA is 
issuing) some of these criteria are less important, e.g. the >99% uptime may be 
less important because oversight would be done via a monitor, but Mozilla intends 
to add SCT-checking to Firefox, at which point all the criteria will be important.


I think the 99% uptime is important. They need to be able to submit new 
certificates to it. This is clearly needed if embedding the SCTs is 
required. But I guess it's more important to the CA in that case than it 
is to Mozilla.



Kurt


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

Re: Remediation Plan for WoSign and StartCom

[Kurt Roeckx]

On 2016-10-14 03:20, Matt Palmer wrote:

On Thu, Oct 13, 2016 at 09:49:50AM -0700, Kathleen Wilson wrote:

5. 100% embedded CT for all issued certificates, with embedded SCTs from
at least one Google and one non-Google log not controlled by the CA.


Will there be any requirements around the qualification status of the logs,
or could anyone who wanted to be "nice" just stand up a log, and have these
CAs obtain precerts from them?


I would suggest to use the same qualification criteria as Google uses 
for Chromium 
(https://www.chromium.org/Home/chromium-security/certificate-transparency/log-policy).


The requirement are otherwise more strict that what Chromium uses, it 
does not require them to be embedded, and they can operate the log 
themselves.  See 
https://www.chromium.org/Home/chromium-security/root-ca-policy/CTPolicyMay2016edition.pdf



Kurt


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

Re: Remediation Plan for WoSign and StartCom

[Nick Lamb]

On Friday, 14 October 2016 02:21:36 UTC+1, Matt Palmer  wrote:
> Will there be any requirements around the qualification status of the logs,
> or could anyone who wanted to be "nice" just stand up a log, and have these
> CAs obtain precerts from them?

I don't think Mozilla has declared any specific requirements, but presumably 
they would expect to choose the same or similar criteria as Google's Chrome 
which you're already aware of but I'll link for anybody else

https://www.chromium.org/Home/chromium-security/certificate-transparency/log-policy

For the immediate purpose here (allowing broad oversight over what the new CA 
is issuing) some of these criteria are less important, e.g. the >99% uptime may 
be less important because oversight would be done via a monitor, but Mozilla 
intends to add SCT-checking to Firefox, at which point all the criteria will be 
important.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[bigiain]

On Friday, October 14, 2016 at 9:47:24 AM UTC+11, Percy wrote:
> > Others have noted the mismatch here with an October 1 date elsewhere in 
> > the document. I think we should pick a single date in the future, to 
> > allow the CAs concerned to wind down operations without leaving 
> > customers having just obtained certs which will stop working in a few 
> > months. So I would argue for October 21st in line with our principle of 
> > minimal disruption to cert owners. 
> 
> I think Oct 1st is a better deadline. WoSign has stopped issuing DV certs 
> since Sept 29th and Apple has banned certs after 2016-09-19. There is no 
> reason to give WoSign another week of time to issuing new certs. 

FWIW, I've got a StartCom cert here dated Not Valid Before: Tuesday, 4 October 
2016

I'll deal with if if it's decided to kill Start off and impact customers from 
before this decision, but it'll be a (possibly unintended?) pain in the arse...

(https://metricon.mobiddiction.com.au/ for anyone curious...)

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

Re: Remediation Plan for WoSign and StartCom

[Matt Palmer]

On Thu, Oct 13, 2016 at 09:49:50AM -0700, Kathleen Wilson wrote:
> 5. 100% embedded CT for all issued certificates, with embedded SCTs from
> at least one Google and one non-Google log not controlled by the CA.

Will there be any requirements around the qualification status of the logs,
or could anyone who wanted to be "nice" just stand up a log, and have these
CAs obtain precerts from them?

- Matt

-- 
Yes, Java is so bulletproofed that to a C programmer it feels like being in
a straightjacket, but it's a really comfy and warm straightjacket, and the
world would be a safer place if everyone was straightjacketed most of the
time.   -- Mark 'Kamikaze' Hughes

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

Re: Remediation Plan for WoSign and StartCom

[Percy]

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

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

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

Re: Remediation Plan for WoSign and StartCom

[Nick Lamb]

On Thursday, 13 October 2016 20:52:54 UTC+1, Gervase Markham  wrote:
> To be clear, this is a permanent ban, applicable worldwide, but only to
> the Hong Kong branch of E (If further issues are found with E
> audits elsewhere, then we might consider something with wider scope.)

Please can Mozilla ensure that both EY Hong Kong and the overarching parent 
organisation in the United Kingdom (in Southwark) are informed of this ban and 
get a copy of Mozilla's findings if they haven't already ?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 13/10/16 17:49, Kathleen Wilson wrote:
> Thanks again to all of you who have put in so much time and effort to
> determine what happened with WoSign and StartCom and discuss what to
> do about it.

You are welcome.

As people will have read, the current decision at Mozilla is to treat
the WoSign and StartCom roots the same, except that StartCom has an
opportunity to be re-included faster than WoSign if they can meet the
conditions in time. It is also the current position that we will require
the companies to use new roots, although cross-signing of the new by the
old is permissible.

Some further comments for Kathleen:

> Within this message, the term “Affected Roots” applies to the
> following 7 root certificates.

Yes; it appears my root list in the investigation document missed one.
Sorry about that.

> 1) Distrust certificates chaining up to Affected Roots with a
> notBefore date after October 21, 2016. 

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

> 3) No longer
> accept audits carried out by Ernst & Young Hong Kong. 

To be clear, this is a permanent ban, applicable worldwide, but only to
the Hong Kong branch of E (If further issues are found with E
audits elsewhere, then we might consider something with wider scope.)

> 4) Remove the
> Affected Roots from NSS after the SSL certificates issued before
> October 1, 2016, have expired or have been replaced.

That should be in approximately 39 months time, as that's the max
issuance length allowed by the BRs.

> 4. Provide auditor attestation that a full performance audit has been
> performed confirming compliance with the CA/Browser Forum's Baseline
> Requirements[6].  This audit may be part of an annual WebTrust BR
> audit. It must include a full security audit of the CA’s issuing
> infrastructure.

I would recommend that Mozilla retain the option to approve the security
auditor, and that it be an external company.

> 5. 100% embedded CT for all issued certificates, with embedded SCTs
> from at least one Google and one non-Google log not controlled by the
> CA.

StartCom/WoSign have indicated ro me that they may have trouble
complying with the non-Google log requirement because it's hard to find
a non-Google log which can scale sufficiently. I suggest we allow them
some leeway on this but they need to demonstrate evidence of efforts to
meet the requirement.

If anyone reading controls a CT log which could accept their volume,
even for payment, please contact StartCom/WoSign and let Mozilla know
you have done so.

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

Re: Remediation Plan for WoSign and StartCom

[Kathleen Wilson]

On Thursday, October 13, 2016 at 10:39:05 AM UTC-7, Han Yuwei wrote:
> 
> Is this the final decision or still pending?

Please consider this the draft of my decision. We are actively working on the 
Mozilla action items, but this plan is still open for discussion.

Thanks,
Kathleen


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

Re: Remediation Plan for WoSign and StartCom

[Han Yuwei]

在 2016年10月14日星期五 UTC+8上午12:50:02，Kathleen Wilson写道：
> All,
> 
> Thanks again to all of you who have put in so much time and effort to 
> determine what happened with WoSign and StartCom and discuss what to do about 
> it.
> 
> Based on the information that I have seen regarding WoSign, I believe that 
> WoSign intentionally bent the rules in order to continue issuing SHA-1 SSL 
> certs, when they knew full well that was no longer allowed. I also believe 
> that the deception continued even after Mozilla directly asked WoSign about 
> this. WoSign has lost my confidence in their ability and intention to follow 
> Mozilla's policies. Therefore, I think we should respond similarly to WoSign 
> as we did to CNNIC [1][2]. Unfortunately, the number of certificates and the 
> timescales involved are such that we prefer not to create a list of the 
> domains for which previously-issued certs that chain up to the Affected Roots 
> may continue to be trusted, so our approach will be a little different, as 
> Gerv previously described[3].
> 
> Within this message, the term “Affected Roots” applies to the following 7 
> root certificates.
> 
> 1) Subject: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
> Certificate Serial Number: 50706bcdd813fc1b4e3b3372d211488d
> SHA-1 Fingerprint   
> 16:32:47:8D:89:F9:21:3A:92:00:85:63:F5:A4:A7:D3:12:40:8A:D6
> SHA-256 Fingerprint   
> D6:F0:34:BD:94:AA:23:3F:02:97:EC:A4:24:5B:28:39:73:E4:47:AA:59:0F:31:0C:77:F4:8F:DF:83:11:22:54
> 
> 2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA 
> Limited, C=CN
> Certificate Serial Number: 5e68d61171946350560068f33ec9c591
> SHA-1 Fingerprint   
> B9:42:94:BF:91:EA:8F:B6:4B:E6:10:97:C7:FB:00:13:59:B6:76:CB
> SHA-256 Fingerprint   
> 4B:22:D5:A6:AE:C9:9F:3C:DB:79:AA:5E:C0:68:38:47:9C:D5:EC:BA:71:64:F7:F2:2D:C1:D6:5F:63:D8:57:08
> 
> 3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA 
> Limited, C=CN
> Certificate Serial Number: 6b25da8a889d7cbc0f05b3b17a614544
> SHA-1 Fingerprint   
> FB:ED:DC:90:65:B7:27:20:37:BC:55:0C:9C:56:DE:BB:F2:78:94:E1
> SHA-256 Fingerprint   
> D4:87:A5:6F:83:B0:74:82:E8:5E:96:33:94:C1:EC:C2:C9:E5:1D:09:03:EE:94:6B:02:C3:01:58:1E:D9:9E:16
> 
> 4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
> Certificate Serial Number: 684a5870806bf08f02faf6dee8b09090
> SHA-1 Fingerprint   
> D2:7A:D2:BE:ED:94:C0:A1:3C:C7:25:21:EA:5D:71:BE:81:19:F3:2B
> SHA-256 Fingerprint   
> 8B:45:DA:1C:06:F7:91:EB:0C:AB:F2:6B:E5:88:F5:FB:23:16:5C:2E:61:4B:F8:85:56:2D:0D:CE:50:B2:9B:02
> 
> 5) Subject: CN=StartCom Certification Authority, OU=Secure Digital 
> Certificate Signing, O=StartCom Ltd., C=IL
> Certificate Serial Number: 01
> SHA-1 Fingerprint   
> 3E:2B:F7:F2:03:1B:96:F3:8C:E6:C4:D8:A8:5D:3E:2D:58:47:6A:0F
> SHA-256 Fingerprint   
> C7:66:A9:BE:F2:D4:07:1C:86:3A:31:AA:49:20:E8:13:B2:D1:98:60:8C:B7:B7:CF:E2:11:43:B8:36:DF:09:EA
> 
> 6) Subject: CN=StartCom Certification Authority, OU=Secure Digital 
> Certificate Signing, O=StartCom Ltd., C=IL
> Certificate Serial Number: 2d
> SHA-1 Fingerprint   
> A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0
> SHA-256 Fingerprint   
> E1:78:90:EE:09:A3:FB:F4:F4:8B:9C:41:4A:17:D6:37:B7:A5:06:47:E9:BC:75:23:22:72:7F:CC:17:42:A9:11
> 
> 7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., 
> C=IL
> Certificate Serial Number: 3b
> SHA-1 Fingerprint   
> 31:F1:FD:68:22:63:20:EE:C6:3B:3F:9D:EA:4A:3E:53:7C:7C:39:17
> SHA-256 Fingerprint   
> C7:BA:65:67:DE:93:A7:98:AE:1F:AA:79:1E:71:2D:37:8F:AE:1F:93:C4:39:7F:EA:44:1B:B7:CB:E6:FD:59:95
> 
> I intend to move forward as follows, unless further information or input 
> causes me to rethink this plan. Therefore, I will continue to appreciate your 
> input, and this discussion is still open.
> 
> Mozilla will perform the following 4 actions. I have filed Bugzilla Bug 
> #1309707 to track the engineering work for this. Please keep discussion here 
> in mozilla.dev.security.policy, and not in the bug.
> 
> 1) Distrust certificates chaining up to Affected Roots with a notBefore date 
> after October 21, 2016. If additional back-dating is discovered (by any 
> means) to circumvent this control, then Mozilla will immediately and 
> permanently revoke trust in the Affected Roots.
> -- This change will go into the Firefox 51 release train [4]. 
> -- The code will use the subject key id (hash of public key) to identify the 
> Affected Roots, so that the control will also apply to cross-certs of the 
> Affected Roots.
> 2) Add the previously identified backdated SHA-1 certs chaining up to the 
> Affected Roots to OneCRL.
> 3) No longer accept audits carried out by Ernst & Young Hong Kong.
> 4) Remove the Affected Roots from NSS after the SSL certificates issued 
> before October 1, 2016, have expired or have been replaced.
> 
> WoSign may apply for inclusion of new (replacement) root certificates 
> following Mozilla's normal root inclusion/change process (minus waiting 

Re: Remediation Plan for WoSign and StartCom

[Kathleen Wilson]

On Thursday, October 13, 2016 at 10:17:28 AM UTC-7, Jonathan Rudenberg wrote:
> Can you clarify if the notBefore cutoff is October 1, 2016, and 
> not October 21, 2016? There are two conflicting dates in the listed actions.

My thinking is that we would distrust certs issued after next week (Oct 21), 
and that Oct 1 would be sufficient time for any clients to find an alternative 
solution. 

But, as you mention, that may be too confusing, so we should pick one date.

Is there any reason why that date cannot be October 1?

Thanks,
Kathleen


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

Re: Remediation Plan for WoSign and StartCom

[Jonathan Rudenberg]

On Oct 13, 2016, at 12:49, Kathleen Wilson  wrote:
> 
> 1) Distrust certificates chaining up to Affected Roots with a notBefore date 
> after October 21, 2016. If additional back-dating is discovered (by any 
> means) to circumvent this control, then Mozilla will immediately and 
> permanently revoke trust in the Affected Roots.
> -- This change will go into the Firefox 51 release train [4]. 
> -- The code will use the subject key id (hash of public key) to identify the 
> Affected Roots, so that the control will also apply to cross-certs of the 
> Affected Roots.
> 2) Add the previously identified backdated SHA-1 certs chaining up to the 
> Affected Roots to OneCRL.
> 3) No longer accept audits carried out by Ernst & Young Hong Kong.
> 4) Remove the Affected Roots from NSS after the SSL certificates issued 
> before October 1, 2016, have expired or have been replaced.

Can you clarify if the notBefore cutoff is October 1, 2016, and not October 21, 
2016? There are two conflicting dates in the listed actions.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Remediation Plan for WoSign and StartCom

[Kathleen Wilson]

All,

Thanks again to all of you who have put in so much time and effort to determine 
what happened with WoSign and StartCom and discuss what to do about it.

Based on the information that I have seen regarding WoSign, I believe that 
WoSign intentionally bent the rules in order to continue issuing SHA-1 SSL 
certs, when they knew full well that was no longer allowed. I also believe that 
the deception continued even after Mozilla directly asked WoSign about this. 
WoSign has lost my confidence in their ability and intention to follow 
Mozilla's policies. Therefore, I think we should respond similarly to WoSign as 
we did to CNNIC [1][2]. Unfortunately, the number of certificates and the 
timescales involved are such that we prefer not to create a list of the domains 
for which previously-issued certs that chain up to the Affected Roots may 
continue to be trusted, so our approach will be a little different, as Gerv 
previously described[3].

Within this message, the term “Affected Roots” applies to the following 7 root 
certificates.

1) Subject: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
Certificate Serial Number: 50706bcdd813fc1b4e3b3372d211488d
SHA-1 Fingerprint   
16:32:47:8D:89:F9:21:3A:92:00:85:63:F5:A4:A7:D3:12:40:8A:D6
SHA-256 Fingerprint   
D6:F0:34:BD:94:AA:23:3F:02:97:EC:A4:24:5B:28:39:73:E4:47:AA:59:0F:31:0C:77:F4:8F:DF:83:11:22:54

2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, 
C=CN
Certificate Serial Number: 5e68d61171946350560068f33ec9c591
SHA-1 Fingerprint   
B9:42:94:BF:91:EA:8F:B6:4B:E6:10:97:C7:FB:00:13:59:B6:76:CB
SHA-256 Fingerprint   
4B:22:D5:A6:AE:C9:9F:3C:DB:79:AA:5E:C0:68:38:47:9C:D5:EC:BA:71:64:F7:F2:2D:C1:D6:5F:63:D8:57:08

3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA 
Limited, C=CN
Certificate Serial Number: 6b25da8a889d7cbc0f05b3b17a614544
SHA-1 Fingerprint   
FB:ED:DC:90:65:B7:27:20:37:BC:55:0C:9C:56:DE:BB:F2:78:94:E1
SHA-256 Fingerprint   
D4:87:A5:6F:83:B0:74:82:E8:5E:96:33:94:C1:EC:C2:C9:E5:1D:09:03:EE:94:6B:02:C3:01:58:1E:D9:9E:16

4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
Certificate Serial Number: 684a5870806bf08f02faf6dee8b09090
SHA-1 Fingerprint   
D2:7A:D2:BE:ED:94:C0:A1:3C:C7:25:21:EA:5D:71:BE:81:19:F3:2B
SHA-256 Fingerprint   
8B:45:DA:1C:06:F7:91:EB:0C:AB:F2:6B:E5:88:F5:FB:23:16:5C:2E:61:4B:F8:85:56:2D:0D:CE:50:B2:9B:02

5) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate 
Signing, O=StartCom Ltd., C=IL
Certificate Serial Number: 01
SHA-1 Fingerprint   
3E:2B:F7:F2:03:1B:96:F3:8C:E6:C4:D8:A8:5D:3E:2D:58:47:6A:0F
SHA-256 Fingerprint   
C7:66:A9:BE:F2:D4:07:1C:86:3A:31:AA:49:20:E8:13:B2:D1:98:60:8C:B7:B7:CF:E2:11:43:B8:36:DF:09:EA

6) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate 
Signing, O=StartCom Ltd., C=IL
Certificate Serial Number: 2d
SHA-1 Fingerprint   
A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0
SHA-256 Fingerprint   
E1:78:90:EE:09:A3:FB:F4:F4:8B:9C:41:4A:17:D6:37:B7:A5:06:47:E9:BC:75:23:22:72:7F:CC:17:42:A9:11

7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., 
C=IL
Certificate Serial Number: 3b
SHA-1 Fingerprint   
31:F1:FD:68:22:63:20:EE:C6:3B:3F:9D:EA:4A:3E:53:7C:7C:39:17
SHA-256 Fingerprint   
C7:BA:65:67:DE:93:A7:98:AE:1F:AA:79:1E:71:2D:37:8F:AE:1F:93:C4:39:7F:EA:44:1B:B7:CB:E6:FD:59:95

I intend to move forward as follows, unless further information or input causes 
me to rethink this plan. Therefore, I will continue to appreciate your input, 
and this discussion is still open.

Mozilla will perform the following 4 actions. I have filed Bugzilla Bug 
#1309707 to track the engineering work for this. Please keep discussion here in 
mozilla.dev.security.policy, and not in the bug.

1) Distrust certificates chaining up to Affected Roots with a notBefore date 
after October 21, 2016. If additional back-dating is discovered (by any means) 
to circumvent this control, then Mozilla will immediately and permanently 
revoke trust in the Affected Roots.
-- This change will go into the Firefox 51 release train [4]. 
-- The code will use the subject key id (hash of public key) to identify the 
Affected Roots, so that the control will also apply to cross-certs of the 
Affected Roots.
2) Add the previously identified backdated SHA-1 certs chaining up to the 
Affected Roots to OneCRL.
3) No longer accept audits carried out by Ernst & Young Hong Kong.
4) Remove the Affected Roots from NSS after the SSL certificates issued before 
October 1, 2016, have expired or have been replaced.

WoSign may apply for inclusion of new (replacement) root certificates following 
Mozilla's normal root inclusion/change process (minus waiting in the queue for 
the discussion), after they have completed all of the following action items, 
and no earlier than June 1, 2017. If StartCom is able to provide proof enough 
to convince the Mozilla community in the mozilla.dev.security.policy forum