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. > 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. > 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 > 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. > Cheers, > > Linus Happy Hacking Paul > > > [1]: https://xmpp.org/extensions/xep-0420.html > [2]: https://qxmpp.org > [3]: https://xmpp.org/extensions/xep-0380.html > _______________________________________________ > 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] _______________________________________________
