mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 08:45:04 -05:00
Merge branches 'feature/xep-0391', 'feature/xep-0060', 'feature/protoxep-cap' and 'feature/protoxep-jet-omemo'
This commit is contained in:
Jonas Wielicki
commit
746cbc7f38
213
inbox/cap.xml
213
inbox/cap.xml
@ -22,6 +22,18 @@
|
||||
<supersededby/>
|
||||
<shortname>cap</shortname>
|
||||
&flow;
|
||||
<revision>
|
||||
<version>0.0.3</version>
|
||||
<date>2017-10-06</date>
|
||||
<initials>fs</initials>
|
||||
<remark><p>Use a custom item value (CAP-V).</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.2</version>
|
||||
<date>2017-08-25</date>
|
||||
<initials>fs</initials>
|
||||
<remark><p>Use PubSub publish-options preconditions.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2017-04-20</date>
|
||||
@ -50,28 +62,91 @@
|
||||
|
||||
<section1 topic='Compare-And-Publish PubSub Items' anchor='cap'>
|
||||
|
||||
<p>In order to atomically compare-and-publish an item, a client
|
||||
sends an &IQ; with a 'pubsub' element qualified by the
|
||||
'urn:xmpp:pubsub:cap:0' namespace. The element MUST contain the same
|
||||
attributes and elements as the <publish/> element defined in
|
||||
&xep0060; <em>and</em> it MUST contain a previd attribute containing
|
||||
an item ID.</p>
|
||||
<section2 topic='PubSub Item Compare-And-Publish Value (CAP-V)' anchor='cap-v'>
|
||||
|
||||
<p>The PubSub service MUST only publish the item if the node's
|
||||
latest item ID is equal to the ID found in the 'previd'
|
||||
attribute.</p>
|
||||
<p>PubSub services supporting the Compare-And-Publish PubSub extension MUST include a Comapre-and-Publish value
|
||||
(CAP-V) for every item in every response. The CAP-V value MUST change if the content of the item changed and
|
||||
different item content under the same node MUST NOT yield the same CAP-V. A simple computation of the CAP-ID would
|
||||
be to hash the String representation of the item's content.</p>
|
||||
|
||||
<example caption='Publisher publishes an item using Compare-And-Publish'><![CDATA[
|
||||
<p>CAP-Vs are assoicated with PubSub node's items via the item ID. The maping information is placed by the PubSub
|
||||
service in a <cap-v-map/> extension element, qualified by the 'urn:xmpp:pubsub:cap:0' namespace, as child
|
||||
element of the <items/> element. The <cap-v-map/> element contains one or more <cap-v-map-entry/>
|
||||
elements, of which each MUST have a 'item-id' and a 'cap-value' attribute. The former contains the PubSub item ID
|
||||
value and the later contains the according CAP-V of the item.</p>
|
||||
|
||||
<example caption='Service returns some items and their according CAP-Vs'><![CDATA[
|
||||
<iq type='result'
|
||||
from='pubsub.shakespeare.lit'
|
||||
to='francisco@denmark.lit/barracks'
|
||||
id='items1'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<items node='princely_musings'>
|
||||
<item id='368866411b877c30064a5f62b917cffe'>
|
||||
<entry xmlns='http://www.w3.org/2005/Atom'>
|
||||
<title>The Uses of This World</title>
|
||||
<summary>
|
||||
O, that this too too solid flesh would melt
|
||||
Thaw and resolve itself into a dew!
|
||||
</summary>
|
||||
</entry>
|
||||
</item>
|
||||
<item id='3300659945416e274474e469a1f0154c'>
|
||||
<entry xmlns='http://www.w3.org/2005/Atom'>
|
||||
<title>Ghostly Encounters</title>
|
||||
<summary>
|
||||
O all you host of heaven! O earth! what else?
|
||||
And shall I couple hell? O, fie! Hold, hold, my heart;
|
||||
And you, my sinews, grow not instant old,
|
||||
But bear me stiffly up. Remember thee!
|
||||
</summary>
|
||||
</entry>
|
||||
</item>
|
||||
<item id='4e30f35051b7b8b42abe083742187228'>
|
||||
<entry xmlns='http://www.w3.org/2005/Atom'>
|
||||
<title>Alone</title>
|
||||
<summary>
|
||||
Now I am alone.
|
||||
O, what a rogue and peasant slave am I!
|
||||
</summary>
|
||||
</entry>
|
||||
</item>
|
||||
<cap-v-map xmlns='urn:xmpp:pubsub:cap:0'>
|
||||
<cap-value-map-entry
|
||||
item-id='368866411b877c30064a5f62b917cffe'
|
||||
cap-value='35a204c2-5d6c-43a2-8e0d-a235a627b04a'/>
|
||||
<cap-value-map-entry
|
||||
item-id='3300659945416e274474e469a1f0154c'
|
||||
cap-value='166b7c04-ed4d-4872-aa56-a58268da84e2'/>
|
||||
<cap-value-map-entry
|
||||
item-id='4e30f35051b7b8b42abe083742187228'
|
||||
cap-value='67f7f792-f2ee-4918-8894-36a3c4a6dd5f'/>
|
||||
</cap-v-map>
|
||||
</items>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
||||
</section2>
|
||||
|
||||
<section2 topic='PubSub publishing using Compare-And-Publish'>
|
||||
|
||||
<p>In order to atomically compare-and-publish an item, a client sends a <cite>XEP-0060</cite> <publish/> IQ
|
||||
with a 'pubsub#prev_item_cap_value' precondition publishing option, set to the value of the currently assumed CAP-V
|
||||
of the latest item of the node.</p>
|
||||
|
||||
<p>The PubSub service MUST only publish the item if the node's latest item CAP-V is equal to the
|
||||
CAP-V found in the 'pubsub#prev_item_cap_value' field.</p>
|
||||
|
||||
<example caption='Atomically publishing with Compare-And-Publish'><![CDATA[
|
||||
<iq type='set'
|
||||
from='hamlet@denmark.lit/blogbot'
|
||||
to='pubsub.shakespeare.lit'
|
||||
id='compare-and-publish1'>
|
||||
<pubsub xmlns='urn:xmpp:pubsub:cap:0'>
|
||||
<compare-and-publish
|
||||
node='princely_musings'
|
||||
previd='1'>
|
||||
<item>
|
||||
<entry xmlns='http://www.w3.org/2005/Atom'>
|
||||
id='pub1'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<publish node='princely_musings'>
|
||||
<item id='2'>
|
||||
<entry xmlns='https://example.org'>
|
||||
<title>Soliloquy</title>
|
||||
<summary>
|
||||
To be, or not to be: that is the question:
|
||||
@ -80,63 +155,73 @@ The slings and arrows of outrageous fortune,
|
||||
Or to take arms against a sea of troubles,
|
||||
And by opposing end them?
|
||||
</summary>
|
||||
<link rel='alternate' type='text/html'
|
||||
href='http://denmark.lit/2003/12/13/atom03'/>
|
||||
<id>tag:denmark.lit,2003:entry-32397</id>
|
||||
<published>2003-12-13T18:30:02Z</published>
|
||||
<updated>2003-12-13T18:30:02Z</updated>
|
||||
</entry>
|
||||
</item>
|
||||
</publish>
|
||||
<publish-options>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/pubsub#publish-options</value>
|
||||
</field>
|
||||
<field var='pubsub#prev_item_cap_value'>
|
||||
<value>1</value>
|
||||
</field>
|
||||
</x>
|
||||
</publish-options>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
||||
<section2 topic='Successfully published an item using Compare-And-Publish'>
|
||||
|
||||
<p>If the 'previd' matched the latest item's ID and if the service
|
||||
was able to successfully process the request then the protocol
|
||||
continues as defined in <cite>XEP-0060 7.1.2</cite>.</p>
|
||||
|
||||
</section2>
|
||||
|
||||
<section2 topic='Could not publish because newest item ID did not match'>
|
||||
|
||||
<p>In case the Compare-And-Publish operation failed because the
|
||||
latest node id is not the same as given in the 'previd' attribute
|
||||
in the request, the server returns an &IQ; result with 'pubsub'
|
||||
element qualified by the 'urn:xmpp:pubsub:cap:0' namespace which
|
||||
contains a <compare-and-publish-failed/> element. The
|
||||
element MUST have a 'id' attribute with the ID of the lastest
|
||||
item.</p>
|
||||
<p>In case the Compare-And-Publish operation failed because the latest node id is not the same
|
||||
as given in the 'previd' attribute in the request, the server returns an <conflict/> error
|
||||
of type 'modify' which a pubsub-specific condition of <precondition-not-met/> and a
|
||||
<compare-and-publish-failed/> element qualifed by the 'urn:xmpp:pubsub:cap:0'
|
||||
namespace. The element MUST have a 'cap-id' attribute with the CAP-V of the lastest item.</p>
|
||||
|
||||
<example caption='Service returns IQ response notifying of failed Compare-And-Publish operation'><![CDATA[
|
||||
<iq type='result'
|
||||
<example caption='Service returns IQ response notifying of failed Compare-And-Publish operation'><![CDATA[
|
||||
<iq type='error'
|
||||
from='pubsub.shakespeare.lit'
|
||||
to='hamlet@denmark.lit/blogbot'
|
||||
id='compare-and-ublish1'>
|
||||
<pubsub xmlns='urn:xmpp:pubsub:cap:0'>
|
||||
<compare-and-publish-failed id='2'/>
|
||||
</pubsub>
|
||||
to='hamlet@denmark.lit/elsinore'
|
||||
id='retract1'>
|
||||
<error type='modify'>
|
||||
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
<precondition-not-met xmlns='http://jabber.org/protocol/pubsub#errors'/>
|
||||
<compare-and-publish-failed xmlns='urn:xmpp:pubsub:cap:0' cap-id='2'/>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
||||
</section2>
|
||||
|
||||
<section2 topic='Error cases'>
|
||||
</section1>
|
||||
|
||||
<p>All other error cases are handled as specified in
|
||||
<cite>XEP-0060 § 7.1.3</cite></p>
|
||||
<section1 topic='Rationale' anchor='rationale'>
|
||||
|
||||
</section2>
|
||||
<p>Unfortunately it was not possible to re-use the PubSub item ID for the "Atomically
|
||||
Compare-And-Publish" purpose. This is mostly due <cite>XEP-0060 § 12.8</cite> stating that:</p>
|
||||
<p class='box'>
|
||||
"If a publisher publishes an item and the ItemID
|
||||
matches that of an existing item, the pubsub service MUST overwrite the existing item and generate a new event
|
||||
notification."
|
||||
</p>
|
||||
<p> Which means that the content of an item could change without its ID, rendering the item ID
|
||||
unusable for CAP. </p>
|
||||
|
||||
<p>Injecting a "cap"-namespaced attribute carrying the item's CAP-V into PubSub's <item/>
|
||||
would be a very elegant approach to assign CAP-Vs to PubSub items (and the favored one of the
|
||||
XEP's author). But the usage of namespaces attributes within XMPP is controversial. Therefore this
|
||||
XEP resorts to using the <cap-v-map/> approach for now.</p>
|
||||
|
||||
</section1>
|
||||
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
|
||||
<p>This extension protocol does not add any further security
|
||||
considerations to the ones mentioned in <cite>XEP-0060 §
|
||||
14.</cite>.</p>
|
||||
<p>This extension protocol does not add any further security considerations to the ones mentioned
|
||||
in <cite>XEP-0060 § 14.</cite>.</p>
|
||||
|
||||
</section1>
|
||||
|
||||
@ -153,17 +238,39 @@ And by opposing end them?
|
||||
<ul>
|
||||
<li>urn:xmpp:pubsub:cap:0</li>
|
||||
</ul>
|
||||
<code caption='Registry Submission'><![CDATA[
|
||||
<code caption='Registry Submission'><![CDATA[
|
||||
<var>
|
||||
<name>urn:xmpp:pubsub:cap:0</name>
|
||||
<desc>Indicates support for Compare-And-Publish</desc>
|
||||
<doc>XEP-XXXX</doc>
|
||||
<name>urn:xmpp:pubsub:cap:0</name>
|
||||
<desc>Indicates support for Compare-And-Publish</desc>
|
||||
<doc>XEP-XXXX</doc>
|
||||
</var>]]></code>
|
||||
|
||||
<p>This specification defines the following <publish-options/> fields:</p>
|
||||
<ul>
|
||||
<li>pubsub#prev_item_cap_value</li>
|
||||
</ul>
|
||||
<code caption='Registry Submission'><![CDATA[
|
||||
<field var='pubsub#prev_item_cap_value'
|
||||
type='text-single'
|
||||
label='Precondition: The assumed value of the latest item' CAP-V of the node'/>]]></code>
|
||||
|
||||
</section1>
|
||||
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
|
||||
<p>TODO: Add after the XEP leaves the 'experimental' state.</p>
|
||||
|
||||
</section1>
|
||||
|
||||
<section1 topic='Acknowledgements' anchor='acknowledgements'>
|
||||
|
||||
<p>Thanks to Kim Alvefur and Dave Cridland for their feedback.</p>
|
||||
|
||||
</section1>
|
||||
|
||||
</xep>
|
||||
|
||||
<!-- Local Variables: -->
|
||||
<!-- fill-column: 100 -->
|
||||
<!-- indent-tabs-mode: nil -->
|
||||
<!-- End: -->
|
||||
|
||||
133
inbox/jet-omemo.xml
Normal file
133
inbox/jet-omemo.xml
Normal file
@ -0,0 +1,133 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY secret "<secret/>">
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Jingle Encrypted Transports - OMEMO</title>
|
||||
<abstract>Extension for JET introducing OMEMO End-to-End Encrypted Jingle Transports.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>XXXX</number>
|
||||
<status>ProtoXEP</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XEP-0391</spec>
|
||||
<spec>XEP-0234</spec>
|
||||
<spec>XEP-0384</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>jet-omemo</shortname>
|
||||
<schemaloc>
|
||||
<ns>jingle</ns>
|
||||
<url>http://xmpp.org/schemas/jingle.xsd</url>
|
||||
</schemaloc>
|
||||
<schemaloc>
|
||||
<ns>jingle:errors</ns>
|
||||
<url>http://xmpp.org/schemas/jingle-errors.xsd</url>
|
||||
</schemaloc>
|
||||
<registry/>
|
||||
<discuss>jingle</discuss>
|
||||
<author>
|
||||
<firstname>Paul</firstname>
|
||||
<surname>Schaub</surname>
|
||||
<email>vanitasvitae@riseup.net</email>
|
||||
<jid>vanitasvitae@jabberhead.tk</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2017-10-06</date>
|
||||
<initials>vv</initials>
|
||||
<remark><p>First draft</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>&xep0391; can be used to utilize different end-to-end encryption methods to secure Jingle Transports, eg. in the context of &xep0234;. This document aims to extend &xep0391; to allow the use of OMEMO encryption with Jingle transports. To achieve this goal, this protocol extension makes use of OMEMOs <link url='https://xmpp.org/extensions/xep-0384.html#usecases-keysend'>KeyTransportElements</link>.</p>
|
||||
</section1>
|
||||
<section1 topic='Mappings' anchor='mappings'>
|
||||
<p>Conveniently the OMEMO protocol already provides a way to transport key material to another entity. So called KeyTransportElements are basically normal OMEMO MessageElements, but without a payload, so the contained key can be used for something else (See Section 4.6 of <cite>XEP-0384</cite>). This extension uses the key encrypted in the KeyTransportMessages <key> attribute and initialization vector from the <iv> attribute to secure Jingle Transports. The key corresponds to the <cite>Transport Key</cite> of <cite>XEP-0391</cite>, while the iv corresponds to the <cite>Initialization Vector</cite>. The KeyTransportMessage is the equivalent to the <cite>Envelope Element</cite>. Note that within the Envelope Element, the Transport Key is encrypted with the OMEMO ratchet.</p>
|
||||
</section1>
|
||||
<section1 topic='Limitaions' anchor='limitations'>
|
||||
<p>Unfortunately &xep0384; determines the type of the transported key to be AES-128-GCM-NoPadding, so no other configuration can be used in the context of this extension.</p>
|
||||
<p>Since OMEMO deviceIds are not bound to XMPP resources, the initiator MUST encrypt the Transport Key for every device of the recipient.</p>
|
||||
</section1>
|
||||
<section1 topic='Key Transport' anchor='transport'>
|
||||
<p>In order to transport a key to the responder, the initiator creates a fresh AES-128-GCM-NoPadding Transport Key and Initialization Vector and generates an OMEMO KeyTransportElement from it as described in <cite>XEP-0384</cite>. This is then added as a child of the JET <security> element. The 'cipher' attribute MUST be set to 'aes-128-gcm-nopadding:0' (see the <link url='https://xmpp.org/extensions/xep-0391.html#ciphers'>ciphers</link> section of <cite>XEP-0391</cite>). The value of the 'type' attribute must be set to the namespace of the used version of <cite>XEP-0384</cite> &VNOTE;.</p>
|
||||
<p></p>
|
||||
<example caption="Romeo initiates an OMEMO encrypted file offer"><![CDATA[
|
||||
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
|
||||
id='nzu25s8'
|
||||
to='juliet@capulet.example/yn0cl4bnw0yr3vym'
|
||||
type='set'>
|
||||
<jingle xmlns='urn:xmpp:jingle:1'
|
||||
action='session-initiate'
|
||||
initiator='romeo@montague.example/dr4hcr0st3lup4c'
|
||||
sid='851ba2'>
|
||||
<content creator='initiator' name='a-file-offer' senders='initiator'>
|
||||
<description xmlns='urn:xmpp:jingle:apps:file-transfer:5'>
|
||||
<file>
|
||||
<date>1969-07-21T02:56:15Z</date>
|
||||
<desc>This is a test. If this were a real file...</desc>
|
||||
<media-type>text/plain</media-type>
|
||||
<name>test.txt</name>
|
||||
<range/>
|
||||
<size>6144</size>
|
||||
<hash xmlns='urn:xmpp:hashes:2'
|
||||
algo='sha-1'>w0mcJylzCn+AfvuGdqkty2+KP48=</hash>
|
||||
</file>
|
||||
</description>
|
||||
<transport xmlns='urn:xmpp:jingle:transports:s5b:1'
|
||||
mode='tcp'
|
||||
sid='vj3hs98y'>
|
||||
<candidate cid='hft54dqy'
|
||||
host='192.168.4.1'
|
||||
jid='romeo@montague.example/dr4hcr0st3lup4c'
|
||||
port='5086'
|
||||
priority='8257636'
|
||||
type='direct'/>
|
||||
</transport>
|
||||
<security xmlns='urn:xmpp:jingle:jet:0'
|
||||
name='a-file-offer'
|
||||
cipher='urn:xmpp:ciphers:aes-128-gcm-nopadding'
|
||||
type='eu.siacs.conversations.axolotl'>
|
||||
<encrypted xmlns='eu.siacs.conversations.axolotl'>
|
||||
<header sid='27183'>
|
||||
<key rid='31415'>BASE64ENCODED...</key>
|
||||
<key prekey="true" rid='12321'>BASE64ENCODED...</key>
|
||||
<!-- ... -->
|
||||
<iv>BASE64ENCODED...</iv>
|
||||
</header>
|
||||
</encrypted>
|
||||
</security>
|
||||
</content>
|
||||
</jingle>
|
||||
</iq>]]></example>
|
||||
<p>The recipient decrypts the OMEMO KeyTransportElement to retrieve the Transport Secret. Transport Key and Initialization Vector are later used to encrypt/decrypt data as described in &xep0391;.</p>
|
||||
</section1>
|
||||
<section1 topic='Determining Support' anchor='support'>
|
||||
<p>To advertise its support for JET-OMEMO, when replying to service discovery information ("disco#info") requests an entity MUST return URNs for any version of this extension, as well as of the JET extension that the entity supports -- e.g., "urn:xmpp:jingle:jet-omemo:0" for this version, or "urn:xmpp:jingle:jet:0" for &xep0391; &VNOTE;.</p>
|
||||
<example caption="Service discovery information request"><![CDATA[
|
||||
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
|
||||
id='uw72g176'
|
||||
to='juliet@capulet.example/yn0cl4bnw0yr3vym'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>]]></example>
|
||||
<example caption="Service discovery information response"><![CDATA[
|
||||
<iq from='juliet@capulet.example/yn0cl4bnw0yr3vym'
|
||||
id='uw72g176'
|
||||
to='romeo@montague.example/dr4hcr0st3lup4c'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
<feature var='urn:xmpp:jingle:jet:0'/>
|
||||
<feature var='urn:xmpp:jingle:jet-omemo:0'/>
|
||||
</query>
|
||||
</iq>]]></example>
|
||||
<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
@ -20,6 +20,7 @@
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XEP-0004</spec>
|
||||
<spec>XEP-0030</spec>
|
||||
<spec>XEP-0059</spec>
|
||||
<spec>XEP-0068</spec>
|
||||
<spec>XEP-0082</spec>
|
||||
<spec>XEP-0131</spec>
|
||||
@ -49,6 +50,12 @@
|
||||
&stpeter;
|
||||
&ralphm;
|
||||
|
||||
<revision>
|
||||
<version>1.13.8</version>
|
||||
<date>2017-10-10</date>
|
||||
<initials>fs (XEP Editor: jwi)</initials>
|
||||
<remark><p>Add missing dependency on XEP-0059.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.13.7</version>
|
||||
<date>2017-08-24</date>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user