[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]