I have an OpenPGP signed message, and a CMS signed message. Neither signature has an expiration time, but both certificates that signed each message have expiration times.
When i use GPGME to verify the signatures of each message, i switch between protocols (GPGME_PROTOCOL_OpenPGP and GPGME_PROTOCOL_CMS).
in either case, i use gpgme_op_verify and then example the signatures from gpgme_op_verify_result.
in the OpenPGP case, the exp_timestamp of the resultant gpgme_signature_t object is 0 (meaning, as far as i can tell, no expiration). But in the CMS case, the exp_timestamp of the resultant gpgme_signature_t object is the expiration time of the signing certificate.
This semantic difference makes it difficult for a tool that consumes GPGME output to reason about what a gpgme_signature_t.exp_timestamp means -- is it the expiration date of the signing certificate? or the expiration date of the signature itself?
For testing, i'm including the OpenPGP signing certificate here as signer.key (the corresponding X.509 certificate is embedded in the CMS signed message, so i don't upload it separately).
Here are the two messages:
Attached is also an example bit of code that invokes GPGME and emits the signature expirations to stderr.
0 dkg@alice:~/src/pkg-gnupg/gpgme-test$ ./test OpenPGP < test.txt.gpg.asc > /dev/null fpr: 3A41BCE3085F3A98FB2825CBC86DB7CCD9FB720A status: 0 ts: 1575441736 expires: 0 0 dkg@alice:~/src/pkg-gnupg/gpgme-test$ ./test CMS < test.cms.txt > /dev/null fpr: 702BA4B157F1E2B7D16B0C6A5FFC8A7DE2057DEB status: 0 ts: 1574813489 expires: 2611032858 0 dkg@alice:~/src/pkg-gnupg/gpgme-test$