First draft.
+ End-to-end encrypted messaging is a popular feature within the community. + Various protocols like &xep0373; or &xep0384; have been proposed to allow sending encrypted messages. + &xep0343; and &xep0391; specify protocols for establishing an encrypted transport using Jingle to share files using &xep0234;. +
++ &xep-sfs; describes a protocol that can be used to share files, previously uploaded using &xep0363;, but lacks means of encrypting files. + This leaves files uploaded using &xep0363; without any standardized means of encrypting them. +
+This XEP describes a protocol building on top of &xep-sfs; to allow encrypting files.
++ This protocol is only meaningful for end-to-end encrypted file sharing when transported as end-to-end encrypted XML, like it's possible using &xep0420;. + However, usage without such end-to-end encryption still has its usecase, as it allows sharing files through untrusted intermediaries for as long as the intermediary XMPP servers, if any, are trusted. +
+Note: To make the examples in this document more readable, no end-to-end encryption is used.
++ Before sharing the file, the sending entity MUST create random symmetric private key and initialization vector (IV) as required by the selected encryption cipher (see Ciphers). The file is then encrypted using selected encryption cipher and the generated key and IV. After this it can be uploaded using &xep0363; or prepared for any other means of file sharing. +
++ The file is then shared using the protocol described in &xep-sfs;. + The <file/> metadata element still refers to the original file, i.e. it describes the original file name, size and hashes. The <size/> element and one or multiple <hash/> elements are REQUIRED when sending encrypted files. +
++ For the encrypted file, a source is added as an <encrypted/> element to the <sources/>. It carries an attribute cipher with the namespace of the encryption cipher being used. The <encrypted/> element contains a <key/> and an <iv/> element, containing both values as Base64-encoded strings. The <encrypted/> element MAY also include <hash/> elements as described in &xep0300;, referring to the hash of the encrypted file. At last, the <encrypted/> element also includes another <sources/> element as described in &xep-sfs;, specifying sources to obtain the encrypted file. + The outer <sources/> may contain additional sources that directly allow for end-to-end encrypted file transfers, for example &xep0234; using &xep0391;. +
+On receive of a message including a <file-sharing/> element, that has an <encrypted/> element in its sources, normal processing as described in &xep-sfs; applies.
++ When the receiving entity tries to obtain the file from the source described by the <encrypted/> element, it will try to obtain any of its inner sources instead. + On success, it decrypts the obtained file using the encryption cipher, private key and IV provided. + If the resulting file is larger than the number of bytes specified in the <size/> metadata element, the additional bytes are cut off. +
++ The protocol to attach a source described in &xep-sfs; can also be used to attach encrypted sources. + After receiving a file using encrypted means, it is RECOMMENDED to only attach additional sources that support encryption. +
+Note The following table was copied from &xep0391;.
+In order to encrypt the file, the sending entity must transmit a cipher key to the responder. There are multiple options available:
+| Namespace | +Type | +Length (bits) | +Parameters | +
|---|---|---|---|
| urn:xmpp:ciphers:aes-128-gcm-nopadding:0 | +AES | +Key: 128, IV: 96 | +GCM/NoPadding | +
| urn:xmpp:ciphers:aes-256-gcm-nopadding:0 | +AES | +Key: 256, IV: 96 | +GCM/NoPadding | +
For compatibility reasons, it is RECOMMENDED to append the GCM authentication tag to the uploaded file when using any AES cipher with GCM. The GCM authentication tag is not needed when using the protocol described in this document as a hash of the resulting file is transported independently.
+Yes.
+This document requires no interaction with &IANA;.
+The ®ISTRAR; includes 'urn:xmpp:esfs:0' in its registry of protocol namespaces (see &NAMESPACES;).
+First draft.
+ Several existing specification have the need to provide metadata on a file. + The only specification of an element that contains file metadata so far is + provided as part of &xep0234;. This resulted in the situation that XEPs like + &xep0385; depend on the mostly unrelated &xep0166; just for the metadata + element. The motiviation of this XEP is to get rid of such dependencies and + have a dedicated place to define a file metadata element. +
+
+ text/plain
+ test.txt
+ 2015-07-26T21:46:00+01:00
+ 6144
+ w0mcJylzCn+AfvuGdqkty2+KP48=
+]]>
+ The child elements of the <file/> element are as follows:
+| Element Name | +Description | +Example | +
|---|---|---|
| date | +Timestamp specifying the last modified time of the file (which MUST conform to the DateTime profile of &xep0082;). | +2015-07-26T21:46:00+01:00 | +
| dimensions | +Horizontal and vertical dimensions of image or video files, in pixels. | +1920x1080 | +
| desc | +A human readable description of the file. Multiple <desc/> elements MAY be included if different xml:lang values are specified. | +Picture of 24th XSF Summit | +
| hash | +A hash of the file content, using the <hash/> element defined in &xep0300; and qualifed by the 'urn:xmpp:hashes:2' namespace. Multiple hashes MAY be included for hash agility. | +see specification | +
| length | +Length of an audio or video file, in milliseconds. | +63000 | +
| media-type | +The media type of the file content, which SHOULD be a valid MIME-TYPE as registered with &IANA; (specifically, as listed at <http://www.iana.org/assignments/media-types>). If not specified, the content is assumed to be "application/octet-stream". | +text/plain | +
| name | +The name of the file. The name SHOULD NOT contain characters or character sequences that would be interpreted as a directory structure by the local file system (e.g. "/", "\", "../", etc.). If any such characters or character sequences are present (possibly because the local and remote file systems use different syntax for directory structure), they SHOULD be escaped (e.g., via percent-encoding) before using the name as part of any file system operation. See Security Considerations. | +text.txt | +
| size | +The length of the file's content, in bytes. | +6144 | +
| thumbnail | +A thumbnail element of the file, using the <thumbnail/> element defined in &xep0264; and qualified by the 'urn:xmpp:thumbs:1' namespace. Multiple thumbnails MAY be included for media type and size agility. | +see specification | +
+ All child elements are OPTIONAL, however, specifications making use of the + file metadata object MAY require providing some of these elements as part + of their specification. +
++ Caution needs to be exercised when using the <name/> of the metadata + to control any interaction with a file system. For example, a malicious + user could request a file with <name>/etc/passwd</name> or + include file system specific control patterns such as + <name>../../private.txt</name> to try and access a sensitive + file outside of the set of files intended to be shared. Or a malicious user + could offer a file named /etc/passwd to try and trick the receiver into + overwriting that or other sensitive files. Therefore, implementations + SHOULD escape any file system path separators in the <name/> before + using that value in any file system calls. +
++ It is RECOMMENDED for implementations to use the strongest hashing + algorithm available to both parties. See &xep0300; for further discussion. +
+This document requires no interaction with &IANA;.
+The ®ISTRAR; includes 'urn:xmpp:file:metadata:0' in its registry of protocol namespaces (see &NAMESPACES;).
+Thanks to the authors of &xep0234; which heavily inspired this XEP.
+First draft.
+ This is a reiteration on &xep0385; with some significant changes: +
++ To share a file, a user sends a message stanza including <file-sharing/> to the inteded recipient contact or group. + The <file-sharing/> element includes a <file/> metadata element as described in &xep-file-metadata; as well as a <sources/> element. + The <sources/> element provides one or multiple sources that the receiving client may use to obtain the file. +
++ It is RECOMMENDED that the file metadata specifies name, media-type, size and one or multiple hash elements as described in &xep0300;. + The hash elements provide end-to-end file integrity and allow efficient caching and flexible retrieval methods. +
++ The message MAY include a suitable fallback body. + The fallback body MUST NOT include any information that is not also represented in <file-sharing/>. + If the <sources/> element includes an <url-data/> element that can be represented as a single URL, adding a &xep0066; x-oob reference is RECOMMENDED for compatibility. +
+If the message has an empty body, it is RECOMMENDED to add a message processing hint, see &xep0334;, to indicate the message to be stored in message stores like &xep0313;.
++ On receive of a message including a <file-sharing/> element, the receiving entity SHOULD lookup in a local storage, whether the file with any of the proivded hashes has already been retrieved and is available. + In that case no transfer needs to be initated and the cached file can be used instead. +
++ If the file is not available locally, the file can be obtained by one of the sources listed in the <sources/> element. + If further sources have been attached (as described in Attaching a source), the receiving entity may also try to obtain the file from any of those. +
++ When the source is an <url-data/> element as described in &xep0103;, the receiving entity MAY obtain the file by downloading it from the specified URL. + If the URL uses HTTP or HTTPS and additional HTTP request information as specified in &xep0104; is provided, the receiving entity SHOULD use such information when obtaining the file. + When sending and receiving files using <url-data/>, it is RECOMMENDED to prefer secure protocols (e.g. HTTPS, FTPS). + Please read security considerations when implementing support for insecure URLs. +
++ When the source is a <jingle-pub/> element as described in &xep0358;, the receiving entity MAY obtain the file using the protocol described in &xep0358;. + If a <hash/> is provided, the receiving entity MAY obtain the file by requesting it as described in &xep0234;. +
++ If sources of any other type are provided, clients MAY attempt to obtain the files from such sources. + The details of obtaining such file are out of scope of this document. +
++ If the <media-type/> of the shared file is such that it can be displayed inline, the receiving entity MAY display the file inline. + If no <media-type/> is provided or the <media-type/> indicates that the file can not be displayed inline, i.e. when the media type is application/octet-stream, the receiving entity SHOULD NOT display the file inline and instead offer to download it or save it on the users file system. +
+TODO: The following section relies on &xep0367;, however other methods to attach information to another message like the recently proposed &xep0422; might be suitable here as well. This is to be clarified before advancing to Draft.
++ After a user shared a file using one entity and another entity in the conversation obtained it or found it in its local storage, that entity MAY announce that the file is now available with an additional source. + This increases availability of the file in case the sender goes offline before all the intended recipients were able to fetch the file. It also allows for peer-to-peer file distribution in group chats. +
++ The entity MUST NOT announce itself as an additional source before verifying that all hashes provided match the hash of the file. + If no hashes are provided, the entity SHOULD NOT announce itself as an additional source. +
+The attaching itself is performed by sending a message including a <sources> element with further sources using the protocol described in &xep0367;.
+Depending on the lifetime of the newly attached source, it may be useful to add a message processing hint, see &xep0334;, to indicate the message to be stored in message stores like &xep0313;.
++ If a <hash/> using any supported algorithm is provided, the receiving client SHOULD verify that the <hash/> of the announced file matches the obained file before presenting it to the user. + If no <hash/> is provided or the <hash/> elements provided use unsupported algorithms, receiving clients MUST ignore any attached sources from other senders and only obtain the file from the sources announced by the original sender. + If no <hash/> is provided or the <hash/> elements provided use unsupported algorithms, receiving clients MUST ignore any sources that use unsecure protocols (e.g. HTTP without TLS). +
++ For most methods of transferring a file proposed through the <sources/> element, obtaining files requires revealing private information like IP addresses to the sending user or third-parties. + Sources that do not require revealing private information to untrusted entities SHOULD be preferred by receiving entitites. + Receiving entities SHOULD ask users for confirmation before obtaining a file, if doing so would require revealing private information to untrusted entities. + If the protocol that is used when obtaining the file is not secure (e.g. HTTP without TLS), this SHOULD be considered as if the protocol reveals private information. +
++ The security considerations of &xep-file-metadata; apply. +
+This document requires no interaction with &IANA;.
+The ®ISTRAR; includes 'urn:xmpp:sfs:0' in its registry of protocol namespaces (see &NAMESPACES;).
+Thanks to the authors of &xep0385; which heavily inspired this XEP.
+First draft.
Stickers
Recently, demand to implement stickers, including their social feature of sharing sticker packs arised within the XMPP community. This specification is to fulfill this demand.
++ Sticker packs are stored on pubsub nodes. + They SHOULD be located at a personal eventing (PEP) node named "urn:xmpp:stickers:0" but MAY be located at a generic publish-subscribe node that is not attached to a user's IM account. + The pubsub node's access model SHOULD be set to 'open', so that other users can fetch sticker packs. +
++ Each sticker pack is one item on the pubsub node consisting of a <pack/> element. +
++ The <pack/> element includes elements <name/> and <summary/> to announce a name and summary of the sticker pack that can be displayed to users, respectively. + The summary MAY contain copyright and license information in user-readable format. + Multiple <name/> and <summary/> elements MAY be included given that no two elements of same name specify the same xml:lang. +
++ The <pack/> element MAY include a <restricted/> element to indicate that this sticker pack may not be used or imported by other users. +
++ The <pack/> element contains one or more <item/> elements that include details on the stickers in the pack. Each <item/> element has <file/> element as described in &xep-file-metadata;. The metadata MUST include one or multiple <hash/> elements as described in &xep0300;. All stickers in a pack MUST use the same algorithm for their <hash/> elements. The metadata MUST include one <desc/> element that is not qualified by a xml:lang attribute and describes the textual fallback (often an emoji or a sequence of emojis) of the sticker. Each <item/> element further has a <sources/> element as described in &xep-sfs; describing how to retrieve the image file of the sticker. Each <item/> element MAY include one or more <suggest/> elements that include a text that clients may replace with the sticker. <suggest/> elements MAY have an xml:lang attribute. +
++ Finally, the <pack/> element includes a single <hash/> element as described in &xep0300;, specifying the hash of the sticker pack. See next section on how such hash is generated. +
+Each sticker pack has a unique ID, which is used as the pubsub item's id. This ID is derived from a hash of significant information from a <pack/> element as outlined in this section.
+Processing <name/> and <summary/> elements:
+For each <name/> or <summary/> element:
+The result of this step is referenced as Meta string later.
+Processing <item/> elements:
+For each <item/> element:
+For each of <hash/> element in <file/>:
+The result of this step is referenced as Stickers string later.
+The ID of the sticker pack is dervied by taking the first 144 bit of the hash and encode it using Base64. This is equivalent to the first 24 characters of the Base64 encoded content of the <hash/> element.
+The sending entity uses &xep-sfs; to send the image file from the sticker pack. The <item/>'s <file/> and <sources/> elements from the sticker pack are used as a template. The sending entity MAY add additional <hash/> elements or sources.
+Additionally, the sending entity adds an element <sticker/> to the message. This element carries an attribute pack referring to the id of the pubsub item carrying the sticker pack. If the sticker pack resides on a pubsub item other than the senders personal eventing (PEP) node named "urn:xmpp:stickers:0", the sending entity must add additional attributes jid and node, referring to the jid of the pubsub node and the name of the node, respectively.
+The sending entity SHOULD use the <file/>'s <desc/> content as the message body, except if the sticker was selected based on a suggestion, in which case the content of the corresponding <suggest/> SHOULD be used.
+When receiving a message with a <sticker/> element, the receiving entity SHOULD consider the message and the <file-sharing/> element as a sticker.
+When receiving a sticker, the receiving entity may display the stickers image file inline or display the textual representation in the <desc/> element. The receiving entity SHOULD NOT display the received sticker only as a downloadable file.
+When receiving a sticker or any other reference to a sticker pack, the receiving entity may allow the user to import such sticker pack. The receiving entity SHOULD NOT offer to import a sticker pack that has a <restricted/> element.
+When importing a sticker pack, the entity SHOULD make all files that are part of the sticker pack locally available. The entity SHOULD duplicate the pubsub item from its original source to the users personal eventing (PEP) node named "urn:xmpp:stickers:0", preserving the pack id. The entity MAY remove any of the sources provided, and MAY make an effort to make the files available at additional sources, e.g. by using &xep0363;.
+After creating or importing a sticker pack, it can be shared using an xmpp:-uri as described in &xep0060;.
+When handling this URI, the entity SHOULD display a preview of the sticker pack and allow importing it as described above.
+Flickering, flashing or blinking stickers can induce seizures or other incapacitating physical reactions. It is RECOMMENDED that clients that support stickers have an option to disable animations and/or stickers entirely.
++ The security considerations of &xep-sfs; apply. +
+This document requires no interaction with &IANA;.
+The ®ISTRAR; includes 'urn:xmpp:stickers:0' in its registry of protocol namespaces (see &NAMESPACES;).
+