2016-08-16 20:41:11 -04:00
|
|
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
|
|
|
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
|
|
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
|
|
|
|
%ents;
|
|
|
|
|
|
]>
|
|
|
|
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
|
|
|
|
<xep>
|
|
|
|
|
|
<header>
|
|
|
|
|
|
<title>Explicit Message Encryption</title>
|
|
|
|
|
|
<abstract>This specification provides a way to mark encrypted messages so the
|
|
|
|
|
|
recipient can discover how to decrypt it.</abstract>
|
|
|
|
|
|
&LEGALNOTICE;
|
2016-10-26 16:44:25 -04:00
|
|
|
|
<number>0380</number>
|
|
|
|
|
|
<status>Experimental</status>
|
2016-08-16 20:41:11 -04:00
|
|
|
|
<type>Standards Track</type>
|
|
|
|
|
|
<sig>Standards</sig>
|
|
|
|
|
|
<approver>Council</approver>
|
|
|
|
|
|
<dependencies>
|
|
|
|
|
|
<spec>XMPP Core</spec>
|
|
|
|
|
|
<spec>XMPP IM</spec>
|
|
|
|
|
|
<spec>XEP-0030</spec>
|
|
|
|
|
|
</dependencies>
|
|
|
|
|
|
<supersedes/>
|
|
|
|
|
|
<supersededby/>
|
|
|
|
|
|
<shortname>EME</shortname>
|
|
|
|
|
|
<author>
|
|
|
|
|
|
<firstname>Emmanuel Gil</firstname>
|
|
|
|
|
|
<surname>Peyrot</surname>
|
|
|
|
|
|
<email>linkmauve@linkmauve.fr</email>
|
|
|
|
|
|
<jid>linkmauve@linkmauve.fr</jid>
|
|
|
|
|
|
</author>
|
2016-10-26 16:44:25 -04:00
|
|
|
|
<revision>
|
|
|
|
|
|
<version>0.1</version>
|
|
|
|
|
|
<date>2016-10-26</date>
|
|
|
|
|
|
<initials>fs</initials>
|
|
|
|
|
|
<remark>
|
|
|
|
|
|
<p>Initial published version approved by the XMPP Council.</p>
|
|
|
|
|
|
</remark>
|
|
|
|
|
|
</revision>
|
2016-08-28 11:05:02 -04:00
|
|
|
|
<revision>
|
|
|
|
|
|
<version>0.0.2</version>
|
|
|
|
|
|
<date>2016-08-28</date>
|
|
|
|
|
|
<initials>egp</initials>
|
|
|
|
|
|
<remark><ul>
|
|
|
|
|
|
<li>Made the 'name' attribute optional for existing mechanisms.</li>
|
|
|
|
|
|
<li>Added a remark about the possibility to hide encrypted messages
|
|
|
|
|
|
following user input.</li>
|
|
|
|
|
|
<li>Made explicit that this protocol affects any encryption mechanism,
|
|
|
|
|
|
present or future, not only those listed here.</li>
|
|
|
|
|
|
<li>Display the namespace of the encryption mechanism in the default
|
|
|
|
|
|
messages.</li>
|
|
|
|
|
|
</ul></remark>
|
|
|
|
|
|
</revision>
|
2016-08-16 20:41:11 -04:00
|
|
|
|
<revision>
|
|
|
|
|
|
<version>0.0.1</version>
|
|
|
|
|
|
<date>2016-08-14</date>
|
|
|
|
|
|
<initials>egp</initials>
|
|
|
|
|
|
<remark><p>First draft.</p></remark>
|
|
|
|
|
|
</revision>
|
|
|
|
|
|
</header>
|
|
|
|
|
|
|
|
|
|
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
|
|
|
|
<p>In the past few years we have seen a strong interest in end to end
|
|
|
|
|
|
encryption, with multiple competing mechanisms being defined on top of
|
|
|
|
|
|
XMPP (e.g., &xep0027;, &xep0364; or &xep0373;). This specification
|
|
|
|
|
|
addresses the lack of proper discoverability of most of these solutions by
|
|
|
|
|
|
adding a machine-readable explanation of how a specific message has been
|
|
|
|
|
|
encrypted.</p>
|
|
|
|
|
|
<p>In a federated network where no central entity can mandate a particular
|
|
|
|
|
|
encryption mechanism, it becomes important to allow end users to know that
|
|
|
|
|
|
a message could not be decrypted (e.g., due to a missing plugin), and to
|
|
|
|
|
|
never fail to display that a message has been received due to that.</p>
|
|
|
|
|
|
</section1>
|
|
|
|
|
|
|
|
|
|
|
|
<section1 topic='Requirements' anchor='reqs'>
|
|
|
|
|
|
<p>This document addresses the following requirements:</p>
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Enable a client to mark a message as encrypted.</li>
|
|
|
|
|
|
<li>Enable a client to determine whether a message was encrypted, no matter
|
|
|
|
|
|
the encryption mechanism used.</li>
|
|
|
|
|
|
<li>Enable a client to offer the user a possibility to decrypt a received
|
|
|
|
|
|
message (depending on the encryption method).</li>
|
|
|
|
|
|
<li>Enable a client to offer the user a possibility to decrypt subsequently
|
|
|
|
|
|
received messages.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<p>This document DOES NOT address the non-message usecases, encrypted
|
|
|
|
|
|
presence and iq have very different requirements than those defined
|
|
|
|
|
|
here.</p>
|
|
|
|
|
|
</section1>
|
|
|
|
|
|
|
|
|
|
|
|
<section1 topic='Use Cases' anchor='usecases'>
|
|
|
|
|
|
<section2 topic='Basic Flow' anchor='flow'>
|
|
|
|
|
|
<p>Romeo, wanting to get Juliet’s attention but not wanting to reveal his
|
|
|
|
|
|
intentions to the montague.lit nor to the capulet.lit servers, sends an
|
|
|
|
|
|
encrypted message tagged as OTR, as follows:</p>
|
|
|
|
|
|
<example caption='Example of tagged message encrypted with OTR'><![CDATA[
|
|
|
|
|
|
<message to='juliet@capulet.lit/balcony'
|
|
|
|
|
|
from='romeo@montague.lit/orchard'
|
|
|
|
|
|
id='secret1'>
|
|
|
|
|
|
<body>?OTR?v23?...</body>
|
|
|
|
|
|
<encryption xmlns='urn:xmpp:eme:0'
|
|
|
|
|
|
namespace='urn:xmpp:otr:0'/>
|
|
|
|
|
|
</message>
|
|
|
|
|
|
]]></example>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Juliet’s client, noticing it does not have any OTR capability, will
|
|
|
|
|
|
display that the message was encrypted but that it is not able to decrypt
|
|
|
|
|
|
it instead of displaying the body, for example:</p>
|
|
|
|
|
|
<div class='example'>
|
2016-10-26 16:44:25 -04:00
|
|
|
|
<p>This message was encrypted with OTR (urn:xmpp:otr:0) and could not be
|
2016-08-28 11:05:02 -04:00
|
|
|
|
decrypted.</p>
|
2016-08-16 20:41:11 -04:00
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Juliet may then communicate to Romeo that she was unable to receive his
|
|
|
|
|
|
message, through an error, or maybe out of band.</p>
|
|
|
|
|
|
<p>Romeo, standing firm in his belief that they should not communicate
|
|
|
|
|
|
without encryption in their world where anyone could be a malicious
|
|
|
|
|
|
listener, then discovers that one of Juliet’s clients support &xep0373; and
|
|
|
|
|
|
subsequently starts an encrypted session using that protocol.</p>
|
|
|
|
|
|
<example caption='Example of tagged message encrypted with OX'><![CDATA[
|
|
|
|
|
|
<message to='juliet@capulet.lit/balcony'
|
|
|
|
|
|
from='romeo@montague.lit/orchard'
|
|
|
|
|
|
id='secret2'>
|
|
|
|
|
|
<openpgp xmlns='urn:xmpp:openpgp:0'>
|
|
|
|
|
|
...
|
|
|
|
|
|
</openpgp>
|
|
|
|
|
|
<body>This message is encrypted with OpenPGP for XMPP.</body>
|
|
|
|
|
|
<encryption xmlns='urn:xmpp:eme:0'
|
|
|
|
|
|
namespace='urn:xmpp:openpgp:0'/>
|
|
|
|
|
|
</message>
|
|
|
|
|
|
]]></example>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Upon receiving this message, Juliet’s current client prompts her to enable
|
|
|
|
|
|
a plugin, or even do it on its own, possible representations include:</p>
|
|
|
|
|
|
<div class='example'>
|
2016-10-26 16:44:25 -04:00
|
|
|
|
<p>This message was encrypted with OpenPGP for XMPP
|
2016-08-28 11:05:02 -04:00
|
|
|
|
(urn:xmpp:openpgp:0), <link url="#">click here</link> to enable this
|
|
|
|
|
|
plugin.</p>
|
2016-08-16 20:41:11 -04:00
|
|
|
|
</div>
|
|
|
|
|
|
</section2>
|
|
|
|
|
|
|
|
|
|
|
|
<section2 topic='Protocols Supported' anchor='protocols'>
|
2016-08-28 11:05:02 -04:00
|
|
|
|
<p>Any encryption mechanism using message as a transport is a candidate, and
|
|
|
|
|
|
MAY have a 'name' attribute to help the receiving client display it to the
|
|
|
|
|
|
user, in case this client doesn’t understand its namespace yet. A 'name'
|
|
|
|
|
|
attribute SHOULD NOT be included for the protocols listed herein, and
|
|
|
|
|
|
SHOULD be ignored by a receiving client:</p>
|
|
|
|
|
|
|
2016-08-16 20:41:11 -04:00
|
|
|
|
<table>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<th>Name</th>
|
|
|
|
|
|
<th>Namespace</th>
|
|
|
|
|
|
<th>Specification</th>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td>OTR</td>
|
|
|
|
|
|
<td>urn:xmpp:otr:0</td>
|
|
|
|
|
|
<td>&xep0364;</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td>Legacy OpenPGP</td>
|
|
|
|
|
|
<td>jabber:x:encrypted</td>
|
|
|
|
|
|
<td>&xep0027;</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td>OpenPGP for XMPP</td>
|
|
|
|
|
|
<td>urn:xmpp:openpgp:0</td>
|
|
|
|
|
|
<td>&xep0373;</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
<!--<tr>
|
|
|
|
|
|
<td>OMEMO</td>
|
|
|
|
|
|
<td>urn:xmpp:omemo:0</td>
|
|
|
|
|
|
<td>https://conversations.im/xeps/multi-end.html</td>
|
|
|
|
|
|
</tr>-->
|
|
|
|
|
|
</table>
|
|
|
|
|
|
</section2>
|
|
|
|
|
|
|
|
|
|
|
|
<section2 topic='Determining Support' anchor='disco'>
|
|
|
|
|
|
<p>If an entity supports the Encrypted Message Extension protocol, it MUST
|
|
|
|
|
|
report that by including a &xep0030; feature of "urn:xmpp:eme:0" in
|
|
|
|
|
|
response to disco#info requests:</p>
|
2016-08-28 11:05:02 -04:00
|
|
|
|
<example caption='Client queries for entity features'><![CDATA[
|
2016-08-16 20:41:11 -04:00
|
|
|
|
<iq type='get'
|
|
|
|
|
|
id='disco1'
|
|
|
|
|
|
to='juliet@capulet.lit/balcony'
|
|
|
|
|
|
from='romeo@montague.lit/orchard'>
|
|
|
|
|
|
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
|
|
|
|
|
</iq>
|
|
|
|
|
|
]]></example>
|
|
|
|
|
|
|
2016-08-28 11:05:02 -04:00
|
|
|
|
<example caption='Entity responds with features'><![CDATA[
|
2016-08-16 20:41:11 -04:00
|
|
|
|
<iq type='result'
|
|
|
|
|
|
id='disco1'
|
|
|
|
|
|
to='romeo@montague.lit/orchard'
|
|
|
|
|
|
from='juliet@capulet.lit/balcony'>
|
|
|
|
|
|
<query xmlns='http://jabber.org/protocol/disco#info'>
|
|
|
|
|
|
...
|
|
|
|
|
|
<feature var='urn:xmpp:eme:0'/>
|
|
|
|
|
|
...
|
|
|
|
|
|
</query>
|
|
|
|
|
|
</iq>
|
|
|
|
|
|
]]></example>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Support can also be determined via &xep0115;, a.k.a. "caps".</p>
|
|
|
|
|
|
</section2>
|
|
|
|
|
|
</section1>
|
|
|
|
|
|
|
|
|
|
|
|
<section1 topic='Business Rules' anchor='rules'>
|
|
|
|
|
|
<p>Entities MUST report a failure to the user if they cannot decrypt an
|
|
|
|
|
|
incoming message for any reason, and MAY prompt the user to install or
|
|
|
|
|
|
enable a plugin to decrypt it.</p>
|
|
|
|
|
|
<p>Entities SHOULD include a non-encrypted body as possible, since older
|
|
|
|
|
|
clients not supporting this protocol might otherwise ignore messages sent
|
|
|
|
|
|
with an unknown encryption, making both the sender frustrated that their
|
|
|
|
|
|
message did not get an answer, and the recipient frustrated that they never
|
|
|
|
|
|
saw any message.</p>
|
|
|
|
|
|
<p>A sender entity MAY include the <encryption/> element even if the
|
|
|
|
|
|
recipient doesn’t advertise support for it in their disco, or isn’t
|
|
|
|
|
|
currently connected, since the recipient may be using multiple clients with
|
|
|
|
|
|
different capabilities.</p>
|
2016-08-28 11:05:02 -04:00
|
|
|
|
<p>A sender entity MAY include a 'name' attribute for any encryption
|
|
|
|
|
|
mechanism not listed in this specification, to help the receiving entity
|
|
|
|
|
|
present it to the user, but SHOULD NOT include one for the ones listed
|
|
|
|
|
|
here.</p>
|
|
|
|
|
|
<p>A receiving entity MUST NOT use the 'name' attribute if it is present and
|
|
|
|
|
|
they already have a name associated with it.</p>
|
|
|
|
|
|
<p>A receiving entity MAY not display anything in case an encrypted message
|
|
|
|
|
|
has been received, if the user agreed to that behaviour.</p>
|
2016-08-16 20:41:11 -04:00
|
|
|
|
</section1>
|
|
|
|
|
|
|
|
|
|
|
|
<section1 topic='Internationalization Considerations' anchor='i18n'>
|
|
|
|
|
|
<p>When a message is marked with an encryption tag and can not be decrypted,
|
|
|
|
|
|
the body can safely be ignored and a localized message displayed
|
|
|
|
|
|
instead.</p>
|
2016-08-28 11:05:02 -04:00
|
|
|
|
<p>If an entity includes a 'name' attribute, it should attempt to localise it
|
|
|
|
|
|
to the best of its abilities for the receiving client.</p>
|
2016-08-16 20:41:11 -04:00
|
|
|
|
</section1>
|
|
|
|
|
|
|
|
|
|
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
|
|
|
|
<p>A malicious entity could try to mimick the style of a client’s failure
|
|
|
|
|
|
message, maybe including a link to a compromised plugin, so a client should
|
|
|
|
|
|
not make those missing plugin messages look like normal messages.</p>
|
|
|
|
|
|
</section1>
|
|
|
|
|
|
|
|
|
|
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
|
|
|
|
<p>This document requires no interaction with the Internet Assigned Numbers
|
|
|
|
|
|
Authority (IANA).</p>
|
|
|
|
|
|
</section1>
|
|
|
|
|
|
|
|
|
|
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
|
|
|
|
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
|
2016-08-28 11:05:02 -04:00
|
|
|
|
<p>This specification defines the following XML namespace:</p>
|
2016-08-16 20:41:11 -04:00
|
|
|
|
<ul>
|
|
|
|
|
|
<li>'urn:xmpp:eme:0'</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</section2>
|
|
|
|
|
|
</section1>
|
|
|
|
|
|
|
|
|
|
|
|
<section1 topic='XML Schema' anchor='schema'>
|
|
|
|
|
|
<code><![CDATA[
|
|
|
|
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
|
|
|
|
|
|
|
|
|
|
|
<xs:schema attributeFormDefault="unqualified"
|
|
|
|
|
|
elementFormDefault="qualified"
|
|
|
|
|
|
targetNamespace="urn:xmpp:eme:0"
|
|
|
|
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema">
|
|
|
|
|
|
|
|
|
|
|
|
<xs:annotation>
|
|
|
|
|
|
<xs:documentation>
|
|
|
|
|
|
The protocol documented by this schema is defined in
|
|
|
|
|
|
XEP-xxxx: http://xmpp.org/extensions/xep-xxxx.html
|
|
|
|
|
|
</xs:documentation>
|
|
|
|
|
|
</xs:annotation>
|
|
|
|
|
|
|
|
|
|
|
|
<xs:element name="encryption">
|
|
|
|
|
|
<xs:complexType>
|
|
|
|
|
|
<xs:attribute type="xs:string" use="required" name="namespace"/>
|
2016-08-28 11:05:02 -04:00
|
|
|
|
<xs:attribute type="xs:string" use="optional" name="name"/>
|
2016-08-16 20:41:11 -04:00
|
|
|
|
</xs:complexType>
|
|
|
|
|
|
</xs:element>
|
|
|
|
|
|
|
|
|
|
|
|
</xs:schema>
|
|
|
|
|
|
]]></code>
|
|
|
|
|
|
</section1>
|
|
|
|
|
|
|
|
|
|
|
|
<section1 topic='Acknowledgements' anchor='ack'>
|
|
|
|
|
|
<p>Thanks to Mathieu Pasquet for his feedback.</p>
|
|
|
|
|
|
</section1>
|
|
|
|
|
|
</xep>
|
