On 5/21/05, Ian G <[EMAIL PROTECTED]> wrote:
If a root key is compromised and a certificate status server responds as such the only way to undo the revocation is for the bad guy with the private-key to prevent access to the responder, or spin up a new one which answers differently (he has the root after all). This is farily sophisicated as it requires coordinating a few different attacks and yet yields a relatively small reward - something this big would likely result in a browser update within a few days and so the opportunity is relatively small; given how many other easier attacks are out there I would be surprised if anyone bothers to do this against a well protected root such as by seven tiers of physical security (including multiple orthogonal dual-control or better systems) in order to reach an (always non-network connected) offline root in FIPS 140 hardware that uses threshold to active. It's just not the weak-point and certainly not an economical attack point if you only trust roots with (ridiculously) good protection policies ;)
On Saturday 21 May 2005 00:41, Julien Pierre wrote:
> Ian G wrote:
> >>But OCSP/CRL can not help in case of *root* cert compromission.
> >>There's nothing above it to sign the validity information.
> >
> > Can't it revoke itself?
> Revocation checks cannot be done at the root level, by definition.
This is an interesting topic and I think Julien does a
decent job of describing the issue. The recap is: if a bad guy has a
copy of a certificate issuer's private-key and he attaches a CRL
listing his own key as good with every signed message, who do you
believe?
> Please explain how you would make it work. If the root's private key has
> been compromised (which is one of the common reasons for cert
> revocations), then anybody could make a fake CRL, or run a fake OCSP
> server with that key that would all say that the root cert OK, even
> though clearly, it's not.
Yes, of course anyone can make a fake product
once they have the root, which is why the revocation
(signed by the same key) needs to be distributed.
Presumably once a revocation is sent around the
place, it is sticky, it itself cannot be revoked?
If a root key is compromised and a certificate status server responds as such the only way to undo the revocation is for the bad guy with the private-key to prevent access to the responder, or spin up a new one which answers differently (he has the root after all). This is farily sophisicated as it requires coordinating a few different attacks and yet yields a relatively small reward - something this big would likely result in a browser update within a few days and so the opportunity is relatively small; given how many other easier attacks are out there I would be surprised if anyone bothers to do this against a well protected root such as by seven tiers of physical security (including multiple orthogonal dual-control or better systems) in order to reach an (always non-network connected) offline root in FIPS 140 hardware that uses threshold to active. It's just not the weak-point and certainly not an economical attack point if you only trust roots with (ridiculously) good protection policies ;)
