Oh and PRs on the XEP are always welcome as well :P
Am 01.09.20 um 18:00 schrieb Linus Jahn: > On Tue, 1 Sep 2020 17:05:23 +0200 > Paul Schaub <[email protected]> wrote: > >> Hi Linus, >> >> thank you for your feedback! >> >> Am 01.09.20 um 16:25 schrieb Linus Jahn: >>> 1. The XEP suggests that each encryption method uses a <encrypted/> tag with >>> xmlns='<xep-namespace>'. However, since the <encryption/> element is not >>> defined by SCE, there's no way of recognising a stanza as encrypted using >>> SCE. I could only search for the elements defined by the supported >>> encryptions QXmpp (in my case) knows about. >> I would say SCE cannot be used by arbitrary encryption mechanisms >> without those mechanisms being aware of SCE. >> >> For example we could not implement SCE with siacs OMEMO because siacs >> OMEMO would not expect the SCE element inside the <encrypted/> element. >> >> Contrary to this, an encryption mechanism that is aware of - and makes >> use of SCE will expect an SCE content element as payload of its >> <encrypted/> element. It is also recommended for encryption mechanisms >> that make use of SCE to define a profile (possibly with its own >> namespace) that describes how to use the affix elements. >>> My suggestion would be to define the <encryption/> element in the SCE XEP >>> instead of redefining it in each of the encryption mechanisms. >>> >>> Instead of: >>> <encrypted xmlns="urn:xmpp:super-e2ee:0"> >>> ... >>> </encrypted> >>> >>> I'd suggest something like this: >>> <encrypted xmlns="urn:xmpp:sce:0" encryption="urn:xmpp:super-e2ee:0"> >>> ... >>> </encrypted> >> I can see your point of having an outer SCE element, as it would >> "streamline" the process of using novel encryption mechanisms with SCE, >> but I don't really see the benefit, as most likely that encryption >> mechanism would need an SCE profile anyways. I'd argue that from the >> namespace of an encryption mechanism you should be able to determine >> that an SCE element will be inside. > Yeah, I see and agree on that. Thanks for your explanation. > >>> 2. The XEP says that messages MUST NOT have an unencrypted <body/> element. >>> This means that I can't include a "fallback body" for clients that don't >>> support SCE. How should I solve this (without violating the XEP)? >> Hm, I haven't really thought of fallback bodies. The rule in the XEP is >> primarily meant to prevent applications from accidentally adding the >> secret message as a plaintext body to the message. But we may make an >> exception for fallback bodies indeed. > I'd be happy about an exception here. :) > >>> 3. How should SCE work with XEP-0380: Explicit Message Encryption [3]? >>> Should SCE maybe replace EME at some point (SCE also annotates the >>> encryption method)? Or should it maybe even recommend using EME in >>> combination? >> I'd say applications should add EME tags outside the SCE element. Your >> suggestion above would enable SCE to become an EME replacement, but >> that's really not my intention. SCE is really meant as a shared format >> for "inside the encryption" ;P > How about adding a recommendation of EME to the XEP? > >>> 4. Is encrypting a stanza with multiple encryptions allowed (optionally), >>> not recommended or forbidden? >> That's an exotic usecase I haven't really thought about yet. I guess as >> those elements will be direct child elements of the message, it's up to >> the encryption mechanism(s) to decide? I.e. OMEMO, OX etc. should decide >> whether additional <encrypted/> elements are allowed or not. > Seems reasonable. Maybe we could add that as a small note to the XEP. > >>> Cheers, >>> >>> Linus >> Happy Hacking >> Paul > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
