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:

Hi Daniel, Le mardi 14 janvier 2025, 09:18:21 heure normale d’Europe centrale Daniel Gultsch a écrit : I know that this is a challenge, and I think that experimental is for that: having a written specification help people to understand the feature and have test implementation. I believe that gateway e2ee is doable and necessary, and I have a working implementation in my email gateway (however, not yet perfect, as signing is not done at the moment, still better than plain text). Sure, as I've said in the other reply, I'm absolutely fine with that. Lets see if other people are interested in working on that. Of course there are not so many gateway developers, so it's more difficult to find than client developers. Best, Goffi

Honestly, why does OX care at all about user ID? It already knows what exact key is allowed, so what user id it does or doesn't have doesn't really affect security by much. OMEMO doesn't have user ids at all for example.

Hi, thank you for all your feedbacks, and sorry for the late answer, I'm overwhelmed. Le lundi 13 janvier 2025, 22:53:12 heure normale d’Europe centrale Marvin W a écrit : Actually the main use case is for OpenPGP, as it makes sense to re-use the key handling specified in XEP-0373, but the formatting is totally dependent of the legacy network. For other use cases, indeed it would be better to have everything paired. Actually my long term goal is to use webassembly for that with a system of verification/validation. Yeah that's right. In the case of MLS, I think that my specification is actually not needed at all. Good catch. I've seen that this topic has been discussed by Flow in a reply to this message. I'm clearly targeting email gateways here, and MIME fits. Plain should probably be handled too indeed, for decryption. The specification is mostly a link to relevant RFCs and how to map data (and any missing one can be added easily). I went with the idea that all major programming languages have a MIME implementation available already, and the main problem for devs is how to map XMPP data. Sure. The most important XEP is main mechanism, other 2 can be merged easily, at least for now. I went with 3 because XEP numbers are cheap (yeah I know there is a debate on that), but I'm fine with a single one at least for now. Best, Goffi

Hi Singpolyma, Le lundi 13 janvier 2025, 21:49:17 heure normale d’Europe centrale Stephen Paul Weber a écrit : Yes sure, I just thought that it would make formatter/encrypter discovery easier, but that's a detail and clearly not necessary. It'z explaining the general mechanism, and the wrapper to look for, how to detect the feature and exchange data. And no, the messaging protocol is handled by the gateways, it's only about encrypting payload, and teaching client how to do so. My long term goal is to have a generic, sandboxed, webassembly based mechanism that clients have to implement once for all. The case of OpenPGP is special because we can re-use large part of OX for that. Best, Goffi