On Wed, Aug 31, 2016 at 07:57:02PM +0300, Eddy Nigg wrote: > On 08/31/2016 03:19 PM, Matt Palmer wrote: > >That bug appears to pre-date *all* of the certificates listed above. > >Further, the last communication on that bug (2014-09-22), from Eddy Nigg > >(of StartCom), said: > >>It's a hard and software related capacity issue of the queue managing the > >>certificates and the real solution will be only available after a hardware > >>upgrade we are planning for Nov-Dec this year. > >So that's presumably Nov-Dec 2014... and 12 months later, duplicate serial > >numbers were still appearing. > > Right, however we could limit this occurrence to a minimum at that time - an > entirely new infrastructure was in the pipeline already which solved the > problem completely. Please note that such infrastructures are fairly complex > and therefore also hard to deal with sometimes. I acknowledged in the bug > report that we were able significantly reduce this issue, though not > eliminate entirely.
That sounds an awful lot like "we can't fix our own systems", which is a... terrifying thought. > >It's somewhat disconcerting that the response from StartCom in that bug > >report was, essentially, a mixture of, "it's not our fault, the software did > >it" and "ain't no thang". To me, that isn't a particularly useful attitude > >for a CA operator. The correctness of the software which is deployed is of > >*crucial* importance to the trustworthiness of a CA. > > True, but as explained above, some more drastic changes had to be done in > order to correct this issue completely, not something done over night. The > corrective measure and eventual implementation was however there on the way, > even if it took some time. "Some time" being about a year longer than you stated it would take in the bug. That's quite some time. > Regarding our "attitude", even though this issue was certainly not desired, > it wasn't comparable to a wrongful issuance leading to possible abuse - some > client software would however stopped working when encountering a duplicate > serial. And to my assessment this wasn't a situation which required to take > an entire system down in order to "fix" it (which was necessary in this > case). You were knowingly violating a MUST provision of RFC5280. For clarity, would you mind listing any other MUST provisions of the relevant RFCs and standards which you are required to adhere to as a publically-trusted CA, just so the community can accurately assess your position? > >Is anyone aware of any attempts by StartCom to proactively report these BR > >violations to Mozilla or any other trust store operator, at or around the > >time of issuance? I don't see any mention of the 2015 misissuances in the > >most recent BR audit report (https://startssl.com/ey-webtrust-br.pdf), > >either. Does this mean that StartCom were unaware that they had issued > >these duplicate certificates, despite having a history of doing so, or did > >they mislead their auditors? > > Neither - the software wasn't designed to issue certificates with duplicate > serials, neither was that done knowingly or willfully. Since we are talking > about an occurrence of perhaps one in 40-50 thousand certificates or less, > it's not really something that can be measured by an auditor. What can be > measured are software design, actions performed, implementation of plans to > solve a particular issue. Ryan can handle this one better than I ever could: > The audit letter included an attestation from Management that, during the > time of the audit, management believed that the CA complied with the > Baseline Requirements. > > Management was aware of non-compliance, by virtue of revocation and system > and procedural changes to align with compliance. > > Thus, do you believe it was faithful and accurate for Management to warrant > that the CA was operated in compliance with the BRs, given that Management > was aware of incidents of non-compliance? - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
