moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

Explicit Message Encryption ProtoXEP: Add a 0.0.2 version 

- Made the 'name' attribute optional for existing mechanisms.
- Added a remark about the possibility to hide encrypted messages
  following user input.
- Made explicit that this protocol affects any encryption mechanism,
  present or future, not only those listed here.
- Display the namespace of the encryption mechanism in the default
  messages.
- Remove the second example message, which didn’t add any useful
  information.
This commit is contained in:
Emmanuel Gil Peyrot 2016-08-28 16:05:02 +01:00
parent 6270772d6c
commit bddc7bd04a
1 changed files with 39 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
inbox/eme.xml
View File

@ -29,6 +29,20 @@
<email>linkmauve@linkmauve.fr</email>
<jid>linkmauve@linkmauve.fr</jid>
</author>
<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>
<revision>
<version>0.0.1</version>
<date>2016-08-14</date>
@ -77,7 +91,6 @@
id='secret1'>
<body>?OTR?v23?...</body>
<encryption xmlns='urn:xmpp:eme:0'
name='OTR'
namespace='urn:xmpp:otr:0'/>
</message>
]]></example>
@ -86,7 +99,8 @@
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'>
<p>🔒 This message was encrypted with OTR and could not be decrypted.</p>
<p>🔒 This message was encrypted with OTR (urn:xmpp:otr:0) and could not be
decrypted.</p>
</div>
<p>Juliet may then communicate to Romeo that she was unable to receive his
@ -104,7 +118,6 @@
</openpgp>
<body>This message is encrypted with OpenPGP for XMPP.</body>
<encryption xmlns='urn:xmpp:eme:0'
name='OpenPGP for XMPP'
namespace='urn:xmpp:openpgp:0'/>
</message>
]]></example>
@ -112,17 +125,19 @@
<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'>
<p>🔒 This message was encrypted with OpenPGP for XMPP, <link url="#">click
here</link> to enable this plugin.</p>
</div>
<div class='example'>
<p>🔒 This message was encrypted with OpenPGP for XMPP, downloading and
installing an appropriate plugin, your message will be displayed
shortly.</p>
<p>🔒 This message was encrypted with OpenPGP for XMPP
(urn:xmpp:openpgp:0), <link url="#">click here</link> to enable this
plugin.</p>
</div>
</section2>
<section2 topic='Protocols Supported' anchor='protocols'>
<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>
<table>
<tr>
<th>Name</th>
@ -156,7 +171,7 @@
<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>
<example caption='Client queries for entity features'><![CDATA[
<example caption='Client queries for entity features'><![CDATA[
<iq type='get'
id='disco1'
to='juliet@capulet.lit/balcony'
@ -165,7 +180,7 @@
</iq>
]]></example>
<example caption='Entity responds with features'><![CDATA[
<example caption='Entity responds with features'><![CDATA[
<iq type='result'
id='disco1'
to='romeo@montague.lit/orchard'
@ -195,12 +210,22 @@
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>
<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>
</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>
<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>
</section1>
<section1 topic='Security Considerations' anchor='security'>
@ -216,7 +241,7 @@
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>This specification defines the following XML namespace:</p>
<p>This specification defines the following XML namespace:</p>
<ul>
<li>'urn:xmpp:eme:0'</li>
</ul>
@ -241,8 +266,8 @@
<xs:element name="encryption">
<xs:complexType>
<xs:attribute type="xs:string" use="required" name="name"/>
<xs:attribute type="xs:string" use="required" name="namespace"/>
<xs:attribute type="xs:string" use="optional" name="name"/>
</xs:complexType>
</xs:element>