<HTML>
<HEAD>
<TITLE>Re: [Standards] XMPP and W3C Digital Signature Specification</TITLE>
</HEAD>
<BODY>
<FONT SIZE="4"><FONT FACE="Arial"><SPAN STYLE='font-size:11pt'>we were primarily focusing on Digital Signing between the user and the server for auditing/integrity purposes and not in passing the dsig down stream to the destination user but I agree the S2S stuff does it much more complex. I think you end up having to focus on just the message content + jid (or something similar).<BR>
<BR>
boyd<BR>
 <BR>
<BR>
<BR>
On 4/6/08 10:33 PM, "David Waite" <dwaite@gmail.com> wrote:<BR>
<BR>
</SPAN></FONT></FONT><BLOCKQUOTE><FONT SIZE="4"><FONT FACE="Arial"><SPAN STYLE='font-size:11pt'>On Fri, Apr 4, 2008 at 9:50 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:<BR>
</SPAN></FONT></FONT><BLOCKQUOTE><FONT SIZE="4"><FONT FACE="Arial"><SPAN STYLE='font-size:11pt'>Who is "we"? Do you have multiple implementations in different<BR>
codebases? One of the major concerns I have heard with XML dsig is<BR>
interoperability (e.g., I have heard reports about serious interop<BR>
problems with SAML). In particular, I have heard that canonicalization<BR>
("c14n") has caused interop problems, since different people interpret<BR>
c14n differently (and there are 3 or 4 different c14n methods!).<BR>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT SIZE="4"><FONT FACE="Arial"><SPAN STYLE='font-size:11pt'><BR>
XML dsig generally has interoperability issues on usage, not in implementations. That said, its a brutally complex specification to implement and there are only four software implementations I can think of off-hand (apache's java and C++ impls, Microsoft's C# implementation, and libxml2/libxmlsec1).<BR>
<BR>
The more significant issue is that there is no guarantee that even modern Jabber protocol and XMPP implementations will not mess up XML in a way that breaks canonicalization. Server to Server traffic will munge up the namespace of the stanzas (from jabber:client to jabber:server), technically breaking a signature over any element in the jabber:client namespace, albeit temporarily.<BR>
<BR>
If an implementation reduces a stanza to a representation that isn't an infoset-compatible DOM its likely that it will reassemble the XML after routing in a way that would break signatures that aren't in the precise order given. Also note that every server implementation that supports S2S, for the changing namespace reason, would require some custom DOM or custom XML serialization engine that goes outside of what has been standardized by the W3C. <BR>
<BR>
>From the point of view of someone who has implemented XML dsig-based protocols in the past, Signing XML as XML rather than as opaque data is a pain in the neck and should be avoided. XML encryption is easier precisely because you have to encrypt the XML as data, not via some flexible ruleset against some mungable object structure. <BR>
<BR>
</SPAN></FONT></FONT><BLOCKQUOTE><FONT SIZE="4"><FONT FACE="Arial"><SPAN STYLE='font-size:11pt'><BR>
It might well be. I haven't heard much interest in digital signatures<BR>
for IM (heck, even email signing is not very popular, for example I'm<BR>
one of the only people posting to this list who signs his email with an<BR>
X.509 signature). I have heard some interest in end-to-end encryption,<BR>
but it's difficult even to get people interested in encryption.<BR>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT SIZE="4"><FONT FACE="Arial"><SPAN STYLE='font-size:11pt'><BR>
The security systems are themselves a network effect; I can't really care until I'm sure its available for everyone I communicate with. For the types of communication I typically have over IM, I would rather send the message unsigned/unencrypted than not send it. If communications were encrypted, I would probably put more high-value communications over IM. <BR>
<BR>
Signatures have little value for me on their own however. In an IM context, if a message has enough value to be signed to prevent forgery, it better also be encrypted to prevent someone else from reading it. <BR>
<BR>
-DW<BR>
<BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>