[cryptography] How are expired code-signing certs revoked?
jon at callas.org
Wed Dec 7 15:10:25 EST 2011
>> 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?
> I'm not sure what you mean.
By policy, I mean that you decide what it's supposed to mean, which is what you get to at the end of this.
But in the rest of paragraph reflects that I am a systems developer and if I am trying to debug why something that is revoked is (or isn't) working when it shouldn't (or should), then I have to create things that are error conditions.
I also once worked on a secure microprocessor, and there were many ways to permanently kill it.
>> 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.
> Yup. In fact, it's more than creepy, it's an open invitation to Certain Software Vendors to *enforce* the notion that you just rent software.
I know I wouldn't buy such a system.
>> 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.
> Right now, I'm speaking abstractly. I'm not concerned with current PKIs or pkis or business models or what have you. If you'd prefer, I'll rephrase my question like this: Assume that there is some benefit to digitally-signed code. (Note carefully that I'm not interested in how the recipient gets the corresponding public key -- we've already had our "PKI is evil discussion" for the year.) Given that there is a non-trivial probability that the private signing key will be compromised, what are the desired semantics once the user learns this. (Again, I'm saying nothing about how the user learns it -- CRLs or OSCP or magic elves are all (a) possible and (b) irrelevant.) If the answer is "it depends", on what does it depend? Whose choice is it?
> Let's figure out what we're trying to accomplish; after that, we can try to figure out how to do it.
I think that's the central problem we're dealing with. There is scads of mechanism and little policy.
I also don't think we're going to agree on what policy should be, except within limited contexts.
More information about the cryptography