Am 14.09.20 um 14:59 schrieb Dave Cridland: > The problem with it is that it won't cooperate with MAM, Carbons, etc. > > I think '290 is possibly the more practical, in terms of compatibility > with the existing infrastructure, but the coding is *much* more annoying.
I see. It's probably worth mentioning that my usecase is signing PEP items and that implementations will be aware that the content is signed. But for signing general purpose stanzas I tend to agree that 290 would be the way to go. > Happy Hacking > Paul > > Am 14.09.20 um 12:30 schrieb Dave Cridland: >> >> >> On Sat, 12 Sep 2020 at 12:36, Paul Schaub <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi List, >> >> I see there have been past activities around creating >> signatures for >> stanzas/elements. >> >> There are two deferred, competing proposals (XEP-0274: Design >> Considerations for Digital Signatures in XMPP ([1]) & XEP-0285: >> Encapsulating Digital Signatures in XMPP ([2])). >> >> >> Those aren't competing proposals; XEP-0274 really just provides a >> lot of background, proposes some useful terms, and summarizes the >> existing designs. XEP-0285, by the same author, *does* propose >> something new, as does XEP-0290 - also by Kurt. >> >> >> Winfried Tilanus very recently hinted towards XAdES as >> another signature >> standard that could be applied to XMPP ([3]). >> >> I recently looked into xmlsec and canonicalized XML via >> C14N11 but I'd >> like to ask if anyone has experience with creating signatures >> of stanza >> contents and sharing signed contents over XMPP. Which >> mechanisms are you >> using? Are you using one of the XEPs mentioned above? If not, >> why not? >> What tooling do you use to overcome the problems of signed XML? >> >> >> Broadly, XEP-0274 says there are two alternatives for signing at >> a high level, and both of them suck. XEP-0285 and XEP-0290 then >> demonstrate viable, well-designed, signature systems of both main >> types, and also demonstrate why they unfortunately suck. >> >> As far as I'm aware, neither '285 nor '290 were ever adopted >> anywhere, though I think Kurt might have written some code for >> one or both. >> >> The summary is, roughly, that signing XML is simple enough, but >> deciding what XML to sign, and what XML has been signed, are both >> much harder. Stanzas are routinely altered by servers as they >> pass through, normally by adding elements but occasionally by >> changing them, and the outer "envelope" of the stanza is also >> frequently rewritten. So senders must indicate what XML has been >> signed, as well as provide a signature. >> >> XEP-0285 does this by serializing the signed XML and signing that >> string, whereas XEP-290 approaches it by referencing the signed >> elements in-situ. >> >> Broadly, I think any approach we take is going to look very close >> to one or other. Nearly a decade ago, we decided by default that >> we couldn't bring ourselves to do either. >> >> If I were in the boil-the-ocean and forklift-upgrade brigade, I'd >> handle this by changing the wire protocol entirely to handle the >> distinction between originator content and intermediary metadata, >> and add signatures all the way down. >> >> Dave. >> >> _______________________________________________ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: [email protected] >> <mailto:[email protected]> >> _______________________________________________ > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > <mailto:[email protected]> > _______________________________________________ > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
