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.
> 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
> 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.
regards
Philipp
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
