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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
