mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 16:55:07 -05:00
Merge pull request #241 from linkmauve/eme
Explicit Message Encryption ProtoXEP: Add a 0.0.2 version
This commit is contained in:
commit
557c240e56
@ -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'>
|
||||
@ -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>
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user