The timestamp server is a separate trusted entity that signs the signature asserting the date and time. It's not just metadata, it's effectively a separate signature.

Checking at install time is effectively useless. The whole point of running signed code is that you can't just load some rootkit. Secure Boot only loads a signed bootloader which only loads a signed kernel which only loads signed kernel modules. You can't do what you're suggesting without fundamentally breaking this chain of trust. What's to stop a rootkit from just spoofing that it was installed months ago?

CRLs are pretty difficult to scale resiliently, though, for a number of applications. Same problem that led to OCSP stapling after OCSP became a thing. With CRLs you can at least take advantage of a CDN of some kind, but there are tradeoffs with your ability to operate a CRL securely doing that, too.

CRL in the driver install flow implies being online (at some point) to install drivers too. As we move into the future it’s hard to imagine not having Internet access, but we also don’t design Windows. It’s definitely a case they’ve considered, though I did see mention of a timestamp server in this thread (I don’t know much about Windows signing, just X.509 PKI in general).

> There's no reason to re-verify the signature every time the driver is used.

I was replying to this part of your comment. It does seem worthwhile to validate the signature of the driver every time the driver is used if that check would reveal when a certificate has been revoked for having been compromised.

Agreed that the expiration time is not particularly useful for this purpose.