On Monday, September 18, 2017 at 11:38:57 AM UTC+1, Inigo Barreira wrote: > > > > 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. > > True > > > 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? > > Those certificates were not trusted at that time and can´t be now because > they were revoked within minutes. > > > > > - 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 nomoney for additional HSMs? Because you don't know how to > > generate new > > keys? An explanation would be great. > > A new thread has started about this. It´s not forbidden. > > > > > - 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? > > At the time of application, the certificates were revoked and countermeasures > set and since then there´s no more issues. We have implemented cablint, > crt.sh, ... and some other tools into our issuance process and still trying > to improve much more. > I´m not trying to excuse we had issues but we corrected them. > > > > > - 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. > > Despite all the terrible systems we have, etc. we haven´t misissued thousands > of certificates, nor hundreds. The issues we had, have been fixed. Those > test certs issued directly from the EJBCA was a mistake, explained many > times. I have nothing to add to what I´ve already said. It was not a good > decission, not a good practice, and it´s forbidden. > > > > > - 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? > > This is a different example, Diginotar was attacked and the attacker was able > to enter in their systems, and this is not what happened with StartCom. As > said, the code that went live is not the same that was audited the first time > and has been improved since then. The audits are just for that, and we will > continue doing yearly security audits to improve our systems.
Why not open-source the code on GitHub and let us be the judge of the improvements made to your systems code? Lets encrypt does this and works successfully. > > > > 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 > > [email protected] > > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
