[Standards] Proposed XMPP Extension: Stanza Content Encryption
philipp at hoerist.com
Mon Jun 24 21:55:56 UTC 2019
I think it would be good to concentrate on the task that this XEP wants to
solve (its hard enough), and not invent new ones.
- No this XEP should not invent a new 0030
- No this XEP should not improve/destroy current crypto mechanics by adding
various information's into the payload. If you feel this is necessary
update the corresponding crypto XEP.
This XEP should be a simple standard that tells developers what content to
expect when decrypting a full stanza payload, and what to put into when
encrypting. Nothing more.
Am Mo., 24. Juni 2019 um 23:38 Uhr schrieb Maxime Buquet <pep at bouah.net>:
> On 2019/06/24, Dave Cridland wrote:
> > On Mon, 24 Jun 2019 at 20:11, Paul Schaub <vanitasvitae at fsfe.org> wrote:
> > > Am 24.06.19 um 19:04 schrieb Ненахов Андрей:
> > > > So much for deniability.
> > >
> > > Yeah, I'd rather keep it flexible and let the encryption XEP which
> > > defines a SCE profile decide, which fields to use and not to use. OX
> > > instance should probably use the "full stack" of affix elements, while
> > > OTR would stay away from most of them (except maybe timestamp).
> > >
> > I would rather everything used the same.
> I think the point of this XEP is to enforce only meaning of elements it
> provides for other XEPs to use.
> As Paul said, I also think profiles of this XEP (other XEPs reusing SCE)
> should define how these elements are used. Somebody might come up with
> an encryption mechanism that doesn't fit our model of REQUIRED elements.
> Maxime “pep” Buquet
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards