On 01/09/2016 10:52, Nick Lamb wrote:
On Thursday, 1 September 2016 08:54:16 UTC+1, Eddy Nigg wrote:
Not so, rather according to my assessment, the cost and everything it
entailed (including other risks) to fix that particular issue outweighed
the benefits for having it fixed within a time-frame shorter than that.
It seems to me that was not your decision to make. The relying parties trust StartCom on
the basis that it will do what it said it would do, not just whatever "in your
assessment" offers most benefits to you. The only option that was permissible
without seeking some exception was to cease issuance until the problem was repaired.
To StartCom, ceasing issuance feels like a really big risk, that is understood.
But for the relying parties it's not. StartCom could go out of business
tomorrow and the relying parties see almost no impact from that. So for them
your risk/ reward trades look very different. You must understand this and act
accordingly.
I do not represent either side in this (though I am a relying party).
However I think a key distinction would be between 4 degrees of badness:
1. Violations that would cause relying parties to trust valid-looking
certificates that the CA doesn't even know about (e.g. CA private key
compromise), probably not the case here.
2. Violations that would cause relying parties to trust valid-looking
certificates that the CA erroneously issued to a wrong party.
3. Violations that involve misissuance of valid-looking certificates in
ways that provide no actual danger of misuse (because the named entity
doesn't exist or the certificate recipient was subsequently verified
not to have used the certificate etc.). An example would be the
incorrectly issued Symantec test certificates many moons ago.
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.
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.
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.
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.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
