On 09/02/2016 09:38 AM, Jakob Bohm wrote:
4. Violations that are purely technical but cannot actually endanger
relying parties (such as issuing non-unique certificates to the correct
entities, or issuing certificates with too early expiry dates). This
would be the case with the StartCom serial number assignment bug.
The way Eddy Nigg describes the issue, it appears there is some kind of
low level race condition in the code or hardware that increments and
uses the serial number counter deep inside the CA, perhaps in a heavily
locked down HSM that prevents fixing the issue without generating a new
CA key.
You are pretty close....
If this is the case, and they correctly store the actually issued
certificates with the wrong serial numbers, the main problem would be
the inability to revoke one certificate without revoking the others,
while a secondary problem could be relying parties rejecting the
certificates if they actually see more than one of a set of conflicting
ones within their local cache lifetime. Since both of those problems
would be limited to the certificates not being trusted when the facts
that should get them trusted are in place, there is no real danger.
You nailed it - I just asked the question about how it affects relying
parties in an other reply to the list, you answered already.
StartCom is of cause one of those high speed DV CAs, that promise cheap
DV issuance within minutes of the request being submitted. So
preventing occasional non-dangerous (but obviously non-compliant)
serial number collisions would require more than average skill by
hardware, firmware and software engineers.
True - and this was planned AND implemented.
That said, they really, really should have set up an automated test
script that scans issued certificates for the problem and raises an
alarm so such certificates would be reissued (with distinct serial
numbers) and revoked within a few days of each failure.
True that we could have done what you suggested. I don't really recall
why we didn't, though I think things got easier with CT today for
similar issues.
The fact is that it didn't had really an effect on the certificate
holder or relying parties (except in case of a revocation in which case
both certificates would have been revoked and probably issued again
depending on the circumstances of the revocation).
--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP: start...@startcom.org <xmpp:start...@startcom.org>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
