Standard response: The process for XEPs in the XSF starts with the ProtoXEP submission - that part is to decide if the XSF should take on the work.
If the XSF does, it takes copyright of the XEP, and works on the contents. We do not have any IPR cover for something before this point, so I'm not particularly motivated toward reading and commenting on unsubmitted XEPs, sorry. Please do not try and change the process we have by adding a "pre submission" stage to it - we really don't need an additional stage (and if you think we do for some reason, we're probably doing something wrong to make you think that way). More useful response: All I'd need to accept a full-stanza encryption XEP is: a) A way to know if the encrypted contents are a full stanza or just body. b) A way to know which elements in the encrypted contents override those in the traditional payload. c) A way to know what encryption has been used. A challenge for (b) is that you don't always know what metadata elements might be added by a server on the way through, and some metadata elements you might include in the original (now encrypted) message may need to be both duplicated on the outer wrapper and changed en-route. An example is security labels, which need to be translated through different policies. As such, I'm not too worried if the (b) answer is quite a lot of hand-waving for now. I think (a) and (c) are trivial, though. If your proposal covers those, just submit it. On Wed, 15 May 2019 at 15:54, Paul Schaub <vanitasvi...@fsfe.org> wrote: > Thank you very much for your eager interest and numerous replies > *cough*, in other words, Thank you Florian for your reply :D > > I'm not quite sure, how exactly the process of negotiating expected > encrypted elements would look like. Do you think this may be done via or > similar to Entity Capabilities (XEP-0115)? I can see that this would > make it easier for adopters to gradually start implementing support for > one feature at a time (like start with support for <body/> encryption > and then successively add support for other elements as well), but at > the same time I feel like this could enable "downgrade" attacks and > would diminish the "encrypt *all* the sensitive things"-approach that I > aim for. > > For now I'm trying to give useful sensible suggestions on what elements > are allowed inside the envelopes content element. If later we learn that > there are elements that are definitely not allowed at all, we might want > to come up with some sort of incomplete list of forbidden elements. > > An alternative approach that some people suggested would be to replace > the envelopes content element with a normal message stanza. That way > implementations could simply decrypt that stanza, check it for forbidden > elements and remove those and then feed the cleaned stanza back into the > XML stream. That way the client wouldn't have to reimplement listeners > for all the events. On the other hand, the client would probably want to > somehow mark the decrypted stanza as end-to-end encrypted. > > What do you think of this approach? Is it better, worse than the current > proposal? (reminder: http://geekplace.eu/xeps/xep-sce/xep-sce.html ) > > I hope that there will be some more feedback from participants of this > list. I don't want to get the feedback only when the document lands in > the inbox folder ;). > If you think the idea behind the spec is a good idea - nice! If you > think it is a bad idea - even better! But please let me know why and > what you'd change. > > Happy Hacking! > Paul > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
