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] _______________________________________________
