x488 vs all other : keyid flip

[Andrew Gallagher]

On 28 Mar 2024, at 09:47, Werner Koch via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> x448 keys are created as version 5 keys and version 5 keys come with a
> 32 byte fingerprint (v4 has 20 bytes).
...
> Here is an example:
> 
> pub   ed25519 2016-02-02 [SC]
>      FD8FEC4F8595AB1B6F60D43FC2CED0800E50ACF1
> uid           [ unknown] chicago <test at example.net>
> sub   cv25519 2016-02-02 [E]
>      532D5C7677B4D806B50B0E0F11E7BF9EE1034B1C
> sub   cv448 2024-03-27 [E]
>      FB6A3BC5EB92C8AA9F3807A9B4C79C38F16E9AA4CF9384B07485923574773DCF
> 
> where a v5 subkey has been added.

V5 subkeys of v4 primary keys would appear to introduce a novel failure mode. It should be noted that in crypto-refresh, adding a non-v4 subkey to a v4 primary key is explicitly forbidden:

> Every subkey for a v4 primary key MUST be a v4 subkey.

https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-crypto-refresh-13#section-10.1.3

I notice in the LibrePGP draft that there is no specification of this hybrid v4/v5 construction. The corresponding section of the spec doesn’t even mention v5 TPKs at all, just v3 and v4:

https://datatracker.ietf.org/doc/html/draft-koch-librepgp#name-key-structures

This appears to be a verbatim copy of the corresponding section from RFC4880 that has not (yet) been updated to take account of v5:

https://datatracker.ietf.org/doc/html/rfc4880#section-12.1

So a few questions arise: is this a deliberate design decision, and if so what considerations were taken into account in that design, and 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/20240329/0603368c/attachment.sig>