Page MenuHome GnuPG
Create Task
Maniphest T3953

GPGSM: Treat EXPKEYSIG as error
Closed, InvalidPublic
Actions

Description

Moved out of T3948

CERT_PATH_COMMON_08|ERROR|INVALID|VALID

Checks the behaviour of the application when an intermediate certificate has expired (now > notAfter). This path is not valid, because one CA certificate has expired.

CERT_PATH_COMMON_10|ERROR|INVALID|VALID

Checks the behaviour of the application when the target certificate has expired (now > notAfter). This path is not valid, because the target certificate has expired.

Root CA:

CERT_PATH_COMMON_08_ROOT_CA.TA.crt807 BDownload

Testmsg:

CERT_PATH_COMMON_08.eml3 KBDownload

CERT_PATH_COMMON_10.eml3 KBDownload

gpgsm --import CERT_PATH_COMMON_08_ROOT_CA.TA.crt
echo "87:0F:8B:9E:5E:DF:A7:87:D2:B9:98:7C:2A:EA:9B:D6:DD:93:2F:D0 S" > $GNUPGHOME/trustlist.txt
echo "disable-crl-checks" > $GNUPGHOME/gpgsm.conf
gpgparsemail --crypto CERT_PATH_COMMON_08.eml 
gpgparsemail --crypto CERT_PATH_COMMON_10.eml

Result: We get a good signature even if the intermediate CA is expired or the signing certificate is expired. EXPKEYSIG is only shown as status.

I think this is a Bug because it behaves differently then GnuPG.

Details

Version
2.2.7-beta33

Related Objects
Search...

Event Timeline

aheinecke created this task.Apr 30 2018, 3:00 PM
aheinecke added a parent task: T3948: GPGSM: Multiple issues reported to KMail.
aheinecke mentioned this in T3948: GPGSM: Multiple issues reported to KMail.Apr 30 2018, 3:24 PM
aheinecke assigned this task to • werner.May 8 2018, 4:00 PM
aheinecke raised the priority of this task from Normal to High.
aheinecke added a subscriber: • werner.

I think this issue is important as GPGME should not report "Green" / Everything OK in that case and only have the EXPKEYSIG in details.

In my opinion we should fix that either in GPGME or in GPGSM for the next release.

@werner objections? I would prefer if you would do that. But I also could look into it myself.

• werner added a comment.May 8 2018, 5:27 PM

gpgsm behaves exactly as gpg and as explain in doc/DETAILS. VALIDSIG is issues even for signatures done by an expired certificate. Let me check whey GPGME claims "green" here while it does not not an expired OpenPGP signature.

• werner closed this task as Invalid.May 8 2018, 6:16 PM

The key receives fully trust and thus we get the "green" flag plus the "expired" flag. In my test with OpenPGP the key was not trysted and thus we did not got only the "expired" flag. At some distant past we agreed on these rules.

The question here is: Why should a data signature be invalid or not anymore trusted after the key expired. There is no reason to claim this.

aheinecke added a comment.May 8 2018, 7:20 PM

But why is that the case for OpenPGP Signatures, then? The difference does not make sense to me.

And I think it comes more from a time where we showed invalid / expired signatures as "alarm alarm you are hacked !!!! bad bad! with blood red background". Nowadays I would say: "This signature is so old and the chain has expired that you should not put any additional trust in the creator of that message.".

And e.g. If I have old certificate chains that used MD5 signatures in my trustlist, but they are expired. An attacker knows this -> he could craft a message using MD5 signatures that would validate as green. Or if he compromised an expired certificate etc.

TBH. My guess about the "some distant past discussion point" is that some customer wanted this, we didn't care and just implemented it to customer wishes.