StartCom remediation plan

[Inigo Barreira]

All,





In this link, https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf, you´ll find the detailed remediation plan for StartCom as was notified last week. It took us some time to have all the people needed for these tasks and clarify the dates for fixing all the possible findings.



StartCom considers this plan accurate and enough to the Mozilla community, specially for their users base, to regain and keep the confidence on our capacity as a trusted CA.





In the plan you all can see that regarding the PKI system, there are 2 actions based on timing, but always using the current roots, we may rethink, due to the email delivered by Mozilla yesterday, if the mid term solution has to be changed and instead of doing for the current roots, this has to be done for new roots, which would mean a longer delay because would need to almost start from scratch.



We´d like to hear from Mozilla in this regard and if so, would allow Startcom some more time.



Anyway, this remediation plan is to be executed by all means, but would like to be sure about the mid term solution.





Regards,

Iñigo Barreira

CEO

StartCom CA limited

[Inigo Barreira]

[Gervase Markham]

Hi Inigo,

On 14/10/16 09:16, Inigo Barreira wrote:
> In this link,
> https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf,
> you´ll find the detailed remediation plan for StartCom as was notified last
> week.

Thanks for this. Is this a correct summary of the situation as regards
the origin of the codebases?

Website/Ordering System

Before: WoSign-authored, but not the same as the one WoSign uses
After: Same WoSign-authored code, audited and improved by Qihoo R&D

CMS

Before: WoSign-authored, but not the same as the one WoSign uses
After: Same WoSign-authored code, audited and improved by Qihoo R&D

PKI

Before: WoSign-authored, same code that WoSign uses
After: StartCom-authored, improved by Qihoo R&D (short term)
Third-party solution (medium term)

OCSP/CRL

Before: WoSign-authored, same code that WoSign uses
After: Same WoSign-authored code, audited and improved by Qihoo R&D


>From my perspective, the "technical separation" part is more than just
"not using the same servers WoSign uses" or "not running the same code
that WoSign runs". One of the things we have lost confidence in is the
coding of the WoSign development team, and therefore any piece of code
remaining which they wrote is suspect - no matter whether it is
StartCom-specific or also run by WoSign.

Given that, it is concerning that after your plan is executed, 3 of the
4 key systems will still be running WoSign-authored codebases, even if
they have been audited and improved to some degree by Qihoo R&D. For
each system where that is true, I think that Mozilla may wish to require
a full external security audit, which would both be expensive and
time-consuming (and may lead to a great deal of remediation required).

Was consideration given to switching back to the old StartCom codebase,
or buying in a third party solution, for the website, the CMS or the
OCSP/CRL function?

Gerv

[谭晓生]

Dear Gerv,

We’ll rewrite all the code with different programing language or buy 3rd party components (for example: PKI), Wosign team using .Net, but my team never use .Net, they are good at C/C++ and PHP, Python.

Thanks，
Xiaosheng Tan



在 2016/10/14 下午11:01，“dev-security-policy 代表 Gervase Markham”<dev-security-policy-bounces+tanxiaosheng=360...@lists.mozilla.org 代表 ge...@mozilla.org> 写入:

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

[Gervase Markham]

Hi Xiaosheng,

On 14/10/16 16:06, 谭晓生 wrote:
> We’ll rewrite all the code with different programing language or buy
> 3rd party components (for example: PKI), Wosign team using .Net, but
> my team never use .Net, they are good at C/C++ and PHP, Python.

It would be great to be clear about what the plan in each case - whether
it's a "audit, check and review" of the existing codebase, or whether
it's a rewrite, or whether it's a 3rd party implementation.

The deadlines in the document are:

Website: Dec 31st 2016
CMS: Dec 31st 2016
PKI: Dec 1st 2016 (replace with StartCom version)
Feb 2017 (implement 3rd party)
OCSP/CRL: Dec 1st 2016

There are only six weeks between now and Dec 1st 2016. There is no way
your team, no matter how big or skilled it is, can safely and securely
write a new OCSP/CRL system in six weeks, and then finish a website and
a CMS four weeks after that. Even if Python is awesome ;-)

Gerv

[Han Yuwei]

在 2016年10月14日星期五 UTC+8下午11:23:10，Gervase Markham写道：

There's no any open-source solution? Maybe Mozilla could build one?

[Christian Felsing]

Am 14.10.2016 um 17:25 schrieb Han Yuwei:
> There's no any open-source solution? Maybe Mozilla could build one?

Hi,

maybe EJBCA (https://www.ejbca.org/) could be a solution for your problem.

Christian