Kev and I had a sidebar, and came to the following: * -0280 will require the wrapping message's 'from' attribute MUST be the carbonating user's bare JID * -0280 will add a paragraph to the SC to indicate any carbon that is *not* from the carbonating user's bare JID MUST be ignored * -0297 will better indicate it's meant to be an enabler, used by other protocols and not standalone * -0297 will add to its SC to tighten up trust considerations
Thanks again, Kev! - m&m On Jul 11, 2011, at 08:22 , Kevin Smith wrote: > On Mon, Jul 11, 2011 at 3:18 PM, Matthew A. Miller > <[email protected]> wrote: >> >> On Jul 11, 2011, at 04:15 , Kevin Smith wrote: >> >>> On Sun, Jul 10, 2011 at 9:15 PM, XMPP Extensions Editor <[email protected]> >>> wrote: >>>> Version 0.2 of XEP-0280 (Message Carbons) has been released. >>>> >>>> Abstract: In order to keep all IM clients for a user engaged in a >>>> conversation, outbound messages are carbon-copied to all interested >>>> resources. >>>> >>>> Changelog: Changed enabling and disabling to use separate elements rather >>>> than attributes; ensured all elements in the examples have their >>>> namespaces more explicitly defined; used message forwarding for carbon >>>> copies. (mm) >>>> >>>> Diff: http://xmpp.org/extensions/diff/api/xep/0280/diff/0.1/vs/0.2 >>>> >>>> URL: http://xmpp.org/extensions/xep-0280.html >>> >>> I think: >>> "The wrapping message SHOULD maintain the same 'type', 'from', and >>> 'id' attribute values (if any), while the 'to' attribute SHOULD be the >>> full JID of the resource receiving the copy." >>> >>> isn't right. The encapsulated message already has these data available >>> - the encapsulating message should have attributes that reflect who is >>> really sending/receiving the stanza (i.e. to=the client receiving the >>> carbon, from=the server or the bare JID, unique id). >>> >> >> I don't quite agree with you; I think there should be some corroborating >> information between the wrapped and wrapping message, especially with one of >> the addresses ('from' seems the least routing-intesive here). The id can be >> relaxed, although I think keeping the type is worthwhile ("normal" and >> "headline" don't seem right here). >> >> I may be paranoia on my part, but I don't want to implicitly trust any >> <forwarded/> that I get. Granted, nothing is guaranteed here without >> digitally signing, but correlating at least one address seems better than >> nothing at all. > > I don't see any possible attack that checking they match would abate. > On the other hand, I do see why knowing which entity is performing the > carbonating is safer. Can you provide an example of something that's > better with faking the from than stamping it with the server/bare JID > (which I think are equivalent for the purposes of this and we can > safely pick either)? > > /K
smime.p7s
Description: S/MIME cryptographic signature
