Change expiration check to match TUF

[joshuagl]

There was a discussion in the issue tracker of TUF reference implementation (https://github.com/theupdateframework/tuf/issues/1231) about how expiration datetime's should be compared.

Having done some research into how other security providers are comparing expiration equivalents (i.e. OpenSSL x509 certificate checking code, and GnuPG expiration checks), and how other TUF implementations are performing the same check (rust-tuf, go-tuf), we came to a consensus that the correct way to implement expiration comparisons is:

expiration <= now

I'm filing this issue because the discussion in the thread suggested it is preferable to have in-toto and TUF specifications and reference implementations behave in the same way on this.

[joshuagl]

I'll be happy to submit a change to the in-toto spec if nobody else gets to it first.

Similar issue filed agains the reference implementation: https://github.com/in-toto/in-toto/issues/417

[adityasaky]

https://github.com/in-toto/docs/pull/69/commits/24ffa490726d13fd254540243f75c8271ce8e46c

Hi @joshuagl, does this diff sufficiently address this issue?

[joshuagl]

That diff LGTM.

For reference, we addressed it in the TUF spec in https://github.com/theupdateframework/specification/pull/118 which includes some discussion on the choice of language.

[adityasaky]

Also, the verification workflow already says: If the system's date is newer than the expiration date on the layout's expiration field, verification should fail.

For reference, we addressed it in the TUF spec in https://github.com/theupdateframework/specification/pull/118 which includes some discussion on the choice of language.

Interesting thread. My thinking is that much of that discussion doesn't directly apply to in-toto. I think we've covered our bases. in-toto would inherit the notion of update window wrt timestamp validity from TUF (ITE-2).

Thanks for the review!