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

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

On Wed 2023-03-01 19:47:24 +0000, Andrew Gallagher wrote:
> Because in a distributed system you don't know that a signature is not 
> the subject of a countersignature or digest somewhere else. We can 
> easily construct a case where a signature is stored on some central 
> system (e.g. a keyserver), and also distributed to a third party (or 
> parties) for countersignature. When a countersig comes back, what 
> happens if the original sig has been fixed up in the meantime? Does the 
> keyserver refuse to process the countersig (being invalid) or does it 
> revert to the previous (malformed) version? What if one third party 
> countersigs the malformed sig and another countersigs the fixed-up copy?

(no hats on here)

hm, i can see these concerns, but i guess i'm not particularly troubled
by them.  the original signer could even realize their mistake and
re-issue the signature with the exact same data -- there are now
basically two signatures: one well-formed and not countersigned, and one
not-well-formed and countersigned.

If anything, this discussion is moving me in the direction that being
strict is really the only way to go, though i do understand the
reluctance to retroactively declare all the signatures made by github to
be incorrect.

> This is a can of worms that should be nailed firmly shut IMO.

I just don't see how this nails it shut, though, since non-compliant
implementations can still distribute copies of transformed signatures,
and compliant implementations will still have to decide how to deal with
them.  Maybe forbidding accepting signatures with a malformed hash
prefix would nail it shut, but most of these steps just seem like we
would be committing to additional breakage :(

Thanks for the discusison here!

           --dkg