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