> It kindof annoys me that the timestamp wasn't somehow worked into the signature itself (like as a sub-packet), Interesting, I took a sample signature from h

> It kindof annoys me that the timestamp wasn't somehow worked into the signature itself (like as a sub-packet), Interesting, I took a sample signature from here [0], saved that to file and run `gpg --list-packets gitsig.asc`: # off=0 ctb=89 tag=2 hlen=3 plen=284 :signature packet: algo 1, keyid 5D3EB2F8800430EB version 4, created 1399174181, md5len 0, sigclass 0x00 digest algo 2, begin of digest 65 b4 hashed subpkt 2 len 4 (sig created 2014-05-04) subpkt 16 len 8 (issuer key ID 5D3EB2F8800430EB) data: [2047 bits] It looks like it is timestamped with date 2014-05-04T03:29:41.000Z. The tag itself also has Date header, usually the tag is created and signed at the same time. [0]: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work OpenTimestamps protects against someone backdating signatures. If they control the key they can create signatures with arbitrary dates but they can't put them in the blockchain in any place. So basically that gives "proof of existence" that the given signature existed at least at that exact point of time. Disclaimer: I never used OpenTimestamps but rather Bitcoin Core JSON interface to timestamp things (it's 3 simple commands to publish OP_RETURN transaction). For people that don't want to spend Bitcoin on timestamping it is possible to (ab)use Certificate Transparency logs for the same purpose: https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency