I want to give you some words from one of the "community side" (this is a personal opinion and may vary from other opinions inside the community).
Trust is not something that you get, it is something that you earn. StartCom was distrusted because of serious issues with their old PKI and now had the chance to restart - there are serious issues again. I don't think that the "community" wants rogue CAs on its list just because they restarted with new certificates. - The fact that you were cross-signed by Certnomis before you had valid WebTrust Audits and the permission to issue trusted certificates again and that the only thing which prevented you from using the trust path is a PUBLIC certificate? Is the only thing that prevents me from entering your datacenter a sign which tells me not to do so and the fact that you did not tell me where your datacenter is located? - Startcom operates/operated multiple CT Log Server itself. There is absolutely no reason to use trusted certificates for testing purposes if he does have a testing infrastructure. It would be easy for you to add one of your testing roots to your CT Logs and then test your CT behaviour. I don't think that Googles CTs are different from your own ones. Though your certificates might not have been trusted at that time, they would be now and as Gerv said, test certificates are not allowed. If you did not care about compliance at that time, why should you care about it now? - There is a reason why Best Practices are called best practices. Why did you reuse your key in root and intermediate certificates? Because there is no money for additional HSMs? Because you don't know how to generate new keys? An explanation would be great. - P-521 are forbidden by Mozilla. Even if there is a discussion to change this it does not allow you to take that as a permission to test it. The fact that these certificates were reported as unrevoked at the time of reporting (as far as I remember) does imply that you do not monitor your certificate issuances for policy compliance at all. What do you do to ensure that all of your certificates are compliant with all requirements at all times? - What internal audits have you done to ensure the integrity of your systems? If something so critically as the permission to issue certificates in EJBCA is only noticed after you explicitly looked for it, what happens if someone removes all of your security mechanisms? You will find that out too after you misissued thousands of certificates? Quis custodiet ipsos custodes. - The incidents with Diginotar should have made clear that secure, well audited and hardened code is absolutely necessary as well as reliable logs. The fact that these flaws where not found by your internal team and only discovered after an external company tested your systems is deeply concerning. What have you done now and what will you do to ensure that your systems won't be abused? How do you make sure that the code your people write in the future is safe and how do you detect security problems if you were unable to do so at the first time? Though I would love to see StartCom up and running again, I have to agree with James that all of these issues do not enwake trust into you and instead produce more uncertainties if StartCom is really able to run a PKI itself. But as I said before, this is a personal opinion :) Am Freitag, 15. September 2017 16:38:25 UTC+2 schrieb Inigo Barreira: > > > Yes, you´re right, that was on the table and also suggested by > > > Mozilla, but the issue was that people from 360 are used to code in > > > PHP and the old one was in Java and some other for which they are not > > > so familiar and then was decided to re-write all the code in PHP > > > trying to keep the same functionality. > > > > Given the quality of code produced, > > I don´t think the quality of the code which is in production now is poor or > of bad quality. It wasn´t good initially, that´s true, but not now. > > > it might have been better in hindsight tohire Java experts to work on the > > old codebase. > > That was also on the table. > > > > > > Furthermore, with this decission, we also wanted to let the community > > > know that this is totally a new CA system in all aspects, nothing > > > related to the past, everything from scratch, so new coding, new > > > programming language, new PKI system, infrastructure, etc. hoping this > > > would make the community have a better impression of the new Startcom > > regarding the distrust issue. > > > > "We rewrote everything from scratch" is not actually something which itself > > inspires confidence. > > What I meant, is that we used a new programming language and then recoded. > > In the case of WoSign, it was required of them because > > their old code was clearly terrible and buggy. But the reason the result > > would > > have to be strongly audited (were they to > > reapply) is that new code is riskier than old, tried-and-tested code. > > > > I don't know if I ever wrote it down anywhere, but I'm fairly sure that > > switching back from the WoSign codebase to the older StartCom codebase > > (i.e. reversing the change you made after the purchase) was my suggestion > > for > > how StartCom should proceed after the dis-trust event. > > Yes, that was your suggestion. > > > That doesn't mean you are required to take my advice, > > Yes, I know > > > but it might have beena hint that I wouldn't consider "hey, we rewrote > > everything from scratch!" as > > a positive point. > > Well, we thought that it could be. During the distrust issues, I think Ryan > posted some old issues related to the old Startcom code or procedures (long > time ago) and then recoding everything was our intent to give a positive > answer. As said, the term "from scratch" maybe it´s not appropiate, but in > the end this code has been audited. > > > > Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
