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