> > 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. > > 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
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
