On Mon, 14 Sep 2020 at 13:47, Paul Schaub <[email protected]> wrote:
> Hi Dave, > > thank your for your reply. > Its a pity that stanza/element signing hasn't caught any real adoption in > the XMPP ecosystem. > > I think for my usecase I will look closer at XEP-0285, as it appears that > it adds the least overhead (apart from applying base64 twice). > 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. > 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]> 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] > _______________________________________________ > > _______________________________________________ > 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] _______________________________________________
