[openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled

[David Woodhouse]

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.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150728/f56fdb2f/attachment-0001.bin>