There is no purpose to the expiration in this particular case. If you have an expiry of say 24hours and constantly update that makes some sense - stolen certs get a very short time window.
If however you have an expiry of multiple years you clearly have no reason to have an expiry date at all. You can't possibly justify a security benefit, imagine reassuring people with "the stolen certificate is only valid for a few years!"
As in it was clearly a mistake to have an expiry date at all for this use case and the multi-year expiry date should have been a smell that tipped people off and made them ask "why do we have an expiry date at all for this?".
If there were no certificate expiry, I could break into your system by finding some bankrupt company last trading in 1980 and stealing their keys to mint my own certificate.
With expiry dates, at least the pool of places you can break into to steal certificate signing keys isn't growing without bound.
there is a difference between the expiration of signing keys, and the expiration of the signature signed with those keys. the signature for a contract, or a bootloader, should remain valid indefinitely, even if the person/key is no longer allowed to sign contracts/bootloaders after some point of time.
That sounds impossible to enforce. Key signing is done offline. If I have an expired signing key, what’s stopping me setting my clock back a few years, creating a new signature and signing it?
If the resulting key works indefinitely, the expiration date on my signing key is utterly meaningless.
Microsoft's Authenticode has been doing this for a long time, allowing a signature to be considered as valid long after the signing certificate expired.
And what stops people from just logging into the bios and changing the date or pulling the clock battery? The point we're all making here is, at least for this application, is that an expiration is pointless.
You can do almost as well by finding a piece of software with a code execution exploit early in boot that’s signed by the bank.
A different model would be to only allow a given EFI binary to be booted if it was installed before the deadline, but that might well have a different set of complications.
Even more, the "current date" comes from an external source that anyone with access to get new images on the machine can probably also manipulate. Setting the hardware clock is a normal operation available to the kernel.
If however you have an expiry of multiple years you clearly have no reason to have an expiry date at all. You can't possibly justify a security benefit, imagine reassuring people with "the stolen certificate is only valid for a few years!"
As in it was clearly a mistake to have an expiry date at all for this use case and the multi-year expiry date should have been a smell that tipped people off and made them ask "why do we have an expiry date at all for this?".