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 : > [SNIP] > > 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. 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. > 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. Yeah that's right. > 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. In the case of MLS, I think that my specification is actually not needed at all. > 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. Good catch. I've seen that this topic has been discussed by Flow in a reply to this message. > > 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. I'm clearly targeting email gateways here, and MIME fits. Plain should probably be handled too indeed, for decryption. > 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). 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. > > 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. 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
