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

[Daniel Kahn Gillmor <[e-mail]>]

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.

this sentence seems likely to prompt questions: why is it OK for v3/v4,
but not ok for v6?  I mean, those of us following this thread
(hopefully) understand the historical context here, but if the goal is
to have the draft explain itself, this sentence on its own, without
justification, seems likely to increase the overall confusion in the
draft.

If the goal is "leave the status quo in place for v3 and v4 signatures"
then perhaps saying nothing about them is the shortest path to retaining
the status quo (since nothing was said before either, leaving us in this
current mess, it really is the status quo).

If we're going to add the above sentence, i'd want some kind of clearer
explanation of why the carveout is in place.

It doesn't sound to me like you would be advocating for this carveout if
there were not a fairly prolific implementation producing malformed
signatures.  Is that right?  So any explanatory text justifying such a
carveout probably needs to make a nod to the relevant historical
circumstances:

 - we failed in RFC 4880 to mandate explicit rejection of signatures
   with an incorrect hash digest prefix.

 - more than one popular implementation was lenient and accepted them
   despite the malformed structure.  But some implementations do reject
   these signatures, leaving an interoperability problem:
   implementations do not agree with each other about certain signatures.

 - a large set of malformed v4 signatures exist in the wild that we
   cannot change without incurring other, non-OpenPGP breakage.

 - To avoid this interoperability problem for future OpenPGP signatures,
   we have a MUST reject for malformed V6 signatures.  The authors
   recommend that any future signature version should also have a strict
   "MUST reject" for any malformed signature, to avoid signature
   validity skew between implementations.

I'm not saying we need all this text in the draft (if we do want
something like it, it probably deserves its own subsection in Security
Considerations).  I'm just saying that if we add an explicit "MAY
accept" for malformed v3/v4 signatures, we should reference a coherent
summary of why there's a difference.

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.

> It MUST NOT modify such malformed signatures. 

Where does this constraint come from?  Why is it here?  Wouldn't an
implementation that understands why a signature is malformed *want* to
modify the malformed signature to fix it?

certainly, "fixing" (by modification) an OpenPGP signature embedded in a
git commit would be a disaster for git, because it breaks the id of the
commit.  But the prohibition on modification comes from the fact that
it's a blob in git, not from the fact that it's a malformed OpenPGP
signature.

Plus, i can imagine some useful tools that this would forbid.  For
example, an implementation could correct the certification signatures
within a certificate generated by a non-conformant implementation to get
a certificate that all implementations will accept.  But this sentence
seems to forbid doing so.  Why would we do that?

        --dkg