On 28 Mar 2024, at 09:47, Werner Koch via Gnupg-users <gnupg-users@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 <t...@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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
