From 9fb1b093addcdce79485989c37484c6b71d4d0b0 Mon Sep 17 00:00:00 2001 From: Emmanuel Gil Peyrot Date: Wed, 17 Aug 2016 01:41:11 +0100 Subject: [PATCH] Inbox: Add Explicit Message Encryption XEP. --- inbox/eme.xml | 256 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 256 insertions(+) create mode 100644 inbox/eme.xml diff --git a/inbox/eme.xml b/inbox/eme.xml new file mode 100644 index 00000000..14664fbb --- /dev/null +++ b/inbox/eme.xml @@ -0,0 +1,256 @@ + + +%ents; +]> + + +
+ Explicit Message Encryption + This specification provides a way to mark encrypted messages so the + recipient can discover how to decrypt it. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XMPP IM + XEP-0030 + + + + EME + + Emmanuel Gil + Peyrot + linkmauve@linkmauve.fr + linkmauve@linkmauve.fr + + + 0.0.1 + 2016-08-14 + egp +

First draft.

 + +
+ + +

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.

+

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.

+ + + +

This document addresses the following requirements:

+
    +
  1. Enable a client to mark a message as encrypted.
    2. +
  2. Enable a client to determine whether a message was encrypted, no matter + the encryption mechanism used.
    3. +
  3. Enable a client to offer the user a possibility to decrypt a received + message (depending on the encryption method).
    4. +
  4. Enable a client to offer the user a possibility to decrypt subsequently + received messages.
    5. +
+

This document DOES NOT address the non-message usecases, encrypted + presence and iq have very different requirements than those defined + here.

+ + + + +

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:

+ + ?OTR?v23?... + + +]]> + +

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:

+
+

🔒 This message was encrypted with OTR and could not be decrypted.

+
+ +

Juliet may then communicate to Romeo that she was unable to receive his + message, through an error, or maybe out of band.

+

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.

+ + + ... + + This message is encrypted with OpenPGP for XMPP. + + +]]> + +

Upon receiving this message, Juliet’s current client prompts her to enable + a plugin, or even do it on its own, possible representations include:

+
+

🔒 This message was encrypted with OpenPGP for XMPP, click + here to enable this plugin.

+
+
+

🔒 This message was encrypted with OpenPGP for XMPP, downloading and + installing an appropriate plugin, your message will be displayed + shortly.

+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
NameNamespaceSpecification
OTRurn:xmpp:otr:0&xep0364;
Legacy OpenPGPjabber:x:encrypted&xep0027;
OpenPGP for XMPPurn:xmpp:openpgp:0&xep0373;
+ + + +

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:

+ + + +]]> + + + + ... + + ... + + +]]> + +

Support can also be determined via &xep0115;, a.k.a. "caps".

+ + + + +

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.

+

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.

+

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.

+ + + +

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.

+ + + +

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.

+ + + +

This document requires no interaction with the Internet Assigned Numbers + Authority (IANA).

+ + + + +

This specification defines the following XML namespace:

+
    +
  • 'urn:xmpp:eme:0'
    • +
+ + + + + + + + + + + The protocol documented by this schema is defined in + XEP-xxxx: http://xmpp.org/extensions/xep-xxxx.html + + + + + + + + + + + +]]> + + + +

Thanks to Mathieu Pasquet for his feedback.

+ +