On Tue, 1 Sep 2020 17:03:59 +0200 Philipp Hörist <[email protected]> wrote:
> Am Di., 1. Sept. 2020 um 16:26 Uhr schrieb Linus Jahn <[email protected]>: > > > Hello folks, > > > > I'm planning to implement Stanza Content Encryption [1] in QXmpp [2] and I > > had > > a more detailed look at the XEP. Here are my open questions / suggestions: > > > > 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. > > > > 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> > > > There needs to be a container for the elements the encryption XEP needs > otherwise you would need to namespace all the children of <encrypted> with > urn:xmpp:super-e2ee:0 > > <encrypted xmlns='eu.siacs.conversations.axolotl'> > <header sid='27183'> > ... > </header> > <envelope xmlns='urn:xmpp:sce:0'> > > PGNvbnRlbnQgeG1sbnM9J3Vybjp4bXBwOnNjZTowJz48cGF5bG9hZD48Ym9keSB4bWxucz0namFi > > YmVyOmNsaWVudCc+SSBnb3QgaW4gZXZlcnlvbmUncyBob3N0aWxlIGxpdHRsZSBmYWNlLiBZZXMs > > IHRoZXNlIGFyZSBicnVpc2VzIGZyb20gZmlnaHRpbmcuIFllcywgSSdtIGNvbWZvcnRhYmxlIHdp > > dGggdGhhdC4gSSBhbSBlbmxpZ2h0ZW5lZC48L2JvZHk+PHggeG1sbnM9J2phYmJlcjp4Om9vYic+ > > PHVybD5odHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9GaWdodF9DbHViI1Bsb3Q8L3VybD48 > L3g+PC9wYXlsb2FkPjwvY29udGVudD4= > </envelope> > </encrypted> > > > header is a child that would have to be namespaced with > urn:xmpp:super-e2ee:0, as namespaces are inherited > > Not sure why you need to know that something is encrypted with SCE, you > find the encryption namespace and pass the stanza to the encryption module. Ahh ok, I actually thought the <encrypted/> element would directly contain the envelope data, sorry, nevermind. > > 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)? > > > > The famous fallback body, which client needs that? Only Pidgin? Client can > implement EME then they don't need to depend on a fallback body Well I actually think there also some important modern clients that don't have EME. I had a quick look at Dino and Conversations and only found code that writes the EME tag into the message. No code that actually handles the tag and displays it to the user when needed. Please correct me if I'm wrong here. I'd say, an exception for fallback bodies is worth thinking about. > > 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? > > > > In my opinion it should recommend using EME, SCE can’t replace EME because > not all encryption mechanisms use SCE, and we can’t say that future > encryption mechanisms will use SCE. > > SCE is for clients who don’t support a particular encryption mechanism, > right now they only need to implement EME and are fine for all eternity, if > we start to fragment that in recommending clients should not use EME when > using SCE, we end up in the same situation as before EME existed. I agree on that and I think ideally SCE should have a note about EME and recommend it. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
