moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

XEP-0297 0.3

Browse Source
This commit is contained in:
Kevin Smith 2011-07-11 17:30:43 +01:00
parent 75c21a18f1
commit 8269062f5a
1 changed files with 15 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
xep-0297.xml
View File

@ -27,6 +27,13 @@
<jid>me@matthewwild.co.uk</jid>
</author>
&ksmith;
<revision>
<version>0.3</version>
<date>2011-07-11</date>
<initials>ks</initials>
<remark><p>Made security considerations more explicit.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2011-07-06</date>
@ -48,7 +55,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>There are many situations is which an entity needs to forward a previously sent message to another entity, such as forwarding an interesting message to a friend, or a server forwarding stored messages from an archive. Here we specify a simple encapsulation method for such forwarded messages.</p>
<p>There are many situations is which an entity needs to forward a previously sent message to another entity, such as forwarding an interesting message to a friend, or a server forwarding stored messages from an archive. Here we specify a simple encapsulation method for such forwarded messages. This format can be used in other specifications requiring the forwarding of messages, or used in isolation for a user to forward a message to another user (rather like email forwards).</p>
</section1>
<section1 topic='Requirements' anchor='requirements'>
@ -112,8 +119,15 @@
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Forwarding messages can reveal information about the original sender, including possible presence leaks as well as the message payloads themselves. Any extensions using this format must therefore consider the implications of this.</p>
<p>Forwarding can either be used as-is, or in the context of another specification, with different security considerations:</p>
<section2 topic='As-is' anchor='as-is-sc'>
<p>Receipt of a forwarded message from a third-party does not guarantee that the original message was actually received, or that the content has not been modified, by the forwarder. Integrity of the original message can only be determined through digital signing mechanisms such as described in &xep0285; and &xep0290;.</p>
<p>Considering the above an end-user client should take special care in its rendering of a forwarded message to ensure that the user cannot mistake it for a message received directly from the original sender.</p>
<p>An entity SHOULD NOT trust that forwards are genuine when receiving them unprovoked (i.e. outside the scope of another specification).</p>
</section2>
<section2 topic='Extensions' anchor='extensions-sc'>
<p>While security considerations are ultimately dependent upon the specifications using the format defined herein, forwarding introduces scope for message forgery such that authors of derivative specifications will need to address security considerations themselves. These need to cover which entities a client should accept forwards from, and which entities those are permitted to forward messages for. For example, a specification may choose to only trust forwards if they are received from the user's client, another client on the bare JID, or the user's server.</p>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[