[Standards] XEP-0374: How to handle conflicting stanza elements?

Florian Schmaus flo at geekplace.eu
Sat Dec 9 09:20:51 UTC 2017


Hi Daniel,

On 08.12.2017 20:29, Daniel Gultsch wrote:
> XEP-0374 states that »The child elements of the OpenPGP content
> element's <payload/> can be seen as stanza extension elements which
> are encrypted and signed. After the <openpgp/> element and the
> including <signcrypt/>, element was verified, they SHOULD be processed
> similar as if they had been direct extension elements of the stanza.«
> 
> My interpretation is that this means that both! the regular stanza
> elements as well as the encrypted stanza elements will be processed.
> How do we make sure that they are not in conflict to each other; and
> or the 'outer' stanza elements can be used to manipulate the inner
> stanzas.
> 
> A quick example from the top of my head; What if an attacker sneaks in
> a <replaced id="some-previous-id"/> in the 'outer'/unecrypted stanza.
> 
> Or what if the outer as well as the inner stanza contain an origin-id.
> Which one counts? Do the inner elements always overwrite the outer?
> Should I not process any of the outer elements at all? What about a
> stanza-id in the outer part?
> 
> What about SIMS and other message references in the outer stanza? I
> think one can find a lot of XEPs, which, included in the outer stanza
> will have some influence on the inner stanza that may or may not be
> desirable in a XEP that's about security.

Exactly. That is why we deliberately underspecified this part because we
wanted to first gain experience from implementing it.

A first impression may be that the issue seems to be simply solved if we
say that elements within the <openpgp/> protection domain have
precedence, or even override, the ones in the outer stanza.

But there are examples where both elements are "valid". The prime
example is a <body/> element in the outer stanza which contains a text
explaining that the message is encrypted.

Eventually I believe that we can find a sensible solution for this. We
just have to find a good wording that we put into the specification(s).
Note that OX consists of a base specification XEP and application
profiles (currently only one: The OX-IM XEP). My idea is to put generic
rules into OX, which then can be extended by profile specific rules in
the profile XEP.

But before we do that, we really should first get some implementations
experience. It appears that you are at least considering working on an
implementation. I hope to continue the work on Smack's implementation
next year. Ideally we combine the knowledge what we have learned from
implementing OX into a spec update.

- Florian

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


More information about the Standards mailing list