On Wed, 2015-07-22 at 22:42 +0200, Kurt Roeckx wrote: > On Wed, Jul 22, 2015 at 03:36:40PM +0000, David Woodhouse via RT > wrote: > > > > FWIW the Linux kernel also specifically avoids checking timestamps > > altogether when validating signed modules. > > What do you mean wit timestamps? The trusted timestamp, or the > validity period? > > Any idea why they don't check it? They're not sure about the time > or something at the moment it's checked?
It's running on a computer. Of course they're not sure about the time. If after a CMOS battery failure you cannot boot the system in order to log into it and correct the time, because the firmware refuses to load the OS kernel or because the OS kernel refuses to load its disk driver, then there is something very wrong with the design. And if your system is designed to suddenly stop booting in 2037 for no better reason than the fact that *some* systems had bugs which made it seem simpler to set that as the expiry date for a cert even though we didn't really want it to expire *ever*, that's kind of broken too. The more I look at this 'signed timestamp' scheme, the more pointless it seems in this situation. We basically don't *care* about the wall -clock time, *and* we don't really know it. If we're going to trust anyone to say " <THIS> was the time at which the signature was generated", then we might as well forget the whole nonsense about an expiry time and just trust that same third party to provide a signature... or not. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev