Consider this test OpenPGP certificate:
And this cleartext inline signed document, made by that certificate:
.Attempting to validate the signature with GnuPG 2.2.27 yields:
gpg: Signature made Tue 09 Feb 2021 12:45:30 AM EST gpg: using EDDSA key B3B5920B69AE83EDA7F6E09029555318E7E16B39 gpg: issuer "test@example.org" gpg: assuming bad signature from key 29555318E7E16B39 due to an unknown critical bit gpg: BAD signature from "test <test@example.org>" [unknown]
gpg --list-packets shows the signature with this info:
# off=0 ctb=88 tag=2 hlen=2 plen=135 :signature packet: algo 22, keyid 29555318E7E16B39 version 4, created 1612849530, md5len 0, sigclass 0x01 digest algo 8, begin of digest 50 d0 hashed subpkt 33 len 21 (issuer fpr v4 B3B5920B69AE83EDA7F6E09029555318E7E16B39) hashed subpkt 2 len 4 (sig created 2021-02-09) critical hashed subpkt 28 len 16 (signer's user ID) subpkt 16 len 8 (issuer key ID 29555318E7E16B39) data: [255 bits] data: [256 bits]
So the only critical hashed subpacket is the "signer's User ID". But GnuPG knows what the "issuer user ID subpacket" is and how to interpret it. It should not reject the signature due to the "critical" bit being set on that subpacket.
Most OpenPGP tools that i'm aware of (including GnuPG 2.2.27) do *not* set the critical bit on this particular subpacket. But GnuPG should still be capable of accepting such a subpacket in a signature without rejecting it due to its critical bit being set.