On Wed, 2015-07-22 at 16:47 +0000, Viktor Dukhovni 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. > > You probably need a dedicated implementation of X509_verify_cert(). > When dealing with "data at rest" (signed email, signed code, ...) > certificate expiration needs to be understood in the context of > time of signature, not time of verification.
Yes, but AFAICT the security model here is entirely bogus. If we're going to trust a third party to say "<this> is my signature, oh and trust me, <this> is when I signed it", then we might as well not be checking the validity time for that third party's signatures at all. There is *no* benefit, surely? Just complexity. > Ideally (this generally works for email), the verifier "initially" > verifies the signed object before the expiration time of the > certificate and then caches this fact in some manner, so that > subsequent verification can ignore the certificate entirely, and > just check the the object has not changed since initially verified. Except that IMAP deliberately provides a *read-only* message store. You cannot modify messages in any way, by design. You can only add flags. I don't even want to contemplate a world in which we just have a 'trust me, message signature was OK' flag on a mailstore and allow that to bypass the *actual* checking. Actually, if you look at RFC3851 §2.5.1 you'll see that we include a signingTime attribute in the S/MIME message. Validation is done using that. Which makes it entirely pointless, as I said above. You might as well just not *check* the validity time at all when validating email, surely? Hell, it would make more sense in the case of email to do the check using the Date: header (or the last Resent-Date: header). At least that wouldn't be *entirely* redundant. And it wouldn't be possible to falsely sign a message > If caching results of initial verification is not an option, then > perhaps disabling expiration checks is a last-resort option. It's not an option. It's not even a good idea. > There are ways (with care) to do this via the verify callback, which > can be made to suppress *only* expiration errors and fail on all > other errors. Yeah. And it turns out that we have verify callbacks in most cases *already*, to cope with intermediate CAs being present in our trust store without the ultimate self-signed root CA also being present. (Although I'd hope there was a better way to handle that; I'll come back to that later.) So for now I can live without the requested feature — although reluctantly because I think the reasons for refusing are utterly bogus — and fix it up on the EDK2 side just by ignoring/allowing X509_V_ERR_CERT_{HAS_EXPIRED,NOT_YET_VALID} thus: http://git.infradead.org/users/dwmw2/edk2.git/commitdiff/9b89269c -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev