From 5679b6eb0f1652b280f839572f26582f8c3175d9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 24 Nov 2020 18:45:52 +0100 Subject: [PATCH 1/8] Accept inbox/ibr-token.xml as XEP-0445 --- xep-0445.xml | 199 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 199 insertions(+) create mode 100644 xep-0445.xml diff --git a/xep-0445.xml b/xep-0445.xml new file mode 100644 index 00000000..e50a8dbb --- /dev/null +++ b/xep-0445.xml @@ -0,0 +1,199 @@ + + +%ents; +]> + + +
+ Pre-Authenticated In-Band Registration + This document extends the In-Band-Registration protocol to use + invitation tokens, e.g. for registering accounts on non-public + servers. + + &LEGALNOTICE; + 0445 + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0077 + XEP-0147 + XEP-0379 + XEP-0401 + + + + ibr-token + + Georg + Lukas + + + 0.2.0 + 2020-11-24 + XEP Editor (jsc) + Accepted by vote of Council on 2020-11-04. + + + 0.1.0 + 2020-10-28 + gl + First version based on XEP-0401. + +
+ +

There are two typical mechanisms to register an account on an XMPP server:

+
    +
  • Out-of-band account creation, after which the account JID and password + need to be manually entered into an XMPP client, and
    • +
  • &xep0077; (IBR) where an account is created and fully configured right + from the XMPP client.
    • +
+

The IBR mechanism is much more convenient for users, but also opens up + the server to abuse, e.g. due to the mass-registration of spam bot + accounts. Captchas, while heavily impacting well-intentioned users, are + not a reliable mechanism to prevent abuse. This specification allows to + restrict the IBR mechanism by requiring a registration token, e.g. for + giving users access to a private server, without exposing their password + to the server administrator.

+

This specification is part of a series of documents aiming at improving + user onboarding:

+
    +
  • &xep0379; to automatically accept roster subscriptions based on a + token.
    • +
  • &xep0401; to generate tokens that can be used for authenticating IBR.
    • +
+

While this specification is designed to work together with &xep0401;, it + can be used with invitation tokens obtained by any other mechanism. XMPP + URIs can then be used out-of-band to deliver the invitation to a new user.

+

A client that obtains such an XMPP URI should allow the user to register + an XMPP account with the server that generated the URI.

+ + + +

A client that implements this specification needs to understand the + &xep0147; specification, to make use of the register query + action and the preauth parameter. Three URI formats + are defined.

+ +

An invitation to register an account can contain a specific XMPP + address (with a pre-defined user account name) to be registered. A + client should populate the address field in the IBR dialog with this + address and disallow changing the address.

+ xmpp:juliet@example.com?register;preauth=TOKEN + + + +

An invitation to register an account can contain just the server domain + to register on. A client should populate the address field in the IBR + dialog with this domain and allow entering the desired account name.

+ xmpp:example.com?register;preauth=TOKEN + + + +

A contact invitation with a registration token (&xep0379;) might + indicate that the token can also be used to register an account on that + server (ibr=y). If the receiving client already has an account + configured, it may skip account registration and simply add the contact + as defined in XEP-0379. The client may also register a new + account on the domain of the proposed contact, allowing the user to + enter the desired account name.

+ xmpp:romeo@example.com?roster;preauth=TOKEN;ibr=y + + + + +

While a registration URI is an indication that the respective server + supports Pre-Authenticated IBR, a URI might be manipulated and is not + guaranteed to be reliable.

+

Therefore, when performing the account creation, the client needs to + ensure that the server supports the Pre-Authenticated IBR protocol, as denoted by + the <register xmlns='urn:xmpp:ibr-token:0'> + stream feature:

+ + + EXTERNAL + SCRAM-SHA-1-PLUS + SCRAM-SHA-1 + PLAIN + + + + +]]> + + +

In order to allow invited users to register on a server, the + registration processs as defined in &xep0077; needs to be extended. The + invited user's client needs to connect to the server and check that the + invitation stream feature + (<register xmlns='urn:xmpp:ibr-token:0'>) is present. + After that, the client initiates the registration flow by sending the + preauth token to the server:

+ + + +]]> +

Upon receiving the preauth request, the server must validate that the + token is acceptable for account registration. However, single-use tokens + MUST NOT be considered used until the actual registration has succeeded. +

+

In addition, if the token has an expiration time, it MUST only be + checked at this point. Subsequent actions performed by the client during + the current session that require a valid token MUST NOT be rejected due + to token expiry. +

+

If the token is acceptable, the server responds with success, and + indicates the client may now proceed with account registration: +

+ +]]> +

If the token provided by the client was unknown, invalid or expired, the + server should return an appropriate error to the client:

+ + + + The provided token is invalid or expired + + +]]> +

In the success case, the client proceeds with registration as defined in + &xep0077;. If the token is rejected by the server, the client still MAY + attempt to perform IBR if the server allows that.

+ + +

If a username was specified when creating an invitation token, the + server SHOULD NOT create an account on the server until the invitee + actually registers it with the corresponding token. + The server MUST reserve the username at least until the corresponding + token expires.

+ + + +

If the invitee opens an invitation URI with ibr=y and + chooses to create a new account, the client SHOULD pre-fill the + inviter JID's domain part as the new account's domain. The client MAY + provide a mechanism to enter or choose a different server, though.

+ + + +

See security considerations in &xep0379;.

+ + +

This document requires no interaction with &IANA;.

+ + +

This document only makes use of the XMPP URI elements defined in + &xep0401;

+ + +

REQUIRED for protocol specifications.

+ + From 6a24bb0eecefd2fdea11955ab373723429d124a8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 24 Nov 2020 18:48:17 +0100 Subject: [PATCH 2/8] XEP-0443: Accept as Draft --- xep-0443.xml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/xep-0443.xml b/xep-0443.xml index e94b564f..3eb64e84 100644 --- a/xep-0443.xml +++ b/xep-0443.xml @@ -22,7 +22,7 @@ &LEGALNOTICE; 0443 - Proposed + Draft 2020-11-03 Standards Track Standards @@ -63,6 +63,12 @@ georg@op-co.de georg@yax.im + + 1.0.0 + 2020-11-24 + XEP Editor (jsc) + Accept as Draft as per Council vote from 2020-11-11. + 0.3.0 2020-11-10 From 250b4daf544e53da01355331f5445221b1cfa305 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 24 Nov 2020 18:48:48 +0100 Subject: [PATCH 3/8] Update xep.ent --- xep.ent | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xep.ent b/xep.ent index d9e84f75..0106a53e 100644 --- a/xep.ent +++ b/xep.ent @@ -1607,3 +1607,6 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates SASL Channel-Binding Type Capability (XEP-0440) XEP-0440: SASL Channel-Binding Type Capability <https://xmpp.org/extensions/xep-0440.html>." > Message Archive Management Preferences (XEP-0441) XEP-0441: Message Archive Management Preferences <https://xmpp.org/extensions/xep-0441.html>." > Pubsub Message Archive Management (XEP-0442) XEP-0442: Pubsub Message Archive Management <https://xmpp.org/extensions/xep-0442.html>." > +XMPP Compliance Suites 2021 (XEP-0443) XEP-0443: XMPP Compliance Suites 2021 <https://xmpp.org/extensions/xep-0443.html>." > +Message Reactions (XEP-0444) XEP-0444: Message Reactions <https://xmpp.org/extensions/xep-0444.html>." > +Pre-Authenticated In-Band Registration (XEP-0445) XEP-0445: Pre-Authenticated In-Band Registration <https://xmpp.org/extensions/xep-0445.html>." > From 033ad4007aef144d52235913f469551685e7299c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 24 Nov 2020 18:51:31 +0100 Subject: [PATCH 4/8] tools: auto-generate entity into xep.ent upon acceptance --- tools/accept.py | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tools/accept.py b/tools/accept.py index 0ffd4a1b..8d99e7cc 100644 --- a/tools/accept.py +++ b/tools/accept.py @@ -70,6 +70,11 @@ def accept_xep(number, last_version, f.write(xep_text) f.flush() + subprocess.check_call(["make", "build/xeplist.xml"]) + + with open("xep.ent", "ab") as f: + f.write(subprocess.check_output(["python3", "tools/makeent.py", str(number)])) + def isodate(s): return datetime.strptime(s, "%Y-%m-%d") @@ -199,7 +204,7 @@ def main(): "git", "reset", "HEAD", ".", ]) subprocess.check_call([ - "git", "add", new_filename.parts[-1], + "git", "add", new_filename.parts[-1], "xep.ent", ]) if args.ask: flags = ["-ve"] From 6111f69d579fee1a7d8a8f63b7920fe2d1319a03 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 24 Nov 2020 18:52:08 +0100 Subject: [PATCH 5/8] Accept inbox/file-metadata.xml as XEP-0446 --- xep-0446.xml | 152 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 153 insertions(+) create mode 100644 xep-0446.xml diff --git a/xep-0446.xml b/xep-0446.xml new file mode 100644 index 00000000..8b71fc06 --- /dev/null +++ b/xep-0446.xml @@ -0,0 +1,152 @@ + + + %ents; + ]> + + +
+ File metadata element + This specification defines a generic file metadata element to be used in other specifications. + &LEGALNOTICE; + 0446 + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + XEP-0082 + XEP-0264 + XEP-0300 + + + + file-metadata + &larma; + + 0.1.0 + 2020-11-24 + XEP Editor (jsc) + Accepted by vote of Council on 2020-11-18. + + + 0.0.1 + 2020-11-03 + lmw +

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 NameDescriptionExample
dateTimestamp specifying the last modified time of the file (which MUST conform to the DateTime profile of &xep0082;).2015-07-26T21:46:00+01:00
dimensionsHorizontal and vertical dimensions of image or video files, in pixels.1920x1080
descA human readable description of the file. Multiple <desc/> elements MAY be included if different xml:lang values are specified.Picture of 24th XSF Summit
hashA 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
lengthLength of an audio or video file, in milliseconds.63000
media-typeThe 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
nameThe 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
sizeThe length of the file's content, in bytes.6144
thumbnailA 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;).

+
    +
  • urn:xmpp:file:metadata:0
    • +
+ + + +

Thanks to the authors of &xep0234; which heavily inspired this XEP.

+ + diff --git a/xep.ent b/xep.ent index 0106a53e..71367d24 100644 --- a/xep.ent +++ b/xep.ent @@ -1610,3 +1610,4 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates XMPP Compliance Suites 2021 (XEP-0443) XEP-0443: XMPP Compliance Suites 2021 <https://xmpp.org/extensions/xep-0443.html>." > Message Reactions (XEP-0444) XEP-0444: Message Reactions <https://xmpp.org/extensions/xep-0444.html>." > Pre-Authenticated In-Band Registration (XEP-0445) XEP-0445: Pre-Authenticated In-Band Registration <https://xmpp.org/extensions/xep-0445.html>." > +File metadata element (XEP-0446) XEP-0446: File metadata element <https://xmpp.org/extensions/xep-0446.html>." > From 13cb0f7ac5d7c5e70eeb17b320140ab13479f3e5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 24 Nov 2020 18:52:31 +0100 Subject: [PATCH 6/8] Accept inbox/sfs.xml as XEP-0447 --- xep-0447.xml | 208 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 209 insertions(+) create mode 100644 xep-0447.xml diff --git a/xep-0447.xml b/xep-0447.xml new file mode 100644 index 00000000..3e4e15af --- /dev/null +++ b/xep-0447.xml @@ -0,0 +1,208 @@ + + +File metadata element (XEP-xxxx) XEP-xxxx: File metadata element <https://xmpp.org/extensions/inbox/file-metadata.html>." > + +%ents; +]> + + +
+ Stateless file sharing + This specification describes a protocol for stateless asynchronous file sharing with integrity and transport flexibility. It allows clients to provide a good interoperable user experience in combination with Carbons and MAM. + &LEGALNOTICE; + 0447 + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + XEP-xxxx + + + + sfs + &larma; + + 0.1.0 + 2020-11-24 + XEP Editor (jsc) + Accepted by vote of Council on 2020-11-18. + + + 0.0.1 + 2020-11-10 + lmw +

First draft.

 + +
+ +

+ This is a reiteration on &xep0385; with some significant changes: +

+
    +
  • No focus on media, generic for every file type.
    • +
  • No mixed content, body is used for fallback only and not to transmit additional information.
    • +
  • Using &xep-file-metadata;.
    • +
  • Using XML for structured data instead of URIs when possible, adding further extensibility (like providing proper means of sharing encrypted files on http servers).
    • +
  • Not relying on underspecified usage of &xep0372;.
    • +
+ + +
    +
  • Do not require any server components for easier deployment
    • +
  • Should work and enable a good UX in multi-user chats like &xep0045; and &xep0369;
    • +
  • Should work great together with conversation synchronization protocols like &xep0280; and &xep0313;
    • +
  • Reuse existing protocols for the actual transport of the data, i.e. &xep0234; or &xep0363;
    • +
  • Guarantee file integrity
    • +
  • Enable aggresive caching
    • +
  • Provide users with metadata, e.g. file size, file type or thumbnail, to help them decide whether or not they want to load the file
    • +
  • Support referring to third party hosting services
    • +
  • Backwards compatibility with existing, widely-deployed protocols
    • +
+ + + +

+ 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. +

+ + + + image/jpeg + summit.jpg + 3032449 + 4096x2160 + 2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU= + 2AfMGH8O7UNPTvUVAM9aK13mpCY= + Photo from the summit. + + + + + + + + + + +]]> +

+ 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. +

+ + + + + Photo from the summit: https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg + https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg + +]]> +

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;).

+
    +
  • urn:xmpp:sfs:0
    • +
+ + + +

Thanks to the authors of &xep0385; which heavily inspired this XEP.

+ + diff --git a/xep.ent b/xep.ent index 71367d24..880e0048 100644 --- a/xep.ent +++ b/xep.ent @@ -1611,3 +1611,4 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates Message Reactions (XEP-0444) XEP-0444: Message Reactions <https://xmpp.org/extensions/xep-0444.html>." > Pre-Authenticated In-Band Registration (XEP-0445) XEP-0445: Pre-Authenticated In-Band Registration <https://xmpp.org/extensions/xep-0445.html>." > File metadata element (XEP-0446) XEP-0446: File metadata element <https://xmpp.org/extensions/xep-0446.html>." > +Stateless file sharing (XEP-0447) XEP-0447: Stateless file sharing <https://xmpp.org/extensions/xep-0447.html>." > From f28b5b5510736a6315fc210803f425b9722a6364 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 24 Nov 2020 18:52:46 +0100 Subject: [PATCH 7/8] Accept inbox/esfs.xml as XEP-0448 --- xep-0448.xml | 166 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 167 insertions(+) create mode 100644 xep-0448.xml diff --git a/xep-0448.xml b/xep-0448.xml new file mode 100644 index 00000000..2d8a2af9 --- /dev/null +++ b/xep-0448.xml @@ -0,0 +1,166 @@ + + +Stateless file sharing (XEP-xxxx) XEP-xxxx: Stateless file sharing <https://xmpp.org/extensions/inbox/sfs.html>." > + +%ents; +]> + + +
+ Encryption for stateless file sharing + This specification provides a protocol for sharing encrypted files using the stateless file sharing protocol (XEP-xxxx). + &LEGALNOTICE; + 0448 + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + XEP-xxxx + + + + esfs + &larma; + + 0.1.0 + 2020-11-24 + XEP Editor (jsc) + Accepted by vote of Council on 2020-11-18. + + + 0.0.1 + 2020-11-10 + lmw +

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.

+ + +
    +
  • Make use of existing protocols for end-to-end encryption (&xep0373; and &xep0420;)
    • +
  • Reuse existing protocols for the actual transport of the data
    • +
  • Allow caching and forwarding without being required to decrypt the file
    • +
  • Backwards compatibility with existing, widely-deployed protocolsThere is a widely-deployed protocol for encrypted file sharing known as "OMEMO media sharing" or "aesgcm-links" that was never accepted as a XEP. While backwards compatibility with such non-standard is not a maxime of the XSF, it was still considered during the design of this protocol.
    • +
+ + +

+ 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;. +

+ + + + image/jpeg + summit.jpg + 3032449 + 4096x2160 + 2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU= + 2AfMGH8O7UNPTvUVAM9aK13mpCY= + Photo from the summit. + + + + + SuRJ2agVm/pQbJQlPq/B23Xt1YOOJCcEGJA5HrcYOGQ= + T8RDMBaiqn6Ci4Nw + BgKI2gp2kNCRsARNvhFmw5kFf9BBo2pTbV2D8XHTMWI= + id4cnqqy9/ssfCkM4vYSkiXXrlE= + + + + + + + + + + +]]> + + +

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:

+ + + + + + + + + + + + + + + + + + + +
NamespaceTypeLength (bits)Parameters
urn:xmpp:ciphers:aes-128-gcm-nopadding:0AESKey: 128, IV: 96GCM/NoPadding
urn:xmpp:ciphers:aes-256-gcm-nopadding:0AESKey: 256, IV: 96GCM/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;).

+
    +
  • urn:xmpp:esfs:0
    • +
+ + + diff --git a/xep.ent b/xep.ent index 880e0048..2355dcda 100644 --- a/xep.ent +++ b/xep.ent @@ -1612,3 +1612,4 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates Pre-Authenticated In-Band Registration (XEP-0445) XEP-0445: Pre-Authenticated In-Band Registration <https://xmpp.org/extensions/xep-0445.html>." > File metadata element (XEP-0446) XEP-0446: File metadata element <https://xmpp.org/extensions/xep-0446.html>." > Stateless file sharing (XEP-0447) XEP-0447: Stateless file sharing <https://xmpp.org/extensions/xep-0447.html>." > +Encryption for stateless file sharing (XEP-0448) XEP-0448: Encryption for stateless file sharing <https://xmpp.org/extensions/xep-0448.html>." > From d777f0cc4ed29fa08251202176d6c68363690814 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 24 Nov 2020 18:55:03 +0100 Subject: [PATCH 8/8] Accept inbox/stickers.xml as XEP-0449 --- xep-0449.xml | 238 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 239 insertions(+) create mode 100644 xep-0449.xml diff --git a/xep-0449.xml b/xep-0449.xml new file mode 100644 index 00000000..5abdd51a --- /dev/null +++ b/xep-0449.xml @@ -0,0 +1,238 @@ + + +File metadata element (XEP-xxxx) XEP-xxxx: File metadata element <https://xmpp.org/extensions/inbox/file-metadata.html>." > + Stateless file sharing (XEP-xxxx) XEP-xxxx: Stateless file sharing <https://xmpp.org/extensions/inbox/sfs.html>." > + +%ents; + + + + +]> + + +
+ Stickers + This specification provides a protocol to send stickers and to create and share sticker packs. + &LEGALNOTICE; + 0449 + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + + + + stickers + &larma; + + 0.1.0 + 2020-11-24 + XEP Editor (jsc) + Accepted by vote of Council on 2020-11-18. + + + 0.0.1 + 2020-11-03 + lmw +

First draft.

 + +
+ +

StickersSticker (messaging) on Wikipedia <https://en.wikipedia.org/wiki/Sticker_(messaging)>. are images or short animations that often represent an emoticon or an action. They are increasingly used in private messaging in the last years, especially on mobile phone apps. Stickers can be more nuanced and expressive than emoticons. They can be used to convey emotions or tell stories in a fun and easy way.

+

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.

+ + +
    +
  • Do not require additional server components for easier deployment
    • +
  • Compatibility with non-graphical user interfaces (terminals, etc)
    • +
+ + +
+
Sticker
Emoticon-like picture
 +
Sticker pack
Collection of stickers, typically devoted to a specific theme or with all stickers created by the same author
 +
+ + + +

+ 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.

+
    +

  1. Processing <name/> and <summary/> elements:

    +
      +

    1. For each <name/> or <summary/> element:

      +
        +
      1. Encode the character data of element name (name or summary), xml:lang attribute value and content.
        2. +
      2. Append an octet of value &sepl4; to each resulting octet string.
        3. +
      3. Join the resulting octet strings together, in the order of element name, xml:lang attribute and content, resulting in a single octet string for the <name/> or <summary/> element.
        4. +
      4. Append an octet of value &sepl3;.
        5. +
      +
      2. +
    2. Join the resulting octet strings together, ordered from lesser to greater.
      3. +
    3. Append an octet of value &sepl1;.
      4. +
    +

    The result of this step is referenced as Meta string later.

    +
    2. +

  2. Processing <item/> elements:

    +
      +

    1. For each <item/> element:

      +
        +
      1. Encode the character data of <file/>'s <desc/> content.
        2. +
      2. Append an octet of value &sepl3; to the resulting octet string.
        3. +

      3. For each of <hash/> element in <file/>:

        +
          +
        1. Encode the character data of algo attribute and content.
          2. +
        2. Append an octet of value &sepl4; to the resulting octet strings.
          3. +
        3. Join the resulting octet strings together, in the order of algo attribute and content, resulting in a single octet string for the <hash/> element.
          4. +
        4. Append an octet of value &sepl3;.
          5. +
        +
        4. +
      4. Join the resulting octet strings together, in the order of <file/>'s <desc/> content first and then all <hash/> elements ordered from lesser to greater.
        5. +
      5. Append an octet of value &sepl2;.
        6. +
      +
      2. +
    2. Join the resulting octet strings together, ordered from lesser to greater.
      3. +
    3. Append an octet of value &sepl1;.
      4. +
    +

    The result of this step is referenced as Stickers string later.

    +
    3. +
  3. Join the Meta String and Stickers String together, in this order.
    4. +
  4. Hash the resulting string using the algorithm choosen for the sticker pack.
    5. +
+

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.

+ + + + + + + Marsey the Cat + Be cute or be cynical, this little kitten works both ways. + + + image/png + 👍 + 71045 + 512x512 + 0AdP8lJOWJrugSKOIAqfEKqFatIpG5JBCjjxY253ojQ= + + + + + +1 + + + + image/png + 😘 + 67016 + 512x512 + gw+6xdCgOcvCYSKuQNrXH33lV9NMzuDf/s0huByCDsY= + + + + + + + EpRv28DHHzFrE4zd+xaNpVb4jbu4s74XtioExNjQzZ0= + + + + + +]]> + + +

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.

+ + 😘 + + + + image/png + 😘 + 67016 + 512x512 + gw+6xdCgOcvCYSKuQNrXH33lV9NMzuDf/s0huByCDsY= + + + + + + +]]> + + +

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.

+ xmpp:romeo@montague.lit?pubsub;action=retrieve;node=urn:xmpp:stickers:0;item=EpRv28DHHzFrE4zd%2BxaNpVb4 + + + +

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;).

+
    +
  • urn:xmpp:stickers:0
    • +
+ + + diff --git a/xep.ent b/xep.ent index 2355dcda..e985cdb2 100644 --- a/xep.ent +++ b/xep.ent @@ -1613,3 +1613,4 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates File metadata element (XEP-0446) XEP-0446: File metadata element <https://xmpp.org/extensions/xep-0446.html>." > Stateless file sharing (XEP-0447) XEP-0447: Stateless file sharing <https://xmpp.org/extensions/xep-0447.html>." > Encryption for stateless file sharing (XEP-0448) XEP-0448: Encryption for stateless file sharing <https://xmpp.org/extensions/xep-0448.html>." > +Stickers (XEP-0449) XEP-0449: Stickers <https://xmpp.org/extensions/xep-0449.html>." >