Event details
I must have a thousand questions. I'm making one comment per question as that seems reasonable. Posted in no particular order. As of 2026-02-25 I have 22 questions.
I typed up all these questions not knowing there was a February AMA. I'll have to watch that later to see if any of my questions are answered there.
---
In the Dec AMA it was mentioned (I think by Scott) that the KEK-signed DB/DBX update binaries are time-stamped and continue to work. How does timestamping work with KEK updates? Similar to how we do it in x509/code signing? Or did I misunderstand? It also sounds like the KEK can't be used after it expires to make DB/DBX changes, so I find this all irreconcilable.
Secure Boot requires update binaries to be timestamped but it doesn't enforce strong verification of those timestamps. The only check is that you can only replace or delete a variable with a timestamp strictly greater than the last used timestamp for that variable. You can still append to the variable with a old timestamp (what Microsoft is doing with these updates since it only appends certificates). Thus the update binaries will always stay valid in the future, as per the current UEFI specifications.
Also, Secure Boot never checks if the certificate signing the binary is expired. So you can generate outdated PKCS#7 signatures with an expired certificate to keep using it for Secure Boot updates. It seems Microsoft won't do that though (or that their PKI won't allow them to), otherwise they wouldn't insist so much on replacing the KEK.
Thanks for the replies.
"Secure Boot requires update binaries to be timestamped but it doesn't enforce strong verification of those timestamps. The only check is that you can only replace or delete a variable with a timestamp strictly greater than the last used timestamp for that variable. "
After staring at your comment for long enough, I think I understand what you're saying, but it's not really my question. I'm talking about "normal" code timestamping where the signature doesn't rely on the subject certificate still being time-valid (RFC 3161). What you're referring seems to be more about ensuring the proper lineage of updates (forward-only updates).
However...
"Thus the update binaries will always stay valid in the future, as per the current UEFI specifications."
...you lose me with this comment. Either the KEK binaries are valid past expiration xor they're not. If update binaries are valid forever and UEFI/SB processes are **trusting** an unauthenticated timestamp, then the whole expiration of the certificate would seem pointless. Or you didn't mean to say what I'm interpreting.
"Also, Secure Boot never checks if the certificate signing the binary is expired."
You're losing me even further with this one. What do you mean by binary? Do you mean the EFI bootloader/oprom/application? Or the update binary (the DB/DBX updates)?