Re: [openpgp] v5 interoperability

Hi Andrew,

The crypto refresh (officially speaking) doesn't know about the
existence of v5 keys. Thus, I'd argue v5 keys are by definition not
compliant with the crypto refresh (regardless of whether it's the whole
key or just a subkey). However, if you want to also implement another
standard or draft (e.g. draft-koch-librepgp) that declares such keys
legal, I'd say the crypto refresh by itself shouldn't stop you.

So practically speaking I would say, librepgp keys can be treated as
being orthogonal/parallel to crypto refresh keys, but to detect whether
something is a librepgp key, I guess you have to check whether any of
the key packets are v5, not just the primary key packet.

Best,
Daniel

On Tuesday, April 2nd, 2024 at 20:50, Andrew Gallagher wrote:

> Hi, all.
> 
> It came to my attention recently that recent versions of GnuPG are (under certain conditions) creating v5 subkeys and binding them to v4 keys. The use of mismatched subkey versions was not explicitly forbidden by rfc4880, but is forbidden in crypto-refresh.
> 
> So what is the proper way to treat such keys? They exist in the wild already, so cannot be ignored. I have been working on the assumption that v5 keys are orthogonal to crypto-refresh, and can therefore safely be treated in parallel, however a strict reading of crypto-refresh would mandate that such v5 subkeys should invalidate the key they are attached to:
> 
> > Every subkey for a v4 primary key MUST be a v4 subkey.
> 
> 
> https://openpgp-wg.gitlab.io/rfc4880bis/#section-10.1.3
> 
> This would appear to mean that if a keyserver presents a v4 key with a v5 subkey to a crypto-refresh compliant client, that client MUST ignore the entire key, which feels like overkill. Or should it merely ignore the offending subkey? If so, should we issue guidance to that effect?
> 
> In a thread on gnupg-users, Werner indicated that such mixing of subkey versions is longstanding behaviour, however there are vanishingly few historical examples in the wild:
> 
> https://lists.gnupg.org/pipermail/gnupg-users/2024-April/067039.html
> 
> A
> 
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp