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 _______________________________________________ Gnupg-devel mailing list Gnupg-devel@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-devel
