Re: [Standards] Proposed XMPP Extension: Pubsub Signing: OpenPGP Profile

Heyho! Some more feedback: In "Signing a Pubsub Item With OpenPGP", you state that "Signing an item with OpenPGP requires to have XEP-0373: OpenPGP for XMPP implemented to handle keys, [...]". I would argue, that - although useful - XEP-0373 is not strictly required as certificate distributio

Re: [Standards] Proposed XMPP Extension: Pubsub Signing

Hey! Thank you Goffi for creating this proposal. Cross-reading it, some points come to mind: In the glossary under "signing profile" you write: "a specialisation of this specification for a specific cryptographic algorithm." I think instead of "cryptographic algorithm", a more generalized ter

Re: [Standards] OX questions/remarks

Hey! Am 27.08.22 um 17:25 schrieb Tim Henkes: Hi, I'm implementing OX and have a bunch of questions/remarks that I would like to hear the authors' (or really anybodies') perspectives on. In no particular order: 1. Section 8.1 tells me to be prepared to find multiple public keys in "[...]

Re: [Standards] OpenPGP for XMPP: HTTP-Upload and MUC

Hey, for encrypted HTTP Uploads I'd like to add the following: If you encrypt the file using standard OpenPGP by encrypting it to some public key(s) and upload it to the server, you cannot "reuse" the upload for additional contacts. What I mean by that is, that the set of recipients is fixed

[Standards] OX Meeting Minutes 26.03.2021

Below you can find the minutes of today's OX Specification Meeting. The time and date for the next meeting will be 28th of May 2021, again at 15:00 Berlin time. The venue will be announced prior to the next meeting here and on the wiki page. # OX Meeting - 26.03.2021 15:00 EST Minutes:     * PubS

Re: [Standards] OpenPGP for XMPP Meeting

Quick reminder about the meeting next Friday! We will meet at 15:00 CET at https://meet.jit.si/AdventurousOxenTrotStandardized Looking forward :) Am 11.03.21 um 11:33 schrieb Paul Schaub: Hey, I wanted to propose that we hold our first (of potentially many?) meetings regarding advancement

[Standards] XEP Wishlist: Encrypted Information Storage

Hey everyone! It would be nice to have a way for clients to store end-to-end encrypted information on the server (imagine Private XML Storage or private PubSub nodes, but encrypted). As I heard that there are efforts of specifying ways to store signed data, I thought storage of encrypted data wou

Re: [Standards] XMPP Office Hours

Hi Sam, that's a great initiative! I'll note it down in my calendar :) Paul Am 12.03.21 um 13:56 schrieb Sam Whited: > Hi all, > > Several places I've worked and a co-op I recently joined do weekly > "office hours" where anyone can sign up to do a short talk on a topic of > interest to them. I'd

[Standards] OpenPGP for XMPP Meeting

-0374:_OpenPGP_for_XMPP_Instant_Messaging [3]: https://wiki.xmpp.org/web/Tech_pages/OX Am 24.02.21 um 21:32 schrieb Paul Schaub: > Am 22. Februar 2021 20:03:21 MEZ schrieb Florian Schmaus > : >> I would be more than happy to participate. >> >> - Florian > > Am 22.02.21 um 20:17 schrieb Thil

Re: [Standards] Syncing multi-device on XEP-0384: OMEMO

I wouldn't be too concerned about periods where the root chain is not advanced. The crypto should still be strong enough to protect the message contents against offline attacks. Take for example OpenPGP with keys over curve25519. There *every* message is encrypted with the same key, yet it is n

Re: [Standards] Year of the OX

Am 22. Februar 2021 20:03:21 MEZ schrieb Florian Schmaus : I would be more than happy to participate. - Florian Am 22.02.21 um 20:17 schrieb Thilo Molitor: I think monal will be part of this, too That's great news! Let's find possible options for a regular meeting then! I'd propose we meet

Re: [Standards] Syncing multi-device on XEP-0384: OMEMO

Hi Paul! You raise some valid points. Am 24.02.21 um 01:37 schrieb Paul L'Allier: *General message sending / carbon copy mechanism, including offline sending.* Consider that Alice and Bob each have two devices (say a desktop and a mobile, some of which may be offline at any given time). Th

[Standards] Year of the OX

Hey everyone! Tomorrow will be new years eve in the Chinese calendar. The Berlin XMPP Meetup celebrated the beginning of the "year of the ox" by talking about OX (XEP-0373.5±0.5 - OpenPGP for XMPP). With around 30 attendants the Jitsi room was quite crowded and there were a lot of interesting dis

Re: [Standards] NEW: XEP-0452 (MUC Mention Notifications)

Its meant to link to https://xmpp.org/extensions/xep-0297.html instead. Am 27.01.21 um 13:27 schrieb Ivan Vučica: > The mention of “Server IP Check” XEP-0279 seems to be a typo? > > On Tue 26 Jan 2021 at 16:04, Jonas Schäfer > wrote: > > Version 0.1.0 of XEP-0452 (

Re: [Standards] On Stanza/Element signing

14.09.20 um 12:30 schrieb Dave Cridland: >> >> >> On Sat, 12 Sep 2020 at 12:36, Paul Schaub > <mailto:vanitasvi...@fsfe.org>> wrote: >> >> Hi List, >> >> I see there have been past activities around creating >> signatu

Re: [Standards] On Stanza/Element signing

l Am 14.09.20 um 12:30 schrieb Dave Cridland: > > > On Sat, 12 Sep 2020 at 12:36, Paul Schaub <mailto:vanitasvi...@fsfe.org>> wrote: > > Hi List, > > I see there have been past activities around creating signatures for > stanzas/elements. > > Ther

[Standards] On Stanza/Element signing

Hi List, I see there have been past activities around creating signatures for stanzas/elements. There are two deferred, competing proposals (XEP-0274: Design Considerations for Digital Signatures in XMPP ([1]) & XEP-0285: Encapsulating Digital Signatures in XMPP ([2])). Winfried Tilanus very rec

Re: [Standards] Feedback on XEP-0420: Stanza Content Encryption (SCE)

Oh and PRs on the XEP are always welcome as well :P Am 01.09.20 um 18:00 schrieb Linus Jahn: > On Tue, 1 Sep 2020 17:05:23 +0200 > Paul Schaub wrote: > >> Hi Linus, >> >> thank you for your feedback! >> >> Am 01.09.20 um 16:25 schrieb Linus Jahn: >&

Re: [Standards] Feedback on XEP-0420: Stanza Content Encryption (SCE)

Am 01.09.20 um 18:00 schrieb Linus Jahn: > I'd say, an exception for fallback bodies is worth thinking about. > I agree on that and I think ideally SCE should have a note about EME and > recommend it. I'll put that on my ToDo list. Thanks again for pointing out those things and for implementing S

Re: [Standards] Feedback on XEP-0420: Stanza Content Encryption (SCE)

Hi Linus, thank you for your feedback! Am 01.09.20 um 16:25 schrieb Linus Jahn: > 1. The XEP suggests that each encryption method uses a tag with > xmlns=''. However, since the element is not > defined > by SCE, there's no way of recognising a stanza as encrypted using SCE. I could > only sear

Re: [Standards] XEP-0396 (jet-omemo) links to a broken URL

Hi Ivan, I guess you can ignore that. The registry link was inserted by accident. Thanks for reporting this :) Paul 26.08.2020 22:36:55 Ivan Vučica : > Hi, > > https://xmpp.org/extensions/xep-0396.html links to > https://xmpp.org/registrar/jet-omemo.html which doesn't exist. > > Was this mean

Re: [Standards] Query types in PubSub

Am 14.08.20 um 14:17 schrieb Paul Schaub: > Also it is not entirely clear to my, why for URIs that cause some action > the URI contains 'pubsub' after the question mark, but for simply > addressing an item, 'pubsub' can be omitted. I already looked into > htt

Re: [Standards] Query types in PubSub

of an XMPP URI, but I can't see why 'pubsub' is sometimes placed as iquerytype and not in other cases. Can someone explain / link me to further resources? Am 14.08.20 um 13:55 schrieb Paul Schaub: > Hi list! > > I'm currently looking into pubsub URIs as specifi

[Standards] Query types in PubSub

Hi list! I'm currently looking into pubsub URIs as specified in https://xmpp.org/extensions/xep-0060.html#registrar-querytypes What I noticed is that the linked section mentions that the registrar maintains a list of pubsub-related query types which are listed here: https://xmpp.org/registrar/que

[Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)

My two cents on this: I'm neither involved with the editors team nor am I a huge CI expert. All I can say is that if the editors team benefits from a switch then I'm all for it. I also like the move from the perspective of decentralization, even if we "just" move from the biggest provider to pro

Re: [Standards] Council Minutes 2020-05-27

01.06.2020 13:31:39 Andrew Nenakhov : > yeah, and we've strengthened our resolve to work on our (yet another) > reference-based markup extension, because it is very consistent, works > great with group chats, makes it easy to process markup, mentions, > filter attached media, stickers, etc.  ¯\_(ツ)

Re: [Standards] Review of XEP-0384: OMEMO Encryption

Hi Sofía! Sorry for the late reply, your mail was not forgotten :) Thank you very much for the valuable feedback, we'll strive to incorporate it in the next version of the XEP! 12.05.2020 01:22:16 Sofía Celi : > > The notion of: > > - "Perfect forward secrecy: Compromised key material does not c

Re: [Standards] MIX Join: JID or ID?

and what you would like me to sort > > > Regards > > > Steve > > > >> -Original Message- >> From: Standards On Behalf Of Paul Schaub >> Sent: 28 February 2020 13:02 >> To: standards@xmpp.org >> Subject: [Standards] MIX Join: JID or ID? >> >>

Re: [Standards] MIX Join: JID or ID?

/xeps/pull/919 that changes the examples of MIX-PAM accordingly. Happy Hacking! On 28.02.20 16:58, Andrzej Wojcik wrote: > Hi, > >> Wiadomość napisana przez Paul Schaub > <mailto:vanitasvi...@fsfe.org>> w dniu 28.02.2020, o godz. 14:01: >> >> Hi List! >>

[Standards] MIX Join: JID or ID?

Hi List! XEP-0369 (MIX-Core) section 7.1.2 about joining a channel states that when the users server sends a join request to the mix channel, the channel responds with an IQ of type result. Further it states: "This stanza includes the nodes to which the user has been successfully subscribed, as w

Re: [Standards] XEP-0313 for transports

> (Also, random thought: seeing XEP-0313 lapse into 'Deferred' is concerning...) The deferred state doesn't really have any meaning, only that there was no input on the XEP for over a year. Paul 26.02.2020 16:41:06 Ivan Vučica : > Hi, > > Sometimes, protocols backing transports may support q

Re: [Standards] Proposed XMPP Extension: Trust Messages

Hi list! Let me give some feedback to the Trust Messages ProtoXEP. I'm not sure how well this specification performs against replay attacks. If some encryption mechanism which prevents re-decryption of old messages like OMEMO is used to encrypt the messages, than replay attacks are probably not a

Re: [Standards] Proposed XMPP Extension: Simple JSON Messaging

If they wanted to send objects via XMPP, they could simply serialize their data to XML. I can see a use case for this XEP for people that just "want to get the job done". IMHO it makes no sense to convert JSON to XML and back simply so that it pleases someone who is looking on what's send ov

Re: [Standards] OMEMO:2 Spec Sprint

gt; Will there be a possibility to attend remotely? > > Thanks so much! > > On 2/17/20 10:51 AM, Paul Schaub wrote: > > > Friendly reminder to add yourself to the wiki page if you plan to > > attend the Spec Sprint. There are only 2 entries at the mome

Re: [Standards] OMEMO:2 Spec Sprint

Friendly reminder to add yourself to the wiki page if you plan to attend the Spec Sprint. There are only 2 entries at the moment. https://wiki.xmpp.org/web/Sprints/2020_March_Duesseldorf Happy Hacking Paul On 06.02.20 13:46, Paul Schaub wrote: > Hello everyone! > > I'm pleased to

Re: [Standards] OMEMO 2 or MLS?

Hi Winfried! I agree with all the points you bring up, however I also don't see any reason why MLS and OMEMO 2 shouldn't coexist. OMEMO 2 aims at fixing all those little issues that currently exist in the OMEMO ecosystem. Personally I'd see it as an "upgrade" to the current OMEMO specification.

Re: [Standards] OMEMO:2 Spec Sprint

rints/2020_March_Duesseldorf If you plan to attend, please add your name to the list of participants in the wiki! Please note, that in-depth knowledge of the OMEMO protocol and/or implementation experience is expected/desired. Happy Hacking! Am 13.01.20 um 14:06 schrieb Paul Schaub: > Hi

Re: [Standards] NEW: XEP-0425 (Message Moderation)

On 24.01.20 15:31, JC Brand wrote: > Yes, I considered the "reason" element to be optional Thanks for the clarification :) Another point that I stumbled across while working on an implementation is that §3 states: > The groupchat service will append a Unique and Stable Stanza IDs (XEP-0359)

Re: [Standards] NEW: XEP-0425 (Message Moderation)

Hi everyone! I have a question regarding the element. Is the text content inside the reason element mandatory? If so, what should be a default reason text. If not, is is okay to leave the element empty, like or or should the element be omitted in such case? Paul On 01.11.19 11:41, li...@opkod

Re: [Standards] OMEMO:2 Spec Sprint

erver-xmpp On Mon, Jan 13, 2020 at 5:08 AM Paul Schaub <mailto:vanitasvi...@fsfe.org>> wrote: Hi everyone! With the current discussions and plans around XEP-0384 being retired soon, some of us found it important to come up with a properly specified replacement in ti

[Standards] OMEMO:2 Spec Sprint

Hi everyone! With the current discussions and plans around XEP-0384 being retired soon, some of us found it important to come up with a properly specified replacement in time. That's why there will be an OMEMO:2 Specification Sprint! \o/ We are going to learn from the mistakes of the old spe

Re: [Standards] XEP-0384: Rejecting? [Was: Re: Proposed XMPP Extension: Ephemeral Messages]

02.01.2020 17:39:38 Philipp Hörist : > Hi, > What I talked about when i said it's impossible is not about the Crypto. It's > the wire format that is not documented to my knowledge. And without that you > can't make OMEMO work. The wireformat can only be looked up in the source > code. If you w

[Standards] SIG-E2EE

Hello everyone! During the 36C3 a bunch of people finalized the idea to form a SIG dedicated to end-to-end encryption. The desired outcome of the SIG would be to facilitate development on E2EE related technology within the XSF. Concrete goals include, but are not limited to: * Work on specifying

Re: [Standards] Proposed XMPP Extension: Ephemeral Messages

That is true. The related part of the double ratchet spec is https://signal.org/docs/specifications/doubleratchet/#out-of-order-messages Paul 28.12.2019 18:11:18 Philipp Hörist : > Hi, > > > 4.5 Exchanging Ephemeral OMEMO Messages > > OMEMO requires that messages are delivered in a sequence.

Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)

Hi! I'm not quite happy with the fact that an advanced mobile client must support push. While I understand the rationale behind this (*cough* iOS *cough*), I dislike the fact that in order to be considered an advanced client, the client MUST depend on a centralized push service (for example G

Re: [Standards] XEP-0084: User Avatar - Invalid example?

to a HTTP service, right? On 31.08.19 15:30, Paul Schaub wrote: > Hello everyone! > > XEP-0084 Example 4 shows a Metadata publication which does contain a > single info element which has type image/gif. However section §4.2.1 > states in the last paragraph: > >> The

[Standards] XEP-0084: User Avatar - Invalid example?

Hello everyone! XEP-0084 Example 4 shows a Metadata publication which does contain a single info element which has type image/gif. However section §4.2.1 states in the last paragraph: > The root element MAY contain more than one element. Each element MUST specify metadata for the same avatar i

[Standards] Byte count of XEP-0084: User Avatar image data

Hi Standardists! I noticed, that XEP-0084 was update in version 1.1.2 to allow image "height"s and "width"s up to 65536 (previously 256). While I agree, that this is a sensible up to date range for width and height, I think that the range of the size attribute (bytes) would need to be updated as w

Re: [Standards] XEP-0392 (Consistent Color Generation): Include HSLuv conversion formula

Hi Jonas! Am 11. Juli 2019 20:19:06 MESZ schrieb "Jonas Schäfer" : >This describes how HSLuv (which is distinct from HSL, so your >difference in >results is easily explained) works, and also lists implementations. Thanks for the clarification! That HSL is not HSLuv explains a lot :D >It is by

Re: [Standards] XEP-0392 (Consistent Color Generation): Include HSLuv conversion formula

PS: Note, that it is perfectly possible, that I just made a mistake in my implementation and that the formulas from wikipedia and the cited page are perfectly fine :D On 10.07.19 23:10, Paul Schaub wrote: > Hi everyone! > > I recently updated my implementation of XEP-0392 to version 0.

[Standards] XEP-0392 (Consistent Color Generation): Include HSLuv conversion formula

Hi everyone! I recently updated my implementation of XEP-0392 to version 0.6.0 and I ended up having to include a third party library to get my implementation to match the provided test vectors. The XEP states: "Use the HSLuv operation hsluvToRgb to convert the Hue angle to a color." Searching f

Re: [Standards] Proposed XMPP Extension: Stanza Content Encryption

Am 24.06.19 um 18:58 schrieb Georg Lukas: > > 2. In an encryption protocol idea that I briefly entertained, I was > pondering about actually embedding a regular XMPP stanza > inside the encrypted container, with the from and to addresses being > bare JIDs of the respective parties. This _might_ m

Re: [Standards] Proposed XMPP Extension: Stanza Content Encryption

Am 24.06.19 um 19:04 schrieb Ненахов Андрей: > пн, 24 июн. 2019 г. в 21:59, Georg Lukas : >> 1. I'd like to see certain fields of the being REQUIRED, >> especially: >> >> - the from address > So much for deniability. > Yeah, I'd rather keep it flexible and let the encryption XEP which defines a S

Re: [Standards] XMPP Compliance Badges, prototype feedback requested.

I like the opensourcedesign ones best, but I can also imagine one of the other two being used as git-repo badges, as those blend in well with existing git badges, while the opensourcedesign badges seem to better fit other places like websites. Paul Am 20. Juni 2019 22:47:50 MESZ schrieb "Nicol

Re: [Standards] Stanza Content Encryption

Oh and I forgot: OpenPGP kind of solves the issue as it allows to bind encryption preferences to the key itself[1]. This may be worth taken into consideration. Paul [1]: https://tools.ietf.org/html/rfc4880#section-5.2.3.7 On 20.06.19 13:17, Paul Schaub wrote: > Hi Philipp, Kim and I

Re: [Standards] Stanza Content Encryption

cated. You have to think about multiple resources online which would > support different kind of features, and other resources offline where you > dont even know the features, this is a nightmare i would not even start to > implement. > > Regards > Philipp > > >

Re: [Standards] Stanza Content Encryption

Hi Florian! Am 17.06.19 um 17:58 schrieb Florian Schmaus: > On 15.05.19 16:53, Paul Schaub wrote: >> Thank you very much for your eager interest and numerous replies >> *cough*, in other words, Thank you Florian for your reply :D >> >> I'm not quite sure, how ex

Re: [Standards] Stanza Content Encryption

Hi Dave! On 15.05.19 18:15, Dave Cridland wrote: > Standard response: > > The process for XEPs in the XSF starts with the ProtoXEP submission - that > part is to decide if the XSF should take on the work. > > If the XSF does, it takes copyright of the XEP, and works on the contents. > > We do n

Re: [Standards] Stanza Content Encryption

Thank you very much for your eager interest and numerous replies *cough*, in other words, Thank you Florian for your reply :D I'm not quite sure, how exactly the process of negotiating expected encrypted elements would look like. Do you think this may be done via or similar to Entity Capabilities

[Standards] Stanza Content Encryption

Hello List! Some of you may remember, that I tried to spark a discussion about "Partial Stanza Encryption" at the summit earlier this year. Unfortunately I couldn't remember all your feedback from back then, so I started another discussion at the most recent Sprint in Berlin and gathered some more

Re: [Standards] Council Voting Summary 2019-03-31

That's what I was going to say. There is no new crypto, and no cross signing, just exchanging fingerprints over an already secured channel. If that would be considered inventing you own crypto, we wouldn't be exchanging any encrypted messages at all. Am 3. April 2019 18:12:47 MESZ schrieb "W. M

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

Thats more a general OMEMO critic that has nothing to do with ATT, right? Am 3. April 2019 17:25:23 MESZ schrieb "Ненахов Андрей" : >What I don't get about this Trust Transfer thing is that it is kinda >defeating the purpose of OTR-like encryption. If you are really that >paranoid that you want/n

Re: [Standards] Stanza Content Encryption

Sure, the chat in that room so far was mainly about the room itself anyways :D Am 2. April 2019 17:30:58 MESZ schrieb "Jonas Schäfer" : >On Montag, 1. April 2019 10:13:27 CEST Paul Schaub wrote: >> xmpp:s...@conference.jabberhead.tk?join > >Can we please move the di

Re: [Standards] Stanza Content Encryption

also includes MLS. Still there is no reason to explicitly mention it :) Am 1. April 2019 11:24:49 MESZ schrieb Evgeny : >On Mon, Apr 1, 2019 at 11:13 AM, Paul Schaub >wrote: >> There was a ton of >> interesting discussions around OMEMO and other stuff, as well as some >>

[Standards] Stanza Content Encryption

Hi everyone! The Sprint in Berlin was great and it was huge fun meeting so many developers (and users as well!) in person. There was a ton of interesting discussions around OMEMO and other stuff, as well as some productive coding (and Mate!). I took the opportunity to once again start a discussio

Re: [Standards] XEP-0384: encrypt stanzas

Currently OMEMO only supports encryption of the body of a message. However, XEP-0373 (OpenPGP for XMPP), which I recently implemented for Smack does support encrypting arbitrary ExtensionElements and I made very positive experience with it. Technically extension encryption is done more or less as

[Standards] XEP-0384: Staleness of devices

Hi everyone! As some of you might know, the OMEMO protocol audit[1] from 2016 contained a notice, that stale devices might lead to loss of forward secrecy. However, the XEP[2] has not yet been updated accordingly. Stale devices are harmful for forward secrecy, as a device that only receives messa

Re: [Standards] message encryption session at IETF 102

Thank you! I'll see, if I can manage to follow the discussions :) On 18.07.2018 16:54, Peter Saint-Andre wrote: > Hi folks, the first meeting of the Messaging Layer Security working > group will be held tomorrow at IETF 102 from 09:30 to 12:00 EDT (i.e., > starting at 13:30 UTC): > > https://dat

Re: [Standards] File sharing states for XEP-0085: Chat State Notifications

Am 17.07.2018 um 15:36 schrieb Jonas Wielicki: > I’m not sure what the use-case for this would be in general. Telegram for example displays "User is recording a voice message". ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/sta

[Standards] Disco#info queries on strangers PubSub nodes with access model 'open'

Hi! During the work on my GSoC project I stumbled across an issue with PubSub and Service Discovery. My server announces support for the PubSub access model 'open'. Configuring a PubSub node with this access model, I expect users who are not in my contact list to be able to fetch the contents of

Re: [Standards] Disappearing timers for OMEMO proposal

Hi! I get what you want to achieve, but I think it would be easier to define disappearing messages for general XMPP (not only OMEMO). As already stated, you cannot trust devices that announce support, to actually delete messages after the timer expired. Lets assume you do trust all involved devic

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

Am 07.03.2018 um 19:18 schrieb Jonas Wielicki: > I started to work on > [XEP-0394] (Message Markup) which intends to do a bit more, with a more > flexible approach. Note that I intend to overhaul XEP-0394 and I don’t know > of > any implementations. FYI: I implemented it for Smack :) https://

Re: [Standards] XEP-0392: Consisten Colors - Error in Test Vectors?

le-view-default >   > Test Vectors: > https://bitbucket.org/sco0ter/babbler/src/1cddf27f01fb464628e71559912b09de9457/xmpp-extensions/src/test/java/rocks/xmpp/extensions/colors/ColorGenerationTest.java?at=xep0392&fileviewer=file-view-default >   > Kind regards, > -- Christian >   >

[Standards] XEP-0392: Consisten Colors - Error in Test Vectors?

Hi! I'm currently implementing XEP-0392 and I'm unable to reproduce the values from the test vectors. More specifically, all my values are more or less correct (very small rounding errors), apart from the B value. I noticed that the B value in the test vectors is always suspiciously even (1.00 or

Re: [Standards] XEP-0385: Stateless Inline Media Sharing (SIMS): Dependency on XEP-0372: References

Hi! Am 02.02.2018 um 19:00 schrieb Paul Schaub: > Hi! > > I noticed, that the SIMS XEP is not linking/depending on References, > even though the examples all contain reference elements. I assume this > was just forgotten? > Also almost all examples in the SIMS XEP are lacking

[Standards] [XEP-0391] JET error conditions

Hi! I'm currently thinking about errors that might occur when initializing an encrypted Jingle session. Most prominent when the decryption of the Transport Key fails for some reason (eg. corrupted OMEMO session, missing trust decision, wrong PGP key etc.). Jingle (XEP-0166) defines a security-err

Re: [Standards] JET-OMEMO Encrypted Jingle Transports

Good evening! I used your recent feedback to work on JET-OMEMO. The rendered result can be found here: http://geekplace.eu/xeps/xep-jet-omemo/xep-jet-omemo.html By limiting usable ciphers for JET-OMEMO to only aes-128-gcm-nopadding, I was able to reuse OMEMOs KeyTransportElement in the way it was

[Standards] JET-OMEMO Encrypted Jingle Transports

Hello everyone! I'm currently working on JET-OMEMO, which will hopefully specify how to use OMEMO with JET to encrypt Jingle Transports. One thing I'm not sure about is, whats the best way to encrypt the Transport Key. Initially I planned to treat the key as a message body. The resulting element

Re: [Standards] XEP-0384 OMEMO questions

Hi! Am 18.09.2017 um 15:27 schrieb Klaus Herberth: > > Hi Paul, > > thanks for reading that lengthy email. > > If I understand you correctly, the complete magic happens in the key > element and there is no description in the XEP or in the linked > "signal protocol" which describes it. So all impl

Re: [Standards] XEP-0384 OMEMO questions

Hi! Am 18.09.2017 um 13:07 schrieb Klaus Herberth: > > I am trying to create an MIT licensed OMEMO library written in > Typescript and while reading the protocol some questions came up. > Nice! OMEMO lacks permissive implementations. > - Version 0.2 uses the signal protocol now (sec 1.1), but as

Re: [Standards] Proposed XMPP Extension: Jingle Encrypted Transports

Heyho! I just created a PR that addresses some of your feedback. A rendered version can be found here: https://geekplace.eu/xeps/xep-jet/xep-jet.html Looking forward to your feedback :) Greetings vv signature.asc Description: OpenPGP digital signature _

Re: [Standards] Experimental vs. Draft vs. ProtoXEP states

Here is a link to the rendered version: https://geekplace.eu/xeps/xep-jet/xep-jet.html Greetings vv Am 06.09.2017 um 18:46 schrieb Paul Schaub: > > Hello everyone! > > To get back to topic: I made some changes based on your feedback. > Basically my plan is to split JET up into

Re: [Standards] Experimental vs. Draft vs. ProtoXEP states

Hello everyone! To get back to topic: I made some changes based on your feedback. Basically my plan is to split JET up into a main XEP and some subprotocols. As Daniel suggested, JET will only contain reusable stuff and has no more mentions of OMEMO and OX. Instead I used "stub" encryption method

Re: [Standards] Proposed XMPP Extension: Jingle Encrypted Transports

Hello everybody! I'm very glad to see some discussion on my proposal :) > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. First things first: My intention for submitting JET to the XSF inbox was to get some comments and first feedback in order

[Standards] XEP-0234: Missing error condition for checksum mismatch

Hi! Currently XEP-0234 does not specify, how to react when the checksum of the received file does not match the announced checksum. Can anybody who implemented the XEP give me a hint what the correct way to react is? Also: Wouldn't it make sense to specify an error reason for this case? Greetin

Re: [Standards] XEP-0234: Denote used hash function in session-initiate

16:08 schrieb Sam Whited: > On Thu, Aug 17, 2017, at 15:23, Paul Schaub wrote: >> I propose the following change: The session-initiate MUST contain a >> reference to the hash algorithm used to calculate the checksum. The >> actual hash-value can still be send afterwards, but now the

[Standards] XEP-0234: Denote used hash function in session-initiate

Hi! I stumbled across another inconvenience in the Jingle File Transfer XEP: The session-initiate MIGHT contain a hash-element which contains the checksum of the file. Alternatively the hash-element can also be sent at a later point to prevent the sender from having to read the file multiple time

Re: [Standards] XEP-0234: Add option to request hash of offered file.

Hi! Am 15.08.2017 um 19:59 schrieb Sam Whited: > On Tue, Aug 15, 2017, at 11:14, Paul Schaub wrote: >> Do you think it might be a good idea to add a session-info element which >> can be used to specifically request the checksum of a file? > My guess is that the reasoning for all

[Standards] XEP-0234: Add option to request hash of offered file.

Hi! While I played around with XMPP to create a file sync application for demonstration purposes (for GSoC) [1,2], I figured that it would be nice to have a way to explicitly request the hash of an offered file. XEP-0234 states, that the checksum of a file MIGHT be sent inside the session-initiat

Re: [Standards] [XEP-0234] Wrong date format in Jingle File Transfer

Am 07.08.2017 um 18:05 schrieb Emmanuel Gil Peyrot: > Hi, > > On Mon, Aug 07, 2017 at 12:19:12PM +0200, Paul Schaub wrote: >> I see, that in some spots the wrong format has already been fixed. I'll >> create a PR fixing the remaining occurences :) > I already proposed

Re: [Standards] [XEP-0234] Wrong date format in Jingle File Transfer

I see, that in some spots the wrong format has already been fixed. I'll create a PR fixing the remaining occurences :) Am 07.08.2017 um 12:08 schrieb Paul Schaub: > Hi! > > XEP-0234 §5 states, that the last-changed-date of a file must be given > in a UTC timestamp which MU

[Standards] [XEP-0234] Wrong date format in Jingle File Transfer

Hi! XEP-0234 §5 states, that the last-changed-date of a file must be given in a UTC timestamp which MUST conform to the DateTime profile from XEP-0082. However, afaict it doesn't. XEP-0082 defines the DateTime profile as "CCYY-MM-DDThh:mm:ss[.sss]TZD", where TZD is '(either "Z" for UTC or "(+|-)h

[Standards] [XEP-0260]: Redundant DstAddr?

Hi! I have a question regarding XEP-0260 (Jingle Socks5Bytestream Transports); §2.2 states that a DstAddr attribute should be included, when the initiator offers at least one proxy candidate. Since the DstAddr is calculated as SHA1(SID + Initiator JID + Responder JID) and both initiator and resp

Re: [Standards] Jingle (XEP-0166): Multiple contents in transport-info message?

l contents. A -> content-add [content 1, content 2] -> B A <- ack <- B A <- content-accept [content 1] <- B A -> ack -> B The first option would probably be preferable, since details (like reasons) can be sent to the peer. I'm not sure though, if there are other obst

Re: [Standards] Jingle (XEP-0166): Missing unsupported-security action

Hi! Am 28.07.2017 um 03:33 schrieb Peter Saint-Andre: > On 7/27/17 3:41 PM, Paul Schaub wrote: >> Hi! >> >> Jingle defines the reasons "unsupported-transports" and >> "unsupported-application" that are used to signal, that one client does >>

[Standards] Jingle (XEP-0166): Missing unsupported-security action

Hi! Jingle defines the reasons "unsupported-transports" and "unsupported-application" that are used to signal, that one client does not support any of the offered description types or transport methods (XEP-0166 Examples 23-26). First of all I'd propose to rename "unsupported-application" and "fa

[Standards] Jingle XEPs: Use of session-info vs. description-info

Hi! Many Jingle related XEPs use the session-info action to indicate certain events (like successful file transfers, ringing for RTP sessions etc). Also there exists the description-info action, which (as I found) is rarely used at all. As far as I understood the session ist description-agnostic

Re: [Standards] Jingle (XEP-0166): Multiple contents in transport-info message?

contains both legal and illegal actions (eg. tie-breaking actions)? Some input on this would be much appreciated :) vv Am 18.07.2017 um 23:31 schrieb Paul Schaub: > Hi! > > I have a quick question: Is it possible to have multiple contents in a > jingle element with the "trans

[Standards] Jingle (XEP-0166): Multiple contents in transport-info message?

Hi! I have a quick question: Is it possible to have multiple contents in a jingle element with the "transport-info" action? I can imagine this might be used to bundle multiple transport-info requests of different contents together, but I'm not sure about that. I haven't found anything in the XEP

[Standards] Jingle File Transfer (XEP-0234) uses NonNegativeInteger instead of UnsignedLong.

This is a very minor issue, but XEP-0234 uses positiveInteger as attribute type for the FileTransferElementType's size attribute. positiveInteger contains all positive numbers except '0', which requires implementers to choose eg. the BigInteger class to represent that value. I think unsignedLong

  1   2   >