[openpgp] Expected client behaviour ambiguity in signature verification

[Andrew Gallagher <[e-mail]>]

Hi, all.

It has been brought to my attention that some keys in the wild are not
being served correctly by some keyservers, and I suspect that the reason
is that only some OpenPGP implementations are performing the following
test as specified in section 5.2.3 of RFC4880:

```
The concatenation of the data being signed and the signature data from
the version number through the hashed subpacket data (inclusive) is hashed.
The resulting hash value is what is signed.
The high 16 bits (first two octets) of the hash are included in the
Signature packet to provide a way to reject some invalid signatures
without performing a signature verification.
```

I know that Protonmail/go-crypto *is* performing this test, and the key
I have been supplied with fails on it - but processing the same key in
both GnuPG and Sequoia throws no errors.

What should an implementation do in the case where these 16 bits are
incorrectly set but the signature is otherwise valid? It is implied that
failing hard on this test is allowed (otherwise why bother?) but it is
not specified as MUST or even SHOULD.

Thanks,
A