<div dir="ltr"><div class="gmail_extra">Hi,</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Sun, Oct 2, 2016 at 11:23 AM, Hanno Böck <span dir="ltr"><<a href="mailto:hanno@hboeck.de" target="_blank">hanno@hboeck.de</a>></span> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">* I assume your intention is to standardize an encryption layer only<br></span><span style="font-size:12.8px">  and not a new messaging protocol, right? (That's the way the thing<br></span><span style="font-size:12.8px">  that's commonly called the signal protocol is used right now due to<br></span><span style="font-size:12.8px">  various ecosystem constrains and also the explicit wish of its main<br></span><span style="font-size:12.8px">  developer.) With the implicit assumption that this protocol is<br></span><span style="font-size:12.8px">  supposed to be used within separate protocols that don't<br></span><span style="font-size:12.8px">  interoperate. I wonder if a design with lack of interoperability in<br></span><span style="font-size:12.8px">  mindmatches IETFs goals.<br></span></blockquote><div><br></div><div>Well, it would provide a building block for other IETF and non-IETF protocols to use. Nothing stops it from being used in an interoperable fashion. For example SIMPLE and XMPP clients could have a E2E secured communication via the protocol with the help of gateways. You just need to have some ID mapping so the correct keys for the crypto can be looked up. I think it would be a fit for standardization at the IETF.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-:3ih" class="gmail-a3s gmail-aXjCH gmail-m15785141b0af4a52">* How does this relate to other standardization efforts? (You already<br>
  mentioned olm, there's also OMEMO which is currently gaining some<br>
  traction.)</div></blockquote></div><div class="gmail_extra"><br></div>OMEMO is currently being adjusted to use Olm instead of Signal, so that it will be more implementation and standardization friendly [1], and will probably be standardized by the XSF afterwards.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra">Tobi</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] <a href="https://github.com/xsf/xeps/pull/251">https://github.com/xsf/xeps/pull/251</a> <br><br></div></div>