x488 vs all other : keyid flip

[Andrew Gallagher]

On 2 Apr 2024, at 11:58, Werner Koch <wk at gnupg.org> wrote:
> 
> On Fri, 29 Mar 2024 13:00, Andrew Gallagher said:
> 
>> V5 subkeys of v4 primary keys would appear to introduce a novel
>> failure mode. It should be noted that in crypto-refresh, adding a
> 
> Nope.

Are you saying that this is *not* a novel failure mode? Because we’ve never before had a key of one version number with a subkey of a different version number (since v3 did not support subkeys). Have you interop-tested this with other implementations? Besides RNP? What were the results?

> A v5 key has nothing to do a v4 signature and having different
> algorithm on the primary key and the subkeys is really common and
> allowed us once to slowly introduce RSA and ECC without any major
> problems.  This is why we will do the same for PQC encryption.

Yes, but a subkey of a different *algorithm* is anticipated by the spec and should work (in principle). A subkey of a different *version* is a different matter. Or is it specified somewhere that I have overlooked?

> All in all a really minor changes and not worth a long debate.

It may be a minor change, but if it breaks interop it is still worth debating the consequences.

> The crypto-refresh has a lot of things which breaks OpenPGP and that
> draft, or soon to be RFC, does not care about backward compatibility.
> They should not have used the term OpenPGP for this.

You keep repeating these talking points, but they are simply not true.

1. crypto-refresh defines a *different* set of extensions to OpenPGP than GnuPG supports, but these do not “break” OpenPGP.
2. crypto-refresh has bumped all of its packet version numbers specifically to avoid compatibility issues. Just because the WG have a different opinion does not mean that they don’t care.
3. The term “OpenPGP” does not belong to GnuPG.

And I notice that you have not addressed the most important point in my last email:

> how should an implementation behave if it wants to support both the librepgp and crypto-refresh specs?

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240402/8fd5683c/attachment.sig>