[openpgp] Re: v4+v6

["Neal H. Walfield" <[e-mail]>]

Hi Andrew,

Thanks for taking the time to comment on my note.

On Sun, 09 Feb 2025 22:13:49 +0100,
Andrew Gallagher wrote:
> 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.

I don't think this is a new problem.  There are many reasons to check
for updates to a certificate before using it: it might have been
revoked, the owner may have added a new subkey, etc.  This is another
type of update, and can be checked for using the usual mechanisms.  I
think the same reasoning also applies to the forward replacement key
subpacket: the owner may have added one, but a user will only know if
they check for an update.

> 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.

Sorry, I don't understand the issue you're raising.  Can you elaborate
what you mean by the trapdoor scenario?

In case you are suggesting that an implementation should transform a
v4 encryption-capable subkey into a v6 encryption-capable subkey if it
can't find the v6 certificate, I don't think that that is a good idea.
I think we should only use v6 if the user actually signals they are
willing to accept v6 messages.  And, I think we should use the
existance of the v6 certificate as the signal.  In that case, this
issue, as I understand it, disappears: if we have the v6 certificate,
we just use the v6 certificate directly.

> 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.

Although I think "doppelgangers" would be the most common construct,
the only requirement in my proposal is that the primary keys have the
same public key material and meta data.  Consider doing something
like:

  $ sq encrypt --cert-email [e-mail] ...

Imagine that sq finds my v4 certificate.  If we prefer v6, the next
step would be to check for a v6 certificate.  If that exists, then we
use can use that, even if it has a different encryption subkey.

> 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.

In my proposal, I was careful to ensure that there is only a single
possible mapping by requiring that the meta-data be the same.  This
prevents chains and the associated complexity, as there can only be at
most one equivalent certificate per version.

:) Neal