Re: [openpgp] Should signatures be rejected if the embedded hash prefix does not match?

[Andrew Gallagher <[e-mail]>]

On 01/03/2023 04:05, Daniel Kahn Gillmor wrote:
> Thanks for proposing text, Andrew.  I'm trying to figure out what it
> does, though, and why, and i'm struggling a bit.
> 
> On Tue 2023-02-28 15:17:01 +0000, Andrew Gallagher proposed:
> 
>> An implementation MAY accept v3 or v4 signatures where these octets
>> don't match the computed hash but the signature is otherwise valid.
> 
> If we're going to add the above sentence, i'd want some kind of clearer
> explanation of why the carveout is in place.

We could prefix it with:

```
RFC4880 did not specify that implementations must reject v3 or v4 
signatures with incorrect prefix octets, and this allowed a significant 
number of apparently valid but malformed signatures to accumulate in the 
wild.
```

> Or we could just not say anything new about v3/v4 here, because this is
> a doc largely aiming to define v6 in a way that doesn't cause the same
> problems.

That would be an option, but if we can't come to a consensus on a common 
treatment of malformed signatures, I would much prefer to actively 
record that lack of consensus.

The background is that Hockeypuck received complaints that it was not 
serving certain (supposedly valid) keys. This was caused by a test of 
the prefix octets in protonmail/gopenpgp. I asked if that test could be 
(perhaps optionally) skipped but protonmail were reluctant to support it 
without the cover of spec, and I didn't want to cut and paste a large 
chunk of their code into Hockeypuck just so I could comment out three 
lines of it.

If users of lenient implementations such as gnupg are happy to work with 
github's malformed but otherwise usable key, IMO the keyservers should 
get out of their way. So I'd prefer to actively permit implementations 
to drop this check. I'm relaxed about how this is done, but I would not 
be happy with either mandating rejection of these sigs or leaving the 
behaviour undefined.

A