Hi, 

1.- yes, I said many times that it was not a good decission and of course not 
the best way to start, but at all times these test certs were under control, 
lived only for some minutes. Everything was explained in bugzilla #1369359 

2.- Those pre-certificates were related to these test certificates for the CT 
testing, and yes, technically they didn´t exist for EJBCA, so we were dealing 
with them on how to revoke them without issuing them wrongly and finally got a 
solution, and then inmediately revoked them.

So, these two issues were related to the same generic problem, the CT testing, 
which was only for Chrome compliance, but that were all the time controlled by 
us. It was a bad practice that it´s not happening again with the 
countermeasures set as explained. 

3.- No, there´s nothing related to Wosign nor Richard Wang. As indicated in our 
remediation plan, 360 owns 100% of StartCom and we´ve performed all the changes 
proposed there to have nothing related to Wosign nor Richard. This is indicated 
in bugzilla #1311832 and also in the remediation plan delivered last year.
Also in our remediation plan, there was a chart in which was indicated how the 
Company is structured, and in the case of StartCom Spain, this is 100% owned by 
the StartCom UK, and I´m director in both offices.

And the reason why Richard Wang is director again in StartCom UK is due to some 
bank issues. Richard was removed as director of the StartCom UK at that time, 
but didn´t realize about his signatory rights in the UK bank account. We 
thought we could change that easily but was not possible. We´ve been dealing 
with our lawyers, Alliotts, and finally agreed that signing again Richard was 
going to be quicker and easier. I had planned to go to London for changing it 
end of july, beginning of august but due to some personal matters, it was 
imposible and have had to delay until September. Once we finish this bank 
issue, Richard will be removed again.
In any case these are internal issues that don´t affect the PKI itself, these 
are administrative tasks, but the fact that Richard is again director in 
StartCom UK is just for this matter and has no other responsibility or function 
within StartCom.


Let me know if you need more clarification or have some other doubts or 
questions

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-----Original Message-----
From: dev-security-policy 
[mailto:dev-security-policy-bounces+inigo=startcomca....@lists.mozilla.org] On 
Behalf Of Jakob Bohm via dev-security-policy
Sent: lunes, 7 de agosto de 2017 22:03
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis

On 07/08/2017 11:21, Franck Leroy wrote:
> Hello
> I see many reactions that are not in line with the reality because you don’t 
> have all the history on the subject.
> I’ll try to summarize.
> Approximately one year ago Inigo was CTO of Izenpe (CA of the Basque Country) 
> and he left this company in order to join StartCom.
> Not long after he arrives at StartCom (days? Weeks? I don’t know) we discover 
> the deal that has been made by the previous CEO (Eddy Nigg) with the 
> Chinese’s guys and the relations with WoSign.
> Inigo could have resign in regard to the trap the hiring was, but he decided 
> to face, and to setup the remediation plan defined by Mozilla community.
> As said Jon Snow in S07E01: “I will not punish a son for this father’s sins”.
> So instead of denigrate Inigo’s work, as a community we should encourage and 
> support him.
> Setting up a new company, with a new datacentre, new pki software, NO 
> client, NO revenue, with Chinese employees far away speaking not fluent 
> English and with the pressure of the market, it is definitely not an easy 
> task! Personally I would not have tried this, so bravo for Inigo’s bravery… 
> One of the major thing to solve in addition of the remediation plan was to be 
> back in the business as soon as possible, because without any incomes a 
> company cannot survive.
> So Inigo contacted me to know if Certinomis could help him to be back in the 
> business. As you can imagine we did not said yes immediately.
> But Inigo is not an anonymous guy coming from a strange area of Spain. He has 
> been for many years an active CABForum member. He is also an active expert at 
> ESTI, where he was editing the CA policy for web authentication certificates. 
> Inigo is known for his expertise, trustworthiness, honesty and not the least 
> his sympathy. So when he said that he will build a new StartCom and engage 
> the remediation plan, we could trust him.
> We are a community, not only in order to do the “police” but also to support 
> each other’s. So my answer was “yes, we will see how we can help you in 
> respect with community expectations”.
> There was different possibilities to be back in the business while waiting 
> for a brand new CA root included in the browsers; reselling Certinomis 
> certificates, becoming a Certinomis RA, creation a StartCom subCA under our 
> root using our technology or a cross-signing operation on new StartCom sub 
> certificates.
> The cross signing was not the very first option we studied because it 
> requires that the new StartCom infrastructure be ready. But the other options 
> were not so trivial, in a technical point of view but also in the context of 
> restoring StartCom trust.
> Then in November 2016 I contacted Kathleen and Gerv to know if there was some 
> stoppers to work with Inigo to help StartCom to be back in the business.
> There was no opposition as long as we follow the requirements of the 
> remediation plan. Gerv also answered that our plan was good to him.
> So with Inigo we studied the different possibilities and finally, taking into 
> account cost and delay, the more efficient solution was cross signing new sub 
> certificates from a StartCom full new pki with CT log and get this audited.
> On April 2017 the new StartCom datacentre with EJBCA pki software were ready, 
> and StartCom was able to create a new root and some sub CAs.
> Then Inigo work on the CT log activation in the EJBCA software, not an easy 
> task, and the bugs to solve. He also engaged the webtrust audit with PwC.
> On April it was also the mouth when Certinomis had planned to use its offline 
> root in order to sign the authority revocation list (ARL, the root CRL). So 
> there was an opportunity to save money by also cross signing StartCom CAs 
> during this operation. But it was strictly clear with Inigo that we will not 
> give him the certificates as long as the remediation plan is not completed.
> By the end of June the audit was completed and so Inigo send me the report on 
> July 3rd.
> I sent it to Kathleen to be sure that the auditor company was an acceptable 
> one and that the editor’s opinion was in line with the Mozilla policy. 
> Kathleen pointed out some minor issues, so I asked Inigo to correct them.
> By mid July Inigo had corrected the remaining minor issues, he published the 
> updated policies and audit assessment report on StartCom web site (July 
> 14/07) and updated the remediation bug (1311832) stating that all remediation 
> steps where achieved (17/07).
> Back from vacation on August first, I read Inigo’s emails, checked the 
> StartCom policies, audit report, remediation bug progress, and it appears 
> that every steps was done. So I asked a confirmation to my management to let 
> StartCom having the cross signing certificates.
> The day after I received the go from my management, so I filled the CCADB 
> with all the corresponding information: policies, practices, audit dates, 
> audit report, certificates fingerprints… And then sent to Inigo the cross 
> signed certificates.
> 
> It appeared that some people think that there is a policy violation about the 
> delay for CCADB disclosure.
> Maybe I misunderstood the policy requirements on the subject. I really took 
> care that no certificates could use the path to our root (by holding the 
> certs in my safe) until all remediation steps were met. So I’m very sorry 
> about this misunderstanding and I apologize to you.
> But in my opinion, asking for a revocation without a full understanding of 
> the situation, is not a balanced and a fair answer.
> 
> If you have any other question, I’ll do my best to answer (sorry for the 
> basic English but I’m not English native nor English fluent).
> 

As an "outside" observer, I would say that it would have been better if the 
following additional things had been done:

1. At StartCom: The various tests should have been done with a dedicated
   "test hierarchy" running on the production hardware but not chaining
   to the intended production roots.  This could also become a long term
   test hierarchy for e.g. new software versions.

2. At StartCom: Remember to revoke certificates that get cancelled
   between CT logging and actual issuance.  I don't know if EJBCA can do
   this without actually issuing the bad certificate, but hopefully there
   is a way.

3. At Certinomis: Be more public up front about the "sealed" signing of
   the cross certificate.  Also, I am not sure how often your ARL signing
   ceremonies happen, but if its every 3 months, the signing could have
   happened in July instead.

4. At Certinomis: Maybe the cross-cert should have been post-dated to
   a date when StartCom expected to be ready (as communicated privately).

5. At StartCom, Mozilla and Google: Should have been more clear if the
   remediation plan did or did not require StartCom to seek
   Mozilla/Google prior approval before getting cross-signed (if such
   cross-signing were to occur before Mozilla approval of the new roots).

6. At StartCom: Be more clear if any of the "Chinese" staff is working
   at, under or otherwise near WoSign and/or Richard Wang.

7. At Quihoo: Actually get rid of Richard Wang, not just change his
   title from CEO to COO.



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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to