Ben Laurie <b...@links.org> writes: >On 24/07/2010 18:55, Peter Gutmann wrote: >> - PKI dogma doesn't even consider availability issues but expects the >> straightforward execution of the condition "problem -> revoke cert". For a >> situation like this, particularly if the cert was used to sign 64-bit >> drivers, I wouldn't have revoked because the global damage caused by that >> is >> potentially much larger than the relatively small-scale damage caused by >> the >> malware. So alongside "too big to fail" we now have "too widely-used to >> revoke". Is anyone running x64 Windows with revocation checking enabled >> and >> drivers signed by the Realtek or JMicron certs? > >One way to mitigate this would be to revoke a cert on a date, and only reject >signatures on files you received after that date.
This wouldn't make any difference, except for the special case of x64, signatures are only verified on install, so existing installed code isn't affected and anything new that's being installed is, with either form of sig-checking. In any case though the whole thing is really a moot point given the sucking void that is revocation-handling, the Realtek certificate was revoked on the 16th but one of my spies has informed me that as of yesterday it was still regarded as valid by Windows. Previous experience with revoked certs has been that they remain valid more or less indefinitely (which would be really great if CAs offered something like domain-tasting for certs, you could get as many free certs as you wanted). The way to revoke a cert for signed malware is to wait 0-12 hours for the malware signature to be added to AV databases, not to actually expect PKI to work. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com