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

[Daniel Huigens <[e-mail]>]

Thanks for the details. Sounds like it's somewhat infeasible to get all those people to fix their keys, then, I guess.

I've created a MR to remove these octets from v5 signatures (option 2 I described previously), here: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/208.

Best,
Daniel

------- Original Message -------
On Sunday, July 17th, 2022 at 22:16, Andrew Gallagher <[e-mail]> wrote:

> On 15 Jul 2022, at 16:45, Andrew Gallagher <[e-mail]> wrote:
>
>> Signed PGP part
>> On 15 Jul 2022, at 15:25, Daniel Huigens <d.huigens=[e-mail]> wrote:
>>
>>> Are there many keys out
>>> there that fail this check? I understood that GitHub has one, generated
>>> using OpenPGP.php, would it be possible to ask them to generate a new
>>> key, or modify their existing one? (Someone could do that for them, I
>>> guess :)) Or are there too many keys like this out there?
>>
>> I hotpatched hockeypuck to log this particular error against a primary key identifier and loaded an SKS dump. It has only been running a few minutes but it is already at several hundred unique primary keys affected, and counting at ~ 50 keys per batch of 15000. Scaling that up gives a ballpark of 22,000 keys in the full SKS dataset with bad hashtag self-signatures.
>
> I need to clarify and correct the above, sorry.
>
> The figure of 22k keys is an estimate of the total number of primary keys that throw a bad UID self-signature warning on import to hockeypuck. This includes misplaced signature packets as well as badly-constructed high-16-bit fields. The number of keys with high-16-bit errors only is considerably smaller than this total. Unfortunately due to a glitch in docker, my system dropped a large chunk of the import logs, and I'll have to run the test again to get the real numbers, but based on conversations with other hockeypuck operators in the last couple of days, the total number of unusable keys is unlikely to be more than a few hundred.
>
> Of the few keys with high-16-bit errors that I did detect, most are of the form `<wordpress@domain>`, and the other is for a software project that I know uses Wordpress to host their website - all consistent with the theory that openpgp-php is creating them.
>
> A