Hi all,

 

I´ve realized that there has not been a good communication path to announce
all the tasks and actions performed by StartCom during this time and this
email will try to remediate it. I´d also like to ask you for some feedback,
comments and/or suggestions on how to improve. I think we´ve done a great
effort and developed a robust system but it´s also true that we have had
some errors even though all were fixed timely (despite the discussions that
are still alive regarding some of them) and put all the countermeasures
needed for not happening again. 

 

Thanks for all your suggestions and comments. I will try to summarize
everything.

 

Areas

 

1. Remediation plan

 

a. Legal structure and management separation

b. operations separation

c. system separation

d. CT logging

 

2. Mozilla requirements (bugzilla #1311832)

 

a. provide a list of changes

b. implement changes and update CP/CPS, stating explicitly backdating is
prohibited

c. providing full webtrust audit

d. security audit

e. All certs CT logged, if possible not using own CT log

 

3. Issues

 

a. test certificates

b. pre-certificates for test certificates

c. use of specific curves not allowed by Mozilla but BRs

d. Country code

e. RSA parameters

f. Unicode vs punnycode

 

4. Improvements

 

a. apply newest version of EJBCA v6.9.0

b. integrate cablint/x509lint in CAProxy

c. check of CSRs

d. integrate crt.sh in database

 

 

1. Remediation plan

This is what StartCom planned to do and was indicated last year in October.
It was presented to Mozilla and also in an email sent to the m.d.s.p

These are the main tasks performed, which are also included in bugzilla
#1311832

 

a. Legal structure and management separation

StartCom HK, which is the main head of the group, is owned 100% by Qifei
International development Co. Ltd in HK, which is also controlled 100% by
360 technology Inc. In november 2016, there were some news indicating the
completed transer of 100% shares from WoSign to Qihoo 360, so StartCom
officially became a wholly owned subsidiary of Qihoo 360.

So, there´s no control from Wosign related to StartCom.

 

StartCom has offices at China, UK, Israel and Spain.

Besides there was a change in the management in which Xiaosheng Tan of 360
was named chairman of the board and Iñigo Barreira, CEO.

Richard Wang has no relation, control nor influence in StartCom. It was
removed from the StartCom directors at the UK office last year. (Note:
recently had to be named again due to some issues related to the bank that
have been already fixed and hence removed again)

 

b. Operations separation

All operations are performed by Startcom employees, from own premises.
There´s no relation at all with any other Wosign operations or departments.

All validations, support and customer service is provided by StartCom. 

Besides StartCom signed a contract with 360 to provide hosting services of
the PKI infrastructure (CA, VA, TSA, CT, CMS, HSM, web,…), maintenance and
support, as well as developing, testing, etc.

 

c. System separation

All systems used for the PKI has been updated or directly changed and all
are hosted in 360 premises as stated above. 

 

Web and CMS have been totally updated, recoded under another programming
language, PHP, for which 360 is more familiar with. This coding has been
performed by the 360 R&D team and checked later by its security team. Cure53
was the firm hired for the security audit.

 

OTOH, StartCom finally decided to acquire the Primekey´s PKI solution,
EJBCA. We considered a significant step forward use this commercial PKI
software, well known in the industry.

Furthermore, the StartCom OCSP also uses the Akamai CDN as well as some
other services.

 

d. CT logging

StartCom logs all SSL issued certificates in CT logs. Currently we´re using
Google CT logs and also StartCom CT log.

We´re also planning to use Comodo CTs Mammoth and Sabre as well as the new
Venafi one.

 

2. Mozilla requirements (bugzilla #1311832)

 

a. provide a list of changes

The remediation plan was the whole list of changes that were presented to
Mozilla and they were agreed with that plan.

 

b. implement changes and update CP/CPS, stating explicitly backdating is
prohibited

All those changes have been implemented as per the remediation plan stated
above. The CPS was updated accordingly

 

c. providing full webtrust audit

The full webtrust audits have been performed by PwC. StartCom did a Webtrust
for CA, webtrust BR, webtrust EV and webtrust for CS. There were some
findings, which are reflected in the reports, but most of them were fixed.
Right now only the configuration of the TSA and the update of the Business
Continuity Plan are delayed, which in any case, will be finished soon. 

 

d. Security audit

For the security audit Mozilla recommended 2 firms they worked with them in
the past and finally hired Cure 53. 

 

e. All certs CT logged, if possible not using own CT log

StartCom logs all the SSL certs issued. For not using our own CT log as
requested, we contacted other CT log providers to know if they were willing
to accept our certs. We contacted CCNIC, Symantec and Digicert and in some
were refused and some didn´t answer. Recently contacted Comodo and accepted
us. Also checked the Venafi 2 log.

 

Note: the logging of all issued certs were done in different steps, firstly
we started with EV (because we issue very few), and gradually when realized
that everything worked fine, move to the other certificate types, OV, IV and
finally DV, and hence, there are some delays from the first one logged, and
EV, and first DV logged. We´re working in a solution to log all those issued
not logged.

 

3. Issues

 

a. Test certificates

It´s been detailed in bugzilla #1369359. There´s an attachment with a
detailed explanation what happened, when, who, what was done to remediate
and to avoid it happening in the future. Those certs were all the time under
our control and lived for some minutes while testing the CT behaviour.

Actions: removed issuance rights for the CA administrator

 

b. Pre-certificates

It´s explained in bugzilla #1386894. Perhaps I was wrong with the word
“intent” and then no need to revoke as they were not real certificates, but
once we had to do it, had to work with Primekey to revoke those certs,
because they didn´t exist for the EJBCA system as they only have
certificates, not pre-certificates. 

Actions: all pre-certs revoked 

 

Recently there are some emails threads in the m.d.s.p as if these
pre-certificates should be considered certificates, what to do with them,
etc. If the same rules of 24h revoking time applies, … so I think it would
be good to have same/similar/specific requirements for these certs.

 

c. use of specific curves not allowed by Mozilla but BRs and errors related
to this like unallowed key usages for this.

This is also covered in bugzilla #1386894. 

According to the BRs, the use of other curves, like P-521, are allowed but
not in Mozilla, so dediced to revoke them and put countermeasures to avoid
them again. We´re not allowing the use of those curves.

Additionally to this, the use of those curves implied a change in the
profile because of the different key usages, the key encipherment instead of
the key agreement, and double checked the profiles defined in the EJBCA
system. 

Action: denied the use of these curves and double checked of the profiles in
the system

 

d. Country code

There was an issue with an old country code for Zaire, which changed the
official name to the Democratic Republic of Congo. Once realized of the
error, revoked the cert, and replaced with a new one correctly. 

Actions: reviewed the whole list of ISO country codes and updated our
Database accordingly. 

 

e. RSA parameters

One of the certs had an error, as stated in https://crt.sh/?opt=cablint
<https://crt.sh/?opt=cablint&id=160150786> &id=160150786

We revoked the certificate when were informed as the first step in this case
and started to investigate that error and why happened. We contacted
Primekey and they didn´t control/check that at the issuance, then decided to
implement a solution in our CMS system to check the CSR files

Actions: application developed to check CSR before sending to EJBCA

 

f. Unicode vs punnycode or bad characters in domain names

This issue has been replied in the m.d.s.p email list and are also covered
by bugzilla #1386894 and also recently requested in
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/D0poUHqiYM
w/Pf5p0kB7CAAJ

Well, for this particular case in which has been some discussions in CABF
(one ballot failed) and in the m.d.s.p mailing list, we revoked those certs
timely and changed our system to convert them to punnycode.

Actions: all “non-standard” domain names changed to punnycode 

 

 

4. Improvements

 

a. apply newest version of EJBCA v6.9.0

Primekey has just released the new version of EJBCA, v6.9.0 (end of august).

This new version comes with some important improvements, such as:

-          CAA automatic checking

-          Perform public key validation (RSA and ECC) 

 

b. integrate cablint/x509lint in CAProxy

These tools have been integrated at the issuance process. We´ll check all
certificates issued and will send an email internally to act accordingly,
i.e, revoking the cert and to start an inmediate investigation of the error.


 

c. Check of CSRs to avoid the error “RSA keys must have a null parameter”
and integrate&configure EJBCA new release 6.9.0 wich also comes with a Key
validator for RSA and ECC.

 

d. integrate crt.sh 

Developed a script to check automatically the crt.sh database daily to
inform of any possible error that has not been controlled.

 

 

Finally, I´d like to also request feedback on the use of the cross-signed
certs by Certinomis. As per the disclosing according to the mozilla policy
within one week, I think this requirement was set in policy version 2.5,
which was not published nor required at the time when those certs were
created so Certinomis acted correctly.

As Franck has explained they retained those certs until we got the Webtrust
certification and you can check that we haven´t issued any certificate with
that chain, firstly because we didn´t have them and later, when disclosed,
because there were some doubts. 

 

Please, feel free to make any question, suggestion and/or request more
information regarding any of the points. If you need additional details
don´t hesitate in asking. 

 

Best regards

 

Iñigo Barreira

CEO

StartCom CA Limited

 

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

_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to