[openpgp] Re: Forwarding for v6 follow-up

Daniel Huigens <[email protected]>
Newsgroups gmane.ietf.openpgp
Message-ID <THXEzeoa80qUcvZKasVCeeoDa96_M9PiGtPo4HIl7dXaJ41wJPoepqO7RBi6TozWcGc7m9_udvoV6EkZJ2BucgrGXYC5RTDVzYiSejr9G94=@protonmail.com>
I'll be a bit contrarian here and lean the other way :)

On Thursday, July 31st, 2025 at 18:35, Andrew Gallagher wrote:
> I concur; I think it’s also cleaner from a protocol design point of view

I think defining a new packet is actually cleaner from a protocol design
point of view, because otherwise we have to duplicate a bunch of
algorithms in the algorithm ID registry (one for X25519 and possibly
X448, two for ML-KEM if we figure out how to do forwarding with that,
and then if the ML-KEM+NIST/BP draft gets adopted and they want to use
forwarding, that'll be more yet.. there's a kind of multiplicative
effect here that I think is not ideal).

Also, all of these algorithm IDs would only be relevant for a decrypter.
They will never appear in a public key, and can't be used for encryption.

> and much less likely to trigger interop issues - unknown algorithm code points are generally handled more gracefully than unknown packet types.

Interop issues aren't as relevant here as it's for decryption only,
and the forwarding server knows that the final recipient has accepted
the forwarding and therefore should support the forwarding scheme.

---

Also, if we're leaning towards defining new packets for persistent
symmetric keys (which seems to be the preference), I think it's cleaner
to do the same here, as well.

Best,
Daniel

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