Re: [openpgp] Expected client behaviour ambiguity in signature verification

Hello,

FWIW, OpenPGP.js does this check as well. I agree it would be nice to
unify the behavior here. In my opinion, doing the check makes more
sense than not doing it, because as you said, otherwise why have those
bytes in the signature; we might as well remove them from v5 signatures.

So I would be OK with saying we should do this check for v5 signatures,
for example, to unify the behavior for the future. That way, if most
implementations follow that, it hopefully also prevents such broken
keys from getting out there (for v5).

Though, I see one potential reason why we might not want this check
/ these bytes, which is if you have a crypto library that provides a
unified hashing+signing/verification API, as the Web Crypto API does,
for example, where you pass the data and get back a signature (or
true/false), without getting the hash in between. (We currently still
hash it separately as well, partially because of this check, but I
could imagine we might want to do an optimization there.)

So I would also be OK with removing these bytes from v5 signatures and
not doing this check in v4 signatures.

Best,
Daniel

------- Original Message -------
On Thursday, July 7th, 2022 at 20:39, Andrew Gallagher wrote:

> 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
>
>
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp