On Jul 27, 2010, at 5:34 PM, Ben Laurie wrote: > 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. There is, of course, the problem of knowing when a signature was stolen! You can know that it was definitely stolen *by* a particular date, but never that it wasn't stolen earlier. Given that it was stolen, what evidence could you produce that it wasn't stolen - and simply kept around for later use - at the moment it was created?
Beyond that, you it's often hard to know when you received a file. Perhaps the actual attack was to stick it on your system and backdate it! A forensic examination could look at backups, but we're talking about how to decide whether to accept a signature in an operational setting. You can't, of course, rely on any dates within the file itself, as they are protected from fakery only by the signature that you can't trust. You could rely on a digital time-stamping service ... but that just brings into sharper focus the absurdity that actually began the moment you needed to check an on-line CRL. The only conceivable purpose for using a signature is that you can check it *offline*. If you assume you can connect to the network, and that you can trust what you get from the network - why bother with a signature? Simply check a cryptographic hash of the driver against an on-line database of "known good" drivers. This is right in line with Lynn Wheeler's frequent mention here that the use case for offline verification of certs for commerce basically doesn't exist. It was a nice theory to develop 30 years ago, but today the rest of the framework assumes connectivity, and you buy nothing but additional problems by focusing on making just one piece work off-line. -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com