[Standards] XMPP and W3C Digital Signature Specification

Dave Cridland dave at cridland.net
Sat Apr 5 22:21:31 UTC 2008

On Sat Apr  5 04:50:12 2008, Peter Saint-Andre 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!).
This is what made us (Isode) look at XTLS as a possible  
integrity/authentication mechanism. That and we didn't really think  
anyone would want to do this. :-)

> 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.

We're very interested in it, since many of our clients are  
interested, and it happens to tie in with various cross-product  
features. Note that Todd Moyer's scenario also needs it.

> > A digital signature is encapsulated in the <ds:Signature/>  
> element. This
> > signature element is a child element of either <message/>,  
> <presence/>,
> > <iq/>.
> What do you sign? The complete stanza?
This is an interesting question also solved by XTLS. But the answer  
is probably that you mock a stanza, since signing the stanza header  
is important. Then again, that might change.

> > A client or server would use JID in XMPP stanzas to lookup a
> > client's X509 certificate.
> For X.509, I assume that the certificate would need to include an  
> OID (id-on-xmppAddr)? What if it doesn't?
No, how the certificate is tied to the Jid is an orthogonal problem -  
in fact, it's another of those "authorization versus authentication"  
games we can play. Ignore it for now.

> > The <ds:KeyName/> carries a X509 fingerprint which is a MD5  
> digest of the
> > X509 certificate and formatted as hex characters, each byte  
> separated by a
> > colon. For example,
> >  
> <ds:Key-Name>94:01:67:A6:45:70:B3:AD:8D:A3:8D:B9:2F:46:AA:52</ds:KeyName>
> >

Okay - we may all remember I maintain MD5 is safe for many tasks?  
This isn't, as I recall, one of them. I *think* that given that the  
signature itself is included here, we're safe, but if this is split  
out (as I suggest might be practical in my other message), this might  
need someone with more beard than I to have a look.

> > A digitally signed IQ stanza. Note this does cause a slight  
> incompatibility
> > with the current IQ schema as we would like to put the digital  
> signature as
> > a 2nd child node of IQ to make it consistent with message and  
> presence
> > stanzas.
> Would that be the only allowable second child of <iq/>? I'm not
> particularly interested in allowing multiple children of <iq/> in
> general, for many reasons (backwards-compatibility, information
> coherence for request-response interactions, etc.).

Yeah, I don't want to do this either. I know our server rejects <iq/>  
stanzas with multiple children, and it's possible other people's do  
as well. In this instance, it'd break things.

I think you probably do something like:

<iq ...>
	<query .../>

Loses backwards compatibility, but I can't see another way around.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list