> > 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)?
I think I provided the reasons. We were distrusted, not re-applied yet, those certs lived for minutes, ... So, I think these are the reasons. It´s not an excuse and we didn´t expect this maremágnum. There´s been long discussions about the harm long term certificates can make and asked CAs about short term to avoid damages. These certs, that it´s true was a mistake, only lived for minutes, so I don´t know what else I can add to this matter. > > > 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. Yes, you´re right. And it was my fault for not have checked in deep this particular one. > > > 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. Yes, right, but this is allowed afaik. It´s mentioned in the BRs. > > >> * 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. There wasn´t a lack of integrity and monitoring, of course not. All PKI logs were and are signed, it´s just the auditors wanted to add the integrity to other systems which is not so clear that should have this enabled. For example, if you want to archive database information for not managing a big one, the integrity of the logs could be a problem when trying to "move" to an archive system. I had some discussions about the "scope" of the integrity. Regarding the monitoring, well, we monitor many things, in both data centers, 24x7, etc. For this specific issue, it´s true that we didn´t have it automatically but manually, but well, and we implement a solution, but this is not a lack of monitoring. I think the audits are to correct and improve the systems and don´t think any CA at the first time had everything correct. So, for example, I thought this finding was good because made us improve. > Repairing them afterwards does not remove the uncertainty. Well, then any issue that you could find, even repaired or fixed, does not provide you any security and hence you should not trust anyone. > 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. Well, I don´t think this is the same "quality" of example. > > > 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. Yes, it´s an overstatement but similar to others. I said that I didn´t know what or how they had applied but you put them as examples and just wanted to indicate that there were discussions, so maybe was not so smooth, but again, I don´t know. > > > 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. No, or not totally. We have issued those certs but not cross-signed by Certinomis because we didn´t have the cross-signed certificates so, all of them were issued under the new startcom hierarchy > > > 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. Well, maybe not Mozilla but we were talking during the F2F meeting in Seattle about options and that one was put on the table > 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. This is something I don´t understand. Why do you say the audits I presented don´t meet the BRs? Because of the findings? The auditors indicate those were fixed About the remediation steps, well, I answered the bug about it providing all the info and yes, you haven´t answered yet nor to approve nor to deny. > > > 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 wanted a clean audit for sure, but I think this also shows our transparency for it. We had findings, those were fixed. > > > 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? No, it´s from the new hierarchy. > > 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. Certinomis only cross-signed the new hierarchy, in fact, the subordinate CAs not the root CAs, so does not implicit trust the old hierarchy. > > > 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? It was in an email of sept 4th, titled "StartCom communication" in which at the end of the long email I asked for feedback to use the cross-signed certificates and give additional explanations > > > 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. I´m not agree with this. It´s true that the development methodology and speed were not good the first time but that´s not said in the second one. The methodology was changed same as framework > > 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
