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

[Andrew Gallagher <[e-mail]>]

On 02/03/2023 10:58, Justus Winter wrote:
> 
> 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.

My proposed wording as of 2023-02-28 did not weaken the requirements of 
RFC4880, it actually strengthened them by restricting the manner in 
which malformed signatures could be processed. But you didn't like that 
one either.

> 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.

Yes. Because I don't believe that it is the role of keyservers to be 
enforcers in this particular matter. It is keyserver operators who are 
fielding complaints, not Github, and the answer "nothing we can do, 
Github is a dumpster fire, blame them" does not satisfy users who just 
want things to work. Inflexibility is valuable if you apply it 
consistently from the start so that deviations don't arise in the first 
place. If you start applying it after twenty years of effective 
liberalism, you're just breaking things that used to work.

Postel's law is flawed, of course. But criticisms of it are framed in 
the context of synchronous protocols, and continuous improvement. You 
refuse to tolerate errors because that's the only way that your peers 
learn to do better.

A more appropriate maxim in this instance is "be tolerant of your 
grandparents, but teach your children properly". There's no value to be 
gained in refusing to buy a second hand out of print book, because there 
is no feedback mechanism to cause that book to improve itself. 
Invalidating a v4 signature on a git commit from 2013 does not encourage 
github to get in a time machine and fix their commit history. It just 
makes users angry because you *broke their stuff*.

> 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?

I considered it, but that would further delay the draft over a 
technicality that did not have any direct consequences for me or my 
implementation. gopenpgp is already lenient on this matter, so I can 
live with it.

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

It does not matter whether you think RFC4880 allowed lenient behaviour 
or not. What matters is that enough other people thought that it did, so 
there are now permanent facts on the ground that you are powerless to 
undo. Neither of us LIKE this scenario. I'm just not prepared to punish 
github users for a historical error that a) they had no hand in, b) has 
no known security implications, and c) nobody, not even github 
themselves, can now fix.

I would much prefer to do this in a documented and mantainable way. But 
since it is now clear that no consensus is possible on any further 
changes of wording, I will no longer pursue it in this forum.

I withdraw my proposal.

A