[openpgp] Re: v4+v6

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

Hey Daniel,

On Mon, 10 Feb 2025 11:04:19 +0100,
Daniel Huigens wrote:
> >From my point of view, the most important use case for having a v6 key
> will be PQC. So, I'll focus on that part of your email:
> 
> On Sunday, February 9th, 2025 at 14:41, Neal H. Walfield wrote:
> > This scheme works, because it it possible to use the same key material
> > for both v4 and v6 keys. It works less well for PQC, but I think it
> > still partially works, because some PQC algorithms use a composite
> > scheme.
> > 
> > Given a certificate with an ML-DSA-65+Ed25519 primary key, (I think)
> > it is possible to extract just the Ed25519 public key, and compute the
> > corresponding v4 or v6 key. So we can go from a PQC certificate to v4
> > or v6 certificate.
> 
> The PQC draft says not to do this:
> https://www.ietf.org/archive/id/draft-ietf-openpgp-pqc-06.html#name-key-generation-2.
> Generally, reusing key material in different contexts is not advised,
> though I don't know whether there's a practical attack in this case,
> but it'd make the security analysis harder (or even fail to hold,
> formally speaking, as the text suggests).

Thanks for linking to that text.  Key reuse was my primary concern,
and that would be (is?) a K.O. argument.

> > Given a v4 or v6 key, we can't figure out the fingerprint of the
> > corresponding PQC key, because we don't have the PQC public key. But
> > if the PQC certificate is available, we can look it up by its Ed25519
> > public key.
> 
> Looking up the v6 (PQC) key from a keyserver when you only have a v4 key
> would seem like the most useful/important part of this, but this would
> only be possible if keyservers would allow looking up PQC keys by the
> Ed25519 public key, which seems complicated.

Perhaps I'm missing something, but I think this is the same level of
complexity as computing the imprint.

> Also, in general (even in the non-PQC case) this seems like a somewhat
> fragile way to look up a v6 key from a v4 key, because you don't know
> whether they reused the key material as you suggest, so the request
> might be insufficient (and conversely they might not have a v6 key
> at all, so the request might also be wasted).

Lots of update requests are wasted in the sense that they return
nothing.  For instance, how do we learn whether there is a key
replacement subpacket?  We have to periodically check for updates (or
wait for them via, e.g., an in-band signaling mechanism).  Most of
these checks return nothing, and that is okay, I think, but they do
serve a purpose: they help ensure that our local state is fresh.

> In essence, compared to this proposal, the key replacement draft places
> additional work on the key holder, to make things more straightforward
> and reliable for the key "consumers", so to speak. And I'd argue that's
> probably a good trade-off to make.

Interesting observation.  My impression is that the replacement key
subpacket introduces some complexity both for users (arranging the
cross signatures), and for the implementation (checking the various
constraints).  I think I need to play with an implementation a bit.

Thanks for your comments!

:) Neal