[Standards] Re: Proposed XMPP Extension: Gateway Relayed Encryption

Hi Goffi, Thanks a lot for working on this, it's indeed a very interesting endeavor and has potential to make gateways more practical. The attempt to generalize, trying to describe payload and encryption algorithm (formatter and encrypter) independently seems like it is effectively overcomplicating things. Realistically, there aren't going to be a lot of situations where formatter and encrypter are not effective paired together. Further, because the gateway server is the one to decide which formatter to use (as the client is unable to know that on its own), it can likely do shenanigans there. Basically the more formatters a client implements, the more likely it is that these formatters have partial overlap, allowing the server to modify what content is displayed in the client. Ruling out illegal formatter+encrypter combinations on the protocol level reduces this risk drastically. Some modern encryption systems, like MLS, solve this issue by specifying the content type inside the encrypted+signed part of the message. In those cases, the formatter should never be specified by the gateway as it is implied from the encryption system. I see you already made an attempt with putting PGP/MIME into this framework. You are referencing OX to base your PGP part on it, however OX requires the recipient to verify that the PGP key has a user id in the form "xmpp:<bare-jid>" (this is a MUST in XEP-0373 § 3.2). As the gateway can't add new user ids to the PGP key and the other end is not aware of XMPP being involved, this is almost impossible to work out in practice. For PGP there are two popular payloads (outside OX) that are popular: - Plain. This is already supported via XEP-0027. - PGP/MIME. This is what you basically do this for. As you can see with this example, the generalization into formatter and encrypter is already not that helpful with the PGP usecase although it's one of the few that has two popular payload formats in real world. You tried to draft a specification for a MIME GRE Formatter. However, MIME is not a payload format. The payload inside PGP/MIME is an Internet Message (RFC 822 / 2822 / 5322). IMO, the following two things would make more sense to specify as XEPs: - A XEP that describes how to process rfc822 messages as a client and how to interpret them into XMPP. This could technically be used with a message/rfc822 type XEP-0481 <content> element - yes I hate me for even suggesting that - but also other things, including: - A second XEP that describes how to do PGP/MIME over XMPP (that is transporting PGP-encrypted RFC822 messages and discovering the keys to use for this), with the obvious intent of it to be used in the context of gateways, but technically 100% valid to be used in other contexts. A note on the procedure on specifying this: I think it would have been better to first merge all of the three ProtoXEPs you proposed now in a single Experimental XEP and see from there how it develops. The XEP can still be split up in the same way as you did right now before moving to Stable, but to me it feels more natural to have them all in one, as changes to one are likely to affect the others and maybe during the development we discover that a different way to split them makes more sense. Marvin On Mon, 2025-01-13 at 21:30 +0100, Goffi wrote: