I went ahead an created a PR for XEP-0384 to match what is actually implemented in the wild. https://github.com/xsf/xeps/pull/470 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. cheers Daniel 2017-06-01 7:03 GMT+02:00 Daniel Gultsch <[email protected]>: > 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 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
