[openpgp] Re: v4+v6

[Andrew Gallagher <[e-mail]>]

Hi, Neal.

Thanks for this idea, I definitely think it's worth considering seriously.

On 9 Feb 2025, at 13:42, Neal H. Walfield <[e-mail]> wrote:
> 
> given just a v4
> certificate, we compute the corresponding v6 certificate by taking the
> v4 certificate's primary key, interpreting it as a v6 key, and
> computing the v6's fingerprint.  Then, we can look up the v6
> certificate locally or in a remote directory.  The same is true in
> reverse.

This is a neat trick, although I'm not sure it's a complete mechanism by itself. Without a positive indication by the key owner, a client would need to calculate counterpart fingerprints for every certificate it knows, and then look them all up on the chance that they might exist - and it would have to keep trying, because a key owner could upload a counterpart at any time. So it would still be preferable to have a forward replacement key subpacket on the original cert.

On the bright side, we could allow for key equivalence to be inferred from the primary key material being identical, in the absence of an inverse subpacket. But by the same argument as above, we might not want to speculatively search for fallback certs without a positive indication, so it might only be practical for the "trapdoor" scenario (i.e. without fallback encryption). If all key material was duplicated, the only scenario where fallback would be useful would be when a client doesn't support v6 at all, in which case the mechanism is irrelevant, so this is not a significant limitation IMO.

So, I think that this could be useful in the case where a key owner wants to make a "doppelganger" replacement cert that shares all key material with the original. We would still need to specify chain treatment, because it is possible in principle to have more than two key versions with the same material. I don't think we need to worry too much about decomposing PQ keys, because that would only apply to primary (i.e. signing) PQ keys, which are not urgently required in cases outside of software distribution, and there are usually other mechanisms available for rolling such keys.

Thanks again for the suggestion!
A