> But also XML C14N-based signing (such as XMLDSIG, which also happens in the > real world) would be broken by element reordering.
Doesn’t the server adding or overriding a “from” in RFC6120 8.1.2.1 already break XMLDSIG canonicalization? > You not emitting in the correct order is an interop concern as we've seen, > but is broadly something we can argue about. You not caring about ordering > when forwarding seems like it's broken. I emit in the correct order, even if it’s not the original order. I maintain order where it matters. In the case of a data forms with <reported/> after the <item/>s, my implementation would forward the “correct” version with <reported/> first. Is that worse than sending the original? I feel like there’s something in the spec I am missing here. > On Feb 17, 2021, at 9:44 AM, Dave Cridland <d...@cridland.net> wrote: > > > > On Wed, 17 Feb 2021 at 13:31, <drew.var...@ninefx.com> wrote: >> But you reorder different elements with anything that has a spec when >> forwarding, is that right? > > Correct. We may change the order in which child elements appear for elements > in our spec. Order among child elements of the same type (el name + > namespace) is stable. Child elements of the same type will always appear > contiguously. > > > OK, this sounds like a bug you may wish to fix. > > There's nothing in our specifications which says that ordering is > insignificant, and general principles such as the end-to-end principle very > strongly suggest you shouldn't be messing with any ordering which could - to > the endpoints - be significant (even if you think it isn't). > > There are practical examples which could be covered by your code here, like > security labelling in PubSub, which (in practise, and contrary to what > XEP-0314 says on the issue) adds child elements to the <item/> after the > payload, and consumers assume the first element is always the payload. > > But also XML C14N-based signing (such as XMLDSIG, which also happens in the > real world) would be broken by element reordering. > > You not caring about ordering on parsing is fine. You not emitting in the > correct order is an interop concern as we've seen, but is broadly something > we can argue about. You not caring about ordering when forwarding seems like > it's broken. > > We don’t have a good way to annotate/enforce that certain child element types > need to appear before other child element types. > > Attribute order, namespacing method (xmlns vs. prefix), and insignificant > white space could also change. > > Aside from the latter - it's not clear to me how you tell if whitespace is > truly insignificant - those are all OK, though unexpected. > > >> On Feb 17, 2021, at 7:27 AM, Dave Cridland <d...@cridland.net> wrote: >> >> >> >> >> On Tue, 16 Feb 2021 at 15:07, Drew Varner <drew.var...@ninefx.com> wrote: >> > So, for example, XEP-0141 page elements could be reordered? >> >> No. The spec does not know about markup mini languages like XEP-0141, >> XEP-0071, XEP-0393 and XEP-0394. Markup is validated at the client. Order >> is maintained because the spec just encodes unknown XML into a struct that >> maintains child order. It’s just a pain to bake those into the spec. >> >> > Fields in forms are assumed to be ordered as well, >> >> No. The order of XData fields in a form (“x”) is maintained. It’s a list of >> fields. The order that could change is whether the list of instructions >> comes after the list of fields. >> >> https://github.com/processone/xmpp/blob/master/specs/xmpp_codec.spec#L2027-L2028 >> >> But you reorder different elements with anything that has a spec when >> forwarding, is that right? >> >> Dave. >> _______________________________________________ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: standards-unsubscr...@xmpp.org >> _______________________________________________ > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
