Incompatability with other PGP implementations

[Ivan Hell]

Hello,

I'm not sure if this is the correct place to post such a question but
I hope I can get an answer nevertheless.
In my everyday life I use GPG mainly to sign documents and git
commits. Recently I had to implement a Node.js application that uses
GPG keys in order to verify GPG signed documents. For this reason I
used the following library: https://openpgpjs.org/. The GPG key in use
had the following structure:


Master-Key (created: 2022-01-01, expires: 2030-01-01)
| -> signing subkey (created: 2022-01-01, expires: 2024-10-15)
| -> encryption subkey (created: 2022-01-01, expires: 2024-10-15)

Up until now everything worked like a charm. Since both subkeys
expired during this month I decided to update their expire Date using
the GPG CLI:

Master-Key (created: 2022-01-01, expires: 2030-01-01)
| -> signing subkey (created: 2022-01-01, expires: 2026-10-15, updated
2024-10-14)
| -> encryption subkey (created: 2022-01-01, expires: 2026-10-15,
updated 2024-10-14)

In consequence I exported the key again and imported it in my Node.js
application. However, from that point on message verification in my
Node.js application always failed for messages signed before
2024-10-14. In contrast, signature verification using GPG worked
without any issues.

To better understand the problem I looked through the implementation
of opengpgjs and noticed that the error was caused by the signing
key's binding signature validity check. In contrast to GPG, when
checking a signature validity, this library looks at the subkey's
binding signature creation date instead of the subkey's creation date.

In consequence I filed an issue on their github project and started a
discussion with the project maintainer:
https://github.com/openpgpjs/openpgpjs/issues/1800.
As a result, the maintainer noted that the library strictly adheres to
the OpenPGP specification and its RFCs when checking signatures and
that gpg may deviate slightly in its implementation of the standard.
He also argued that according to sequoia-pgp's OpenPGP
interoperability tests, most implementations adhere to his
interpretation of the standard:
https://sequoia-pgp.gitlab.io/openpgp-interoperability-test-suite/results.html?impls=7594#Key_revocation_test__subkey_signs__primary_key_is_not_revoked__base_case_

My question now is whether the current implementation of GPG is
exposed to a security risk by not taking the creation date of the
binding signature into account? I also wanted to find out whether
there is a way to adapt the implementation in GPG so that it is
compatible with the other OpenPGP implementations (possibly using a
configuration option)?

Best regards
Ivan