Hi Inigo, On 14/09/17 16:05, Inigo Barreira wrote: > Those tests were done to check the CT behaviour, there was any other testing > of the new systems, just for the CT.
Is there any reason those tests could not have been done using a parallel testing hierarchy (other than the fact that you hadn't set one up)? > Some of these "mis-issuances" were due to some incongruencies between the BRs > and the Mozilla policy, such as the use of different curves (allowed by the > BRs but not for some browsers), But it is the job of a CA to be aware of browser policies. > As far as I know, the current manager of Startcom has not been previously > accused of deception or bad action. No, indeed. There is no accusation that you have been deceptive towards anyone. > Yes, it´s not a policy violation. As explained, this was a problem in the > EJBCA with the UTF8 encoding. That was the reason for the revocation; it's not the reason for the key reuse. >> * The WT/BR/EV audits on StartCom's website are significantly qualified, and >> they include lack of controls on issuance. They should have clean ones done >> before we permit any inclusion request to proceed. The qualifications >> include: >> >> - Risk analysis process defined but not implemented >> - Business continuity plan defined but not implemented >> - Audit logs not guaranteed to have integrity >> - Monitoring system cannot detect security-related changes to >> Certificate Systems > > Yes, this is also true. Our webtrust audits have findings but those are not > so significant according to the auditors who signed the reports, so I assume > the auditors thought that the system is good enough to have the audit report > in place. I think lack of monitoring and lack of integrity of logs are serious issues. Repairing them afterwards does not remove the uncertainty. If you said "I left the root certificate private key on a USB stick on the desk in my unlocked office over the weekend - but it's OK, I've remediated the problem now, and it's back in the safe", that would not remove the uncertainty about whether someone had done something with it in the mean time. > I don´t know how these you mention have applied, but I remember lots of > issues regarding Google and the acquisition of the Globalsign roots and how > they proceeded. I think "lots of issues" is an overstatement. There was an issue regarding the scope of their audits which was raised publicly, but it was something that Google has explicitly sought our approval for in advance. > Not sure about this. We were distrusted in october 2016, the new system > started to operate in april 2017, which is not related to the old one which > has been switched off. None of the new certs are trusted in Mozilla Firefox > and we notify our users so by messages in the web and applications. I may have made a mistake here. I was under the impression that you had told me that your new hierarchy, cross-signed by Certnomis, had issued 50,000 certificates. Did I misunderstand? If so, my apologies. > Ok, I see this is a new requirement that was not imposed last time in which > you recommended and allowed us to be cross-signed as many other CAs have done > in the past to be in the business. Mozilla did not recommend that you be cross-signed. Certnomis raised the possibility, and we said that it could happen when you had met the BRs and completed the remediation steps. The plan we "approved" was not a cross-signing plan. The audits show you haven't yet met the BRs, and we have not yet signed off on you having completed the remediation steps. > We´ve met all the conditions, new system, new management, security audit and > webtrust audit and CT logging. In those conditions, it was not mentioned that > the webtrust audit should be clean Isn't that implied? > I´ve never said this. In fact, despite having that cross-signed which were > provided to us in july we have never used and provided to any of our > customers to build a trusted path. So none of those 50000, or the new ones, > go with the Certinomis path because none have it. But all those 50000 certs > are untrusted because we´re not in the Mozilla root, not the new one, and the > old one was distrusted. So the 50,000 certs you mentioned are issued in your old hierarchy, which is not cross-signed by Certnomis? If you could clarify the numbers for your old and new PKI, and confirm that the Certnomis cross-signs apply only to the new one, that would be helpful. Again, apologies for any misunderstanding on my part. > In fact, recently, I asked for permission to use the Certinomis cross-signed > certificates and have no response. I don´t know if this is an administrative > silence which may allow me to use it but until having a clear direction we > haven´t used it. Can you remind me how you asked and when? > I think this has been explained. I don´t understand why you say it´s a "poor > quality PHP code". Because poor quality PHP code does not become good quality PHP code by applying security fixes to it. I am talking about the development metholodology and speed which were evident from the Cure53 report. Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
