[cryptography] How are expired code-signing certs revoked?
jon at callas.org
Wed Dec 7 12:34:29 EST 2011
On 7 Dec, 2011, at 8:52 AM, Steven Bellovin wrote:
> On Dec 7, 2011, at 11:31 23AM, Jon Callas wrote:
>> But really, I think that code signing is a great thing, it's just being done wrong because some people seem to think that spooky action at a distance works with bits.
> The question at hand is this: what is the meaning of expiration or revocation
> of a code-signing certificate? That I can't sign new code? That only affects
> the good guys. That I can't install code that was really signed before the
> operative date? How can I tell when it was actually signed? That I can't
> rely on it after the specified date? That would require continual resigning
> of code. That seems to be the best answer, but the practical difficulties
> are immense.
I want to say that the answer is "mu" because you can't actually revoke a certificate. That's not satisfying, though.
I think it is a policy question. If I were making a software development system that used certificates with both expiration dates and revocation, I would check both revocation and expiry. I might consider it either a warning or an error, or have it be an error that could be overridden. After all, how can you test that the revocation system on the back end works unless you can generate revoked software?
On a consumer-level system, I might refuse to install or run revoked software; that seems completely reasonable. Refusing to install or run expired software is problematic -- the thought of creating a system that refuses to work after a certain date is pretty creepy, and the workaround is to set the clock back.
But really, it's a policy question that needs to be answer by the creators of the system, not the crypto/PKI people. We can easily create mechanism, but it's impossible to create one-size-fits-all policy.
More information about the cryptography