[Standards] Stanza Content Encryption

Florian Schmaus flo at geekplace.eu
Mon Jun 24 19:04:53 UTC 2019


On 18.06.19 11:03, Philipp Hörist wrote:
> Hi,
> 
> Im not quite sure what you want to negotiate,

Roughly speaking which secured, i.e. encrypted and/or signed, extension
elements an entity is going to send to another entity. We may not have
to negotiate it for all extension elements, but probably for some.

> but making any part of the
> encryption process depending on disco info of a online resource is a fail.

Potentially true. Zash already said that "we might have to re-think how
XEP-0030 should work in this new world.", and I believe that we should
do so. We probably need a public PEP node with "user-declared" features
for that (or should the features be announced on bare JID as disco#info
result?).

> Feature negotiation in encryption process is a fail in General. Its
> simply not needed, we have 2 encryption methods right now (OMEMO and
> PGP) that dont depend on any kind of negotiation and this works fine.

I do not think that both of those statements are true. It does not work
fine, I receive OMEMO encrypted messages on my non-OMEMO enabled client
all the time. Sure, one can argue that this is by-design and/or somehow
desired behaviour. But maybe we can do better. Also both use some kind
of negotiation, otherwise how do you know that you can send a secured
message using the particular mechanism to the recipient?

> One of them even having full stanza encryption.
> 
> The whole encryption process must be possible while the recipient is
> offline, for the whole process. Feature negotiations also imply that
> there are multiple features to handle differently which makes
> implementation more complicated. 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.

I'd love to avoid complexity when it is possible. But this requires
implementation experience first and then a round of feedback.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190624/96cbfb8f/attachment.sig>


More information about the Standards mailing list