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.
Jon
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
