Page MenuHome GnuPG
Create Task
Maniphest T4767

gpgme_signature_t exp_timestamp behaves differently for OpenPGP vs. CMS
Open, LowPublic
Actions

Description

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).

signer.key612 BDownload

Here are the two messages:

test.cms.txt2 KBDownload

test.txt.gpg.asc265 BDownload

Attached is also an example bit of code that invokes GPGME and emits the signature expirations to stderr.

test.c1 KBDownload

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$

Event Timeline

dkg created this task.Dec 4 2019, 8:01 AM
• werner added a subscriber: • werner.Dec 4 2019, 8:56 AM

CMS signatures do not have a expiration time. Further the meaning of the expiration time of one of the certificates also depends on the validation model (shell or chain); thus a one-to-one relationship between these times is not possible.

dkg added a comment.Dec 4 2019, 10:03 AM

Very few OpenPGP data signatures have an expiration time either, fwiw. I have never actually seen one in the wild, and no one that i know uses --ask-sig-expire or --default-sig-expire (it shows up in the cupt test suite and the apt test suite, but doesn't appear to be actually used by anything).

And a CMS signature could easily be extended with an arbitrary OID that indicates a signature expiration time in the signedAttributes section if someone were to just define such a thing (i have no plans to do so)

So, regardless of the validation model that you use (shell or chain) in either protocol, the public key material in the signing certificate is overwhelmingly more likely to have an expiration date than the signature itself.

So why is the CMS variant of GPGME presenting the expiration time of the certificate (which as you mention might itself vary based on the validation model) as though it were an expiration time of the signature?

• werner triaged this task as Low priority.Dec 4 2019, 10:43 AM