On Wed, Dec 7, 2011 at 4:32 PM, Peter Gutmann <[email protected]> wrote: > > In the presence of such a [self-revoking] revocation [of a root certificate] > applications can react in one of three ways: they can accept the CRL > that revokes the certificate as valid and revoke it, they can reject the > CRL as invalid because it was signed by a revoked certificate, or > they can crash... > Um, the real problem is not revoking the root certificate but what other certificates to temporarily trust in the face of the revoked root certificate (In the past, I have chosen the simplest to code option of "none" but with the knowledge that things might break).
In a CRL that contains an element that revokes the CRL signing certificate, only that element can be assumed to be correct. All other list elements are suspect. If a self-signed CA certificate lands in that CA's CRL, then, of course the self-signed certificate can now be considered compromised. Either the original private key signed the CRL or the compromising copy signed it - both cases mean the root private key must be considered compromised. Of course, the second case means some malicious entity wanted to crash some piece of code that crashes in this case. I can't think of another reason the malicious entity would "out" themselves other than crashing buggy code. All other elements in that CRL, and, indeed, all CRLs dating back to the time of the compromise, might be invalid CRL elements. Code I have written in the past assumed those certificates were invalid even though they might not be. This was with full knowledge of the possible but unlikely denial-of-service attack (there are so many better things one can do with a compromised CA key then issue bad CRLs). Any CRL-based DoS attack doesn't need to last too long because the CA can issue new certificates signed with a new key in short order - getting the new certificates including the new root certificate distributed, of course, can take more time. ---- -Michael Heyman _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
