[cryptography] How are expired code-signing certs revoked?

William Whyte wwhyte at securityinnovation.com
Wed Dec 7 12:09:02 EST 2011


> > 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 would say that you shouldn't install code signed with an expired
certificate,
but you can continue to use code you've already installed after the
certificate
expires. That requires occasional resigning, rather than continual.

Revocation is a different issue; it seems like it should require either
spooky
action at a distance or TTP timestamping (as ianG discussed earlier). In
the
absence of timestamping, if a code signing cert is revoked, the most
sensible
thing to do is uninstall any software signed with that cert.  This
obviously means
that even expired certs need to appear on a CRL, which raises the question
of
whether it's worth expiring them. I think it probably is worth it because
(a) it raises
the possibility that one cert's worth of software could be withdrawn
without
requiring all software from that vendor to be compromised, although at
that point
you're into marginal gains in very hypothetical situations; and (b) it
makes going out
of business cleaner and doesn't leave too many still-valid certs floating
around.

William



More information about the cryptography mailing list