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 decission of StartCom. Mozilla and the rest of the root programs can make comments or suggestions for sure, but can´t interfere. And this is not a matter of trust or something similar I´m reading here. And again, taking into account that the security of the end users have not been affected.

I´d also like to comment the issue regarding the CT, which I think is unfair, but let me explain:

- Firefox does not support CT yet

- All CT log servers operators out there have to follow the same requisites, for example, RFC 6962 up to now, and google requires some more requisites to be admitted into Chrome browser. These are the same for every CT log server operator independently who manages them

- There are additional tools, such as crt.sh, that are also valid to check out certificates

so and as stated in the plan:

- Before Mozilla asked, StartCom started publishing all their certificates in the CT logs

- In the document, you can see that for EV (and to meet google requisites) StartCom uses a google and non-google log server

- for the non-EV certificates, StartCom uses a google and non-google log server. These non-google log servers were announced to be include in release 54 (which has been already released)

- StartCom has been in touch with other CT log server operators but it´s complicated due to the number of certificates StartCom issues. Not all log servers accept these numbers for many reasons, i.e. performance because can´t create some delays that will affect its status in Chrome. Having said this, I´ve contacted Symantec to see how´s the current situation (were some talks in the past), also was commented the choice of using CNNIC log server (but maybe there are suspicions), and was planned to talk in person with Digicert.

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.

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. Maybe there are some additional steps to make or some other conditions proposed by Mozilla, but in general, I think this plan is good enough to be maintained in the Mozilla root program because it solves all the issues that have happened.

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.

Lastly, and now I´m finishing, also has been said about the transparent of the process, how different root programs work, a unique source of information, etc. I think this is good, but it´s only one leg, the information to provide to the root programs, but it will be good to have also another one listing the issues and the penalties. For example, something similar of what the EU Commission is doing with eIDAS and article 19, in which CAs have to communicate to their supervisory body (the equivalent of the browsers root program) all the incidents they have and then decide based on a specific procedure and with the help of a tool. ENISA is working in developing this tool and providing this procedure to all SB and TSPs, and this procedure is divided into different categories with different levels and possible issues that are going to be treated differently and with accordingly sanctions, from monetary to distrust. With this solution, all CAs will know in advance what will happen if you make a mistake and not treat them on a one-by-one case and applying different resolutions for similar incidents. The aim is to be the more objective possible.

If you think this option will improve the transparency of an open collaboration, I´m willing to help.

Best regards,

Iñigo Barreira


StartCom CA Limited

El 18/10/2016 a las 1:26, Kathleen Wilson escribió:

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 

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.

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 

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
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
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.
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 of the CAs?

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


dev-security-policy mailing list

Iñigo Barreira
StartCom CA Limited

dev-security-policy mailing list

Reply via email to