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

[Justus Winter <[e-mail]>]

Andrew Gallagher <andrewg=[e-mail]> writes:

> On 02/03/2023 09:44, Justus Winter wrote:
>> I don't think either warrants a clarification for v4 (let alone v3)
>> signatures.
>
> I was erring on the side of caution. However, in the interests of moving 
> this along, I withdraw the last sentence of my proposed text.
>
> It now reads:
>
> ```
> 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.
> An implementation MAY accept v3 or v4 signatures where these octets 
> don't match the computed hash but the signature is otherwise valid.
> ```

RFC4880 failed to specify a lot of things.  I fear that if we enumerate
all of them, and retroactively sanction lenient behavior, that a) we're
going to be here until the end of time, and b) weaken the already weak
requirements that RFC4880 failed to nail down.

I understand that this is precisely your point: if the spec would
sanction lenient behavior in this case, then that may convince Proton to
support lenient behavior in GopenPGP, and that would enable Hockeypuck
to serve these signatures.

I assume that with "a significant number of apparently valid but
malformed signatures" you don't mean artifacts produced by openpgp.php,
which I don't believe to be in widespread use.  Instead, I think you
refer to the malformed signatures produced by Github.  If so, are you
going to propose a similar paragraph for the malformed MPIs?

Both cases are contingent on reading RFC4880 as allowing lenient
behavior, which to this day I fundamentally disagree with.

I prefer not to add this paragraph.

Best,
Justus