The way this is supposed to work is by using a timestamp from a trusted timestamp server to show the certificate was valid at the time the code was signed.
See the following text from the draft code signing baseline requirements from the CA/Browser forum: 8.2.1: "... With the exception of revocation checking for time-stamped and expired Certificates, Platforms are expected to validate Code Signatures in accordance with RFC 5280 when first encountered. Subsequent signature validation MAY ignore revocation, especially if rejecting the Code will cause the device to fail to boot. When a Platform encounters a Certificate that fails to validate due to revocation, the Platform should not permit the Code to execute. When a Platform encounters a Certificate that fails to validate for reasons other than revocation, the Platform should treat the Code as unsigned. Ordinarily, a Code Signature created by a Subscriber is only considered valid until expiration of the Certificate. However, the “Timestamp” method and the “Signing Service” methods permit Code to remain valid for longer periods of time. 1. Timestamp Method: In this method, the Subscriber signs the Code, appends its Code Signing Certificate and submits it to a Timestamp Authority to be time-stamped. The resulting package can be considered valid after expiration of the Code Signing Certificate and expiration of the Timestamp Authority certificate if the timestamp is dated prior to the Certificate’s expiration date and any applicable revocation date. (See Section 13.2.) 2. Signing Service Method: In this method, the Subscriber uses the service to sign compiled code, binary, file, app, or similar object. Alternatively, the service MAY sign a digest of the preceding objects. The resulting Code Signature is valid up to the expiration time of the Signing Service’s Code Signing Certificate and any applicable revocation date, whichever comes first. Signing Services MAY also timestamp signed objects." This is much better than simply ignoring all date validation. -Tim -----Original Message----- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Woodhouse, David via RT Sent: Wednesday, July 22, 2015 9:10 AM Cc: openssl-dev@openssl.org Subject: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled There are various circumstances in which it makes no sense to be checking the start and end times of a certificate's validity. When validating OS kernel drivers, or indeed when validating the OS kernel itself when the firmware loads it, we *really* don't want to have a built-in obsolescence date after which the system will no longer function. That would be a bad thing even if we *could* reliably trust the system's real time clock at this stage in the boot sequence. This patch gives us a way to disable the time checks entirely, by using X509_VERIFY_PARAM_set_time() with a time of -1. There is a slight risk here — if anyone was genuinely using the value of -1 to check if a certificate chain was indeed valid in the last second of 1969. I judge that risk to be negligible. And it certainly shouldn't be externally triggerable — if an attacker could influence the value passed to X509_VERIFY_PARAM_set_time() then all bets were off w.r.t. time-based checks anyway. If there are serious concerns, however, I can provide an alternative patch which adds an X509_V_FLAG_NO_CHECK_TIME flag for this purpose instead. I'm happy with anything except the existing version in the UEFI source tree that everyone is shipping, which just disables the time check if OPENSSL_SYS_UEFI is set¹. That one I *don't* like. -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ http://scanmail.trustwave.com/?c=4062&d=w5av1VNIDJq7CuEBC-sOxIBHFHbcisoH_n4fAJKpMg&s=5&u=http%3a%2f%2fgit%2einfradead%2eorg%2fusers%2fdwmw2%2fopenssl%2egit%2fcommitdiff%2f2fb12afc2ceb ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
