Re: Remediation Plan for WoSign and StartCom

[Itzhak Daniel]

On Monday, November 7, 2016 at 10:46:32 AM UTC+2, Rami Kogan wrote:
> Just came across the following Phishing site which is using a StartCom cert:
> 
> serviices-intl[.]com

Did you contact them, if you did, what was their reply? It's better to contact 
the CA first, and only if issues arouse then to publicly disclose the issue.

Anyway, they've revoked it.

---OUTPUT SNIP---
CN: serviices-intl.com
ASN: serviices-intl.com
 From: Nov  4 21:03:13 2016 GMT  To: Nov  4 21:03:13 2019 GMT
 Issuer: StartCom Class 1 DV Server CA
 Type: RSA  Size: 2048bit   Signature: SHA2-256
 Serial: 51ae9062c56e25e414d056a6b77e2c33

---OUTPUT SNIP---
revoked
This Update: Nov  7 09:11:40 2016 GMT
Next Update: Nov 11 09:21:40 2016 GMT
Revocation Time: Nov  7 09:08:47 2016 GMT
___
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

[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&d=sZWa2NJm1b7zf0w12nNA5JOUrTfLuNXQPooKM1C0fA&s=5&u=https%3a%2f%2fwww%2email-archive%2ecom%2fdev-security-policy%40lists%2emozilla%2eorg%2fmsg04274%2ehtml
>2. 
>https://scanmail.trustwave.com/?c=4062&d=sZWa2NJm1b7zf0w12nNA5JOUrTfLuNXQPtwOMQDifg&s=5&u=https%3a%2f%2fcrt%2esh%2f%3fid%3d4467456
>3. 
>https://scanmail.trustwave.com/?c=4062&d=sZWa2NJm1b7zf0w12nNA5JOUrTfLuNXQPtpZZQXtKA&s=5&u=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&d=sZWa2NJm1b7zf0w12nNA5JOUrTfLuNXQPtpZZ1bsJg&s=5&u=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

[Jakob Bohm]

On 02/11/2016 13:44, dracenm...@googlemail.com wrote:

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.



At least internally and to WoSign and StartCom, the October 21 deadline
was announced before it took place (See for example the posting by
Kathleen Wilson titled "Remediation Plan for WoSign and StartCom" on
2016-10-13), but for some dubious reason, they continued selling
certificates they knew would not work.


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.



If they sold anyone a certificate after the browser cut-off dates
(Apple used a cut of date of 2016-09-19), those webmasters should
demand their money back, and if possible, block any payment by credit
card through their bank.


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



When someone else mentioned that earlier, Ryan Sleevi of Google
explained that their customer announcement didn't rule out reinclusion,
they simply didn't say anything.  So as far as the official Google
announcement goes, there is no (published) minimum return date for
Chrome (the second largest browser).


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

[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

[Gervase Markham]

On 22/10/16 20:41, Peter Bowen wrote:
> 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?

Certum are aware of the situation and may have their own comments to
make. But it is certainly not Mozilla's intention to allow our policy
decisions to be circumvented by cross-signing. (This is not saying that
Certum's intent was to do this!)

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  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 
> Cc: Kathleen Wilson ; 
> 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 
> 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 
Cc: Kathleen Wilson ; 
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 
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  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

[Jernej Simončič]

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.

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

[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

[marc . reitz]

Am Freitag, 21. Oktober 2016 17:31:17 UTC+2 schrieb Nick Lamb:
> This is the "too big to fail" argument and I think we've addressed why that's 
> not acceptable previously.

I've not said that the whole certificate system depends on StartCom. Sorry if I 
had not expressed myself clearly. As someone who uses StartCom and is personal 
not able to pay the price of nearly 500 EUR for a wildcard cert to secure a few 
websites, some devices and a mailserver, I've read about the bull that 
StartCom made and followed the threads in this group. I've read a lot of (good 
and true) argumentation but only from the "technical" side not one single 
argument dealing with the impact on users. So my intention was to bring up this 
"view".

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

Let's Encrypt is surely a very good approach but actually not an replacement 
for an CA that is listed in the root store of all major browsers. It's not 
really practicable for someone using shared space without shell access, for 
securing consumer devices (router, NAS, and so on), because of the 90 day 
period. To much effort for the "normal" people out there. 

And this is what my argument dealing with. In times where everybody, also 
Mozilla, is "praying" to use encryption I find it hard to understand that one 
big (and nearly the only) opportunity to secure communication for small 
businesses and individuals is thrown out. No question StartCom has made 
mistakes and of course there should be arrangements made to keep the CA-system 
safe and to prevent others from making this mistakes. But with distrusting 
StartCom I think (my personal view) the "small" users are punished a lot more 
than everyone else and they haven't done something wrong.

My only intention was to bring up this thought, not to say that the whole 
system depends on StartCom. But for sure the effort for many, many small 
webmasters out there or people who want's to secure their LAN at home, there 
small networks in company, is groing intensively by distrusting StartCom and as 
a result of this, they will not use encryption.
___
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

[longolius]

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. 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.
I doubt we'll see a professional answer like this in the current Comodo case. 
But then - of cause - Comodos headquarter is in the United States and not in 
China.

I feel like Mozilla is misusing its market power in a beginning trade war and 
this is not a good thing for the Mozilla Foundation. We all trust Mozilla to 
fight for a free web and not to choose sides in a trade war.

Best,
Nikolai

Am Donnerstag, 13. Oktober 2016 18:50:02 UTC+2 schrieb 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 R

Re: Remediation Plan for WoSign and StartCom

[Tom Ritter]

On Oct 19, 2016 11:51 AM, "Ryan Hurst"  wrote:
>
> > 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
>
> Since you would be OK with one google log, it seems it would be harmless
for them to log to their log also. As such treating them consistently as
the Google EV policy (one google, one other) seems acceptable.
>

It would be harmless, but if the only option for them to get to two logs is
to run their own, I don't see the point in requiring them to if we're not
going to really regard it as trusted. (Which at least I wouldn't. I'd
regard it as "A log I expect to be manipulated as soon as it is financially
expedient to do so.")

Unless we're proverbially doing it to give them more rope to hang
themselves with, so they get punished worse if they manipulate their log
like their CA issuance. But I'm not keen on that idea since we're
retroactively finding them putting users at risk, and this would be even
moreso.

-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

[Ryan Hurst]

> 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

Since you would be OK with one google log, it seems it would be harmless for 
them to log to their log also. As such treating them consistently as the Google 
EV policy (one google, one other) seems acceptable.

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

[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&Y 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&file=pdf
> https://cert.webtrust.org/SealFile?seal=2091&file=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&Y 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&file=pdf
> https://cert.webtrust.org/SealFile?seal=2091&file=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&file=pdf
https://cert.webtrust.org/SealFile?seal=2091&file=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 do

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

[Nick Lamb]

On Tuesday, 18 October 2016 15:38:07 UTC+1, Inigo Barreira  wrote:
> 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.

Without any doubt in my mind, all three issues were in fact security problems. 
Most broadly this is because StartCom deviated from its stated policy and 
obeying that policy is itself a security requirement. It is not for StartCom to 
declare that it has decided after the fact some aspects of the policy are not 
"security" and it chose to ignore those, the Relying Parties are entitled to 
expect that StartCom will obey the entire policy and to rely on however much or 
little of the policy as they like. Likewise for the Baseline Requirements.

StartCom was of course welcome to write a policy saying "We might issue 
backdated certificates, we might re-use serial numbers, we might not bother 
actually doing domain verification properly" and I believe a hypothetical 
alternative CA which documented such policies, let's call it "Garbage StartCom" 
would not be trusted by Mozilla, nor by any major trust store. Why should the 
actual StartCom be permitted to document good policies, then act like Garbage 
StartCom anyway with the thin excuse that you think it was not a "security" 
problem?

For the backdated SHA-1 certificates in particular, signing these certificates 
involved taking a huge risk each time because of the known vulnerability of the 
Merkle–Damgård construction and relatively short hashes in SHA-1. When this is 
done for the Exception process the _entire_ community gets to examine the 
tbsCertificates first, with both statistical analysis tools and simple visual 
inspection of the contents to see if there's anything dubious. But StartCom / 
WoSign instead issued certificates without so much as telling anybody, forcing 
the risk upon the entire Web PKI relying community without notice, for their 
financial benefit.

StartCom's Issuer for the back-dated SHA-1 certificates has a CA:TRUE 
certificate without a path length constraint allowing a hypothetical bad guy to 
create themselves a full CA:TRUE certificate of their own using a chosen-prefix 
attack or some as-yet unknown improvement on the same idea. That's basically 
game over for the PKI if it had happened, but StartCom/ WoSign risked it to get 
some cash in direct defiance of the Baseline Requirements, and the rules of the 
trust store programmes they'd agreed to. How is that _not_ a security problem ?
___
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 decis

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

[Peter Bowen]

On Tue, Oct 18, 2016 at 5:51 AM, Gervase Markham  wrote:
> 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.

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.

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

[Gervase Markham]

On 18/10/16 01:00, Nick Lamb wrote:
> 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).

This is a difficult call.

On the one hand, I want to stand up for the right of all browsers to
make independent decisions on who to trust, and that includes Qihoo
360's Safe Browser. And as it's perfectly possible and not in any way
unacceptable or illegal for CA to operate while not being trusted by
Mozilla, I don't think it's reasonable to interfere with thr
relationship between a CA and its customers by requiring them to make
particular forms of communication about Mozilla's level of trust in them.

On the other hand, Qihoo 360 do have a conflict of interest when making
trust decisions about the CAs that they own.

It is not clear what Qihoo plans to do about WoSign. For StartCom, they
plan to rebuild or review all of its systems to remove the influence of
WoSign-authored code, which is agreed to be of poor quality. It would
certainly be a statement of how Qihoo 360 views security, as to whether
StartCom continued to issue certs during this process or whether they
suspended issuance until it was done.

I guess I would say the following to Qihoo 360, without knowing what
they plan to do. Continuing to trust StartCom and WoSign (assuming the
other browsers popular in China do the same), and continuing to issue
certs from them while other browsers are refusing them, runs the danger
of further splitting the Chinese internet from that of the rest of the
world. One thing that's clear about the Internet is that its value to
all goes up the more connected it is. Steps which make the Chinese
internet and the rest of the world less connected are to be avoided, for
everyone's benefit.

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

[Kathleen Wilson]

All,

Here’s a summary of your input, and my thoughts.

~~
What about NSS?
We discussed this in the NSS team call last week, and the general decision was 
that the rules we put in place regarding these Affected Roots for Mozilla will 
also be put in place inside NSS. 
That doesn’t help all consumers of the NSS root store, just the 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. 

~~
Several comments about Mozilla’s Action #4.
> 4) Remove the Affected Roots from NSS after the SSL certificates 
> issued before October 1, 2016, have expired or have been replaced.

I will change the date to October 21, 2016 to be consistent with the date 
previously listed.

When I wrote that we would remove the Affected roots after the certs had 
expired or been replaced, I was incorrectly only thinking about the 1-year SSL 
certs.

My intent was to find a reasonable date in the future when current clients have 
had enough notice and time to transition to other root certificates. Based on 
the data from Kurt, it looks like a year might be too little time. Two years 
seems like a lot of time.

~~
Regarding actions for the CA…
Several suggestions that Mozilla require or strongly urge the CA owners of the 
Affected Roots to reach out to their subscribers asap to let them know about 
these changes, and give those clients time to transition.

> subscribers 
> deserve some warning even of the risk that invalidation would 
> happen in future, not to mention that they will not be able to
> receive renewals from these CAs, at least for some time.

> 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 

I would hope that the CA would figure out how to communicate this to their 
customers in order to help their customers have minimum disruption. 

The CA could create new root certs, and put information on their website to 
make it easier for users to manually import their new root certs, and also put 
information on their website for their current customers who will need to get 
new intermediate certs, and instruct their customers about downloading the new 
root certs. That’s basically what CAs whose root certs aren’t included in NSS 
(and aren’t cross-signed by an included root) have to do anyways.

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.


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

I will add the sentence: “The auditor must be an external company, and approved 
by Mozilla.”


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

As suggested, I will add: 
”The CA SHOULD NOT fulfill 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." 

> I should add that if StartCom/WoSign have a CT log codebase capable of
> taking the volume necessary, they could always open source it, and then
> pay a 3rd party to run an instance of it, with an arms-length contract.
> That sort of solution may well be acceptable, depending on contract details.

I don't think that changes the sentence that is being added.


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

I think Gerv is doing that.

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?

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

What would be a reasonable requirement to state for each

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

[Erwann Abalea]

Bonsoir,

Le vendredi 14 octobre 2016 22:21:44 UTC+2, Ryan Sleevi a écrit :
> 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?

The job of a CA is not only to issue or not issue certificates, it's also to 
maintain revocation status for the previously issued certificates, receive and 
consider revocation requests from anybody, and revoke certificates the CA knows 
are not valid anymore (for a number of reasons listed in the BR at least in 
section 4.9.1.1).
It's agreed that revocation checking is far from perfect, and that's why Google 
and Mozilla have developed CRLSets and OneCRL, which depends on the revocation 
status information published and/or declared by the CAs.

It's then important that the Affected Roots and their subordinate CAs continue 
to follow good practices regarding revocation of subscriber certificates.
___
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&sa=D&sntz=1&usg=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 15:46, Gervase Markham wrote:
> 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."

I should add that if StartCom/WoSign have a CT log codebase capable of
taking the volume necessary, they could always open source it, and then
pay a 3rd party to run an instance of it, with an arms-length contract.
That sort of solution may well be acceptable, depending on contract details.

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

[Gervase Markham]

On 14/10/16 02:20, 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?

Log qualification is a Chrome concept - it means "suitable for being
trusted by Chrome". When and if Firefox supports CT checking, we may
also need our own list of qualified logs, which may or may not be
related to the Chrome list, and we would have our own requirements for
how many SCTs need to be included, which again may or may not be related
to Chrome's requirements.

But before those things happen, it seems inappropriate to me to place
restrictions on the choice of CT server based on Chrome's log list.
Google may do so, of course, but that's up to them.

We do, of course, require that the CT server not be defective - i.e. not
be proved to be evil :-)

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-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&Y. (If further issues are found with E&Y
> 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