[andrewstuart2]

The expiration date is the fallback if you don't have confirmation from the timestamp server that it was signed prior to expiration.

Ideally it's not used except by the timestamp service, but it seems like a fairly reasonable fallback.

[wtallis]

> The expiration date is the fallback if you don't have confirmation from the timestamp server that it was signed prior to expiration.

The fact that the driver was installed locally before the expiration should be taken as proof that the driver was signed before expiration.

[slededit]

Then you would need an internet connection just to install a driver. It would make getting your network driver installed pretty difficult.

You could look at the system clock but that was not designed to be secure for this purpose.

[wtallis]

> Then you would need an internet connection just to install a driver.

If you think I'm proposing any changes to how drivers are installed, then you have misread me. I'm proposing a change to how already-installed drivers are handled: absent any new information, the code that was trusted yesterday should be trusted today, and be allowed to keep running.

[slededit]

Imagine a scenario where a driver is installed during a network outage and with an incorrect clock. Because you need to be able to install a network driver the system will allow this security flaw. However when the system knows better its reasonable to limit the damage by stopping the driver.

You could say that any damage has already been done which is most likely true. But I can't fault them from mitigating it as much as possible.

I suppose you could modify the system to get external attestation of the time while the driver is installed and use that as a sticky bit - but its a big complication and its much better if the driver is securely timestamped in the first place.

[wtallis]

> Because you need to be able to install a network driver the system will allow this security flaw. However when the system knows better its reasonable to limit the damage by stopping the driver.

The only way that the system "knows better" is by acquiring something like a certificate revocation list. The system does not know whether it was powered down for five minutes while the network outage was fixed, or for five years. When the system is powered back on with a working internet connection, it does not have any reliable way to tell whether the offline installation of the network driver occurred prior to the expiration, or after the expiration with a properly backdated driver and backdated system clock. There is no way to justify suddenly de-trusting a driver that's already been running simply by observing that you're in the future.

[Retric]

Even then you only need to verify that once and can save a time stamp in case the cert is revoked afterwards. Breaking system that has already been verified is still unjustified.

[mattnewton]

Can’t Microsoft give you an error report when they do this, to let you know what you are doing is probably very dumb?

I guess I don’t know the time when Microsoft has their code and heir contact information and is doing some kind of preflight check, or if that ever actually happens, and there are already so many ways to be very dumb with drivers...