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).
boyd
On 4/6/08 10:33 PM, "David Waite" <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 4, 2008 at 9:50 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>> Who is "we"? Do you have multiple implementations in different
>> codebases? One of the major concerns I have heard with XML dsig is
>> interoperability (e.g., I have heard reports about serious interop
>> problems with SAML). In particular, I have heard that canonicalization
>> ("c14n") has caused interop problems, since different people interpret
>> c14n differently (and there are 3 or 4 different c14n methods!).
>
> 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).
>
> 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.
>
> 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.
>
> 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.
>
>>
>> It might well be. I haven't heard much interest in digital signatures
>> for IM (heck, even email signing is not very popular, for example I'm
>> one of the only people posting to this list who signs his email with an
>> X.509 signature). I have heard some interest in end-to-end encryption,
>> but it's difficult even to get people interested in encryption.
>
> 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.
>
> 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.
>
> -DW
>
