Hi,
Dave, thanks for explaining why we have traditionally accepted specifications early. The IPR angle might not necessarily be compelling for some, but we have had issues around this before. Other organizations have similar policies, and IETF even has stronger ones, which include all discussion on lists. So although authors or others might feel a proposal is not fully baked, we do prefer this. Having multiple (partially) competing specifications in Experimental stage is a good thing. Retracting after solid discussion is much easier. Also note that the discussion on having a phase before experimental has come up before. Instead, we recently made some small adjustments to accommodate for this with the current stages. Adding another stage would just shift labels. I do agree that we should probably move a bunch of existing drafts forward. -- ralphm ________________________________ From: Dave Cridland <d...@cridland.net> Sent: Wednesday, May 15, 2019 18:15 To: XMPP Standards Subject: Re: [Standards] Stanza Content Encryption > 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 not have any IPR cover for something before this point, so I'm not > particularly motivated toward reading and commenting on unsubmitted XEPs, > sorry. Please do not try and change the process we have by adding a "pre > submission" stage to it - we really don't need an additional stage (and if > you think we do for some reason, we're probably doing something wrong to make > you think that way). > > More useful response: > > All I'd need to accept a full-stanza encryption XEP is: > a) A way to know if the encrypted contents are a full stanza or just body. > b) A way to know which elements in the encrypted contents override those in > the traditional payload. > c) A way to know what encryption has been used. > > A challenge for (b) is that you don't always know what metadata elements > might be added by a server on the way through, and some metadata elements you > might include in the original (now encrypted) message may need to be both > duplicated on the outer wrapper and changed en-route. > > An example is security labels, which need to be translated through different > policies. > > As such, I'm not too worried if the (b) answer is quite a lot of hand-waving > for now. > > I think (a) and (c) are trivial, though. If your proposal covers those, just > submit it. > > On Wed, 15 May 2019 at 15:54, Paul Schaub <vanitasvi...@fsfe.org> 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 exactly the process of negotiating expected >> encrypted elements would look like. Do you think this may be done via or >> similar to Entity Capabilities (XEP-0115)? I can see that this would >> make it easier for adopters to gradually start implementing support for >> one feature at a time (like start with support for <body/> encryption >> and then successively add support for other elements as well), but at >> the same time I feel like this could enable "downgrade" attacks and >> would diminish the "encrypt *all* the sensitive things"-approach that I >> aim for. >> >> For now I'm trying to give useful sensible suggestions on what elements >> are allowed inside the envelopes content element. If later we learn that >> there are elements that are definitely not allowed at all, we might want >> to come up with some sort of incomplete list of forbidden elements. >> >> An alternative approach that some people suggested would be to replace >> the envelopes content element with a normal message stanza. That way >> implementations could simply decrypt that stanza, check it for forbidden >> elements and remove those and then feed the cleaned stanza back into the >> XML stream. That way the client wouldn't have to reimplement listeners >> for all the events. On the other hand, the client would probably want to >> somehow mark the decrypted stanza as end-to-end encrypted. >> >> What do you think of this approach? Is it better, worse than the current >> proposal? (reminder: http://geekplace.eu/xeps/xep-sce/xep-sce.html ) >> >> I hope that there will be some more feedback from participants of this >> list. I don't want to get the feedback only when the document lands in >> the inbox folder ;). >> If you think the idea behind the spec is a good idea - nice! If you >> think it is a bad idea - even better! But please let me know why and >> what you'd change. >> >> Happy Hacking! >> Paul >> _______________________________________________ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: standards-unsubscr...@xmpp.org >> _______________________________________________
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
