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 26/02/2023 14:30, Daniel Kahn Gillmor wrote:
>> Hi OpenPGP folks--
>> 
>> one more question about an outstanding merge request, which i missed in
>> my earlier review:
>> 
>> https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/213 proposes
>> adding a single sentence to the "Notes on Signatures" subsection about
>> the two octets of hash prefix that are embedded in an OpenPGP signature:
>> 
>>         An implementation MUST reject signatures where these octets don't
>>         match the first two octets of the computed hash.
>
> ...
>
>> Alternatively, we could be even more conservative and apply this
>> requirement *only* to v6 signatures, leaving untouched the ambiguity in
>> verification for v3 and v4 signatures.
>
> IMO the check should be mandatory for v6 signatures. If we are keeping 
> the prefix octets in v6, they MUST be meaningful. But I am not happy 
> with retaining the current ambiguity for v3/4 sigs. v4 sigs in 
> particular will be around for a long time to come, so we have an 
> obligation to address the well-known interop problems.

I agree.

> Given that there are a significant number of non-conformant historical 
> sigs in the wild,

Can you elaborate on that?  I'm not aware of a single one.

> it is wrong to mandate a stricter interpretation in 
> retrospect. Signatures that were previously considered valid (even if 
> only by some implementations) should only be retrospectively invalidated 
> in the event of a security vulnerability, and there is no suggestion 
> that this ambiguity could be exploited to make an invalid signature 
> appear valid. This is an interop issue, not a security one, so IMO the 
> least problematic solution is to be lenient in what we accept.

For the record, I disagree.  If the standard says put the hash prefix
there, and you don't put the hash prefix there, your signature is
malformed, and has always been malformed.  The fact that some
implementations (including ours) do not reject the malformed signatures
does not change the fact that they are malformed.

In my mind, !213 is merely a clarification, and is useful for v3 and v4
signatures as well (as the test results indicate).

The fix is to make all lenient implementations strict.

Best,
Justus