[openpgp] Re: v4+v6

andrewg <[email protected]>
Newsgroups gmane.ietf.openpgp
Message-ID <[email protected]>
Hey, Neal.

On 2025-02-10 10:21, Neal H. Walfield wrote:
> 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.

A user should(?) be performing refresh requests on the original anyway. 
This new mechanism would mean at least doubling the number of refreshes 
(once for v4 and once for v6, possibly more) in every client that 
supports it, even if nobody ever creates such a key.

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

I mean a scenario where a keyholder wants their correspondents to 
upgrade from an original to a replacement if possible, but doesn't want 
to allow fallback to the original. If it was customary for all of the v4 
encryption subkeys to be duplicated onto the v6 doppelganger, then there 
would be no scenario where a correspondent would find the v6 cert, see 
no usable subkeys on it, then search for the v4 cert and find new usable 
subkeys. In that scenario following a reverse subpacket isn't useful, so 
we could keep things simple by assuming a trapdoor and not bothering to 
fall back.

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

No, I'm not suggesting that, that would be bad. :-)

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

I just meant that there are more than two versions in the wild already, 
and at some point presumably we may specify a version 7, so there may 
well be a chain "4->(5?)->6->7". To be fair, it does have an intrinsic 
ordering - it just may not be the order that the keyholder wants... ;-)

Thanks again,
A

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.