[Standards] OMEMO Key Agreement

Daniel Gultsch daniel at gultsch.de
Thu Jun 1 10:22:27 UTC 2017

I went ahead an created a PR for XEP-0384 to match what is actually
implemented in the wild.
Here is a rendered version: https://gultsch.de/files/xep-0384.html
I also added a section about SignalProtocol not being public domain.

I haven't talked to Andy yet so I don't know if he would approve.

I changed the track from Standards to Historical.
I checked: Track changes have happened before and are apparently
possible if Council agrees.
I think this is the best way forward given that developers and users
who are *currently* looking for the OMEMO spec are probably looking
for this XEP and not OMEMO-NEXT.
Also we don't have to assign a new author as it would be the case if
XEP-0384 would become OMEMO-NEXT.


2017-06-01 7:03 GMT+02:00 Daniel Gultsch <daniel at gultsch.de>:
> Hi,
> a lot of what Dave said about future proofing spoke to me and I'm
> starting to think he (and the others) are right.
> It makes me wonder if we should work towards making OMEMO a good
> standard for a more distant future. In the past a lot of valid changes
> to OMEMO have been dismissed because they can not be implemented right
> now. What if we put all those changes in? (Element encryption, not
> using multiple PEP nodes for multiple devices, and so on). It will
> surely take time to properly define all that. But there is no rush. We
> have a pretty good thing going with 'siacs-omemo' right now. We can
> use that for the foreseeable future and switch to a no-compromise
> OMEMO once it's truly done.
> We could change the current OMEMO XEP to reflect what is actually
> implemented right now with 'siacs-OMEMO'. It would become an
> Informational XEP (or maybe historical). At the same time we start
> working on 'OMEMO-NEXT'. A new standards track XEP that incorporates
> all the good suggestions that aren't really viable right now but will
> be in the future once implementations have caught up. (Like the
> multiple items in a PEP node for example). I always said that
> Element-Encryption (stanza-content) is nice to have. It just takes
> time to define properly. Let's take that time for OMEMO-NEXT. And most
> importantly we don't have to worry about being Signal compatible with
> that one and can use crypto primitives that are future proof. I
> appreciate Remko was trying to make it work with OMEMO Key Agreement
> v2 but rolling the dice again and again until the key matches some
> criteria doesn't sound like something that should be in a standard.
> Client authors who are looking for a short term solution (and can live
> with the downsides) can implement OMEMO while all the protocol work
> would go into OMEMO-NEXT.
> - Daniel

More information about the Standards mailing list