[cryptography] How are expired code-signing certs revoked?
iang at iang.org
Wed Dec 7 14:34:36 EST 2011
On 8/12/11 04:34 AM, Jon Callas wrote:
> On 7 Dec, 2011, at 8:52 AM, Steven Bellovin wrote:
>> 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.
Right, but it's getting closer to the truth. Here is the missing link.
Revocation's purpose is one and only one thing: to backstop the
liability to the CA. It does this by marking 3 periods in time: before
reporting to the CA, after reporting but before revocation, and after
This creates three windows in time, each of which has separate
liabilities. The first window is zero liability because the CA has not
been notified. The second window is some indeterminate liability. The
third window is no liability because the cert has been revoked.
Some will leap into the question of how much liability then the second
window has: well, it's a short period and we can see an incentive for
the CAs to reduce that window - only. Typically CAs talk about a day.
We can contrast this with the recent Malaysian 512 bit cert attack which
by some speculation went on for a year or so, to the extent that anyone
knows or is saying. So, we can now see it reasonable for CAs to say
"ok, because of the clarity revocation gives for Windows 1, 3, we'll
wear the liability for 2. But let's keep it short, ok?"
The goodly angels of PKI will oppose this evil claim. They will say oh,
no, revocation means something else. They will have to show that, with
a precise explanation. And now they have a problem. If we read through
countless standards and PKI PhDs and blah blah ... we will find an
absence of defined meaning.
Whether that's deliberate or accidental I'll leave to others :) Let's
just stick to the facts.
It is not stated anywhere *what revocation means*. It is stated what
you should do. Or not do. It is stated in deep technical detail what
happens, and what bits to do and how to do variations and how to double
up the complexity. How to report, when to report. How you will break
certain undertakings, and your life will be worse, because...
But it never states what it means, in any tangible, legal, semantic
sense. This then allows Jon's myths to emerge. If I as CA haven't told
you what it means, then you are free to imagine anything you like,
right? I won't contradict, why should I? I've got my liability
covered, anything else is up to you. Good luck!
Now Peter G's question. The answer is simple, it doesn't matter. It
doesn't speak to the purpose of revocation, so it can be anything you
desire. Knock yourself out...
More information about the cryptography