[Standards] Stanza Content Encryption

Maxime Buquet pep at bouah.net
Mon Jun 24 21:50:38 UTC 2019

On 2019/06/24, Florian Schmaus wrote:
> 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?

> I receive OMEMO encrypted messages on my non-OMEMO enabled client
> all the time.

I assume this is very much a feature indeed.

You probably wouldn't like your client to send your message encryption
to one device, and plain to another.

You also wouldn't like your client to prevent you from sending a message
at all I guess?

And as the receiver I that I have received a message, even if my client
doesn't support it (and this is not the only reason we tend to remove
resource-locking nowadays anyway)

As Zash said it's pretty much impossible to know where your message will
arrive with carbons and MAM.

The current way of doing opportunistic encryption seems fine to me: if
you can find keys, then it means at least a device has published them
and thus supports the encryption mechanism.

This discovery mechanism can be defined on SCE profiles. I don't think
SCE should worry about this.

Maxime “pep” Buquet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190624/cc623ca9/attachment.sig>

More information about the Standards mailing list