Re: [openpgp] Expected client behaviour ambiguity in signature verification

[Andrew Gallagher <[e-mail]>]

Thanks for the correction. What must therefore be happening is that something else (gnupg?) is duplicating the sigs onto the correct object, and then go-crypto is dropping the incorrect ones (it’s definitely doing at least *some* of the cleanup). It may be sufficient to leave it like that; anyone with a sufficiently broken key is likely to either upload a fixed one or have someone else do it on their behalf, at which point we can discard the duplicates.

Thanks,
A

> On 12 Jul 2022, at 20:13, Daniel Huigens <d.huigens=[e-mail]> wrote:
> 
> go-crypto currently doesn't move signatures from one object to the other
> if they're incorrectly ordered. I think it would return an error in
> that case, since it verifies signatures during parsing (except for
> third-party signatures on the User ID) - whether that's desirable is
> of course also debatable but that's what it does currently.
> 
> Best,
> Daniel
> 
> 
> ------- Original Message -------
> On Tuesday, July 12th, 2022 at 19:38, Andrew Gallagher <[e-mail]> wrote:
> 
>> On 8 Jul 2022, at 15:22, Daniel Huigens [e-mail] wrote:
>> 
>>> On Friday, July 8th, 2022 at 15:14, Justus Winter wrote:
>>> 
>>>> You said before that you prefer not to use the reordering heuristic.
>>>> But how else should the keyserver fix the certificate?
>>> 
>>> I meant more that they could do a manual intervention for the keys where
>>> that happened, perhaps. (Particularly in the case where the keyserver
>>> itself broke the key, I didn't mean that they should fix up these keys
>>> in general.) Then, they could also verify the signature packets with
>>> each of the components, to check where it should be placed.
>> 
>> 
>> Hockeypuck already fixes such badly-ordered sigs, because it uses go-crypto to parse the key material before serving to clients, and AIUI this normalises signatures implicitly. (There are knock-on issues about how to deal with the non-normalised back end storage but those are orthogonal to this discussion…)
>> 
>> A
> 
> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp