[Standards] XMPP and W3C Digital Signature Specification
Fletcher, Boyd C. CIV US USJFCOM JFL J9935
Boyd.Fletcher at je.jfcom.mil
Tue Apr 8 02:36:23 UTC 2008
On 4/4/08 11:50 PM, "Peter Saint-Andre" <stpeter at stpeter.im> wrote:
> Hi Boyd, thanks for posting about this.
> Boyd Fletcher wrote:
>> Over the last couple of years we have discussed various approaches to add
>> digital signature support to XMPP
> In fact we haven't had many discussions about digital signatures, mostly
> about end-to-end encryption. :)
>> that did not violate the XML nature of
>> XMPP like RFC3923.
> Well, that's a good thing. :)
>> We would like to propose a method of using W3C¹s XML
>> Digital Signature specification. Below is description of how we use the W3C
>> spec with XMPP. We have been using this approach for about 3 years and it
>> seems to work quite well though it is a bit expensive in terms of message
>> size but with digital signatures, I¹m not sure that can be avoided.
> Who is "we"? Do you have multiple implementations in different
> codebases? One of the major concerns I have heard with XML dsig is
we have been using a custom implementation and one from Apache
> 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!).
canonicalization has proven to be a bit tricky
>> We are curious what other people think and if its worth moving forward with
>> a XEP to formally describe the approach.
> 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.
Digital Signatures are quite popular in defense establishment. ;)
>> We chose to use the W3C because its standardized, well understood, and
>> widely implemented. We were not planning to address how the public keys
>> between the users are exchanged or how the certificates are validated.
> Do you have comments on XEP-0189? It's currently in Last Call.
no but that is because we really haven't looked at it since key is exchange
is handled differently in our environment. we will look at it.
>> A digital signature is encapsulated in the <ds:Signature/> element. This
>> signature element is a child element of either <message/>, <presence/>,
> What do you sign? The complete stanza?
pretty much the entire stanza.
>> 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 XMPP
> OID (id-on-xmppAddr)? What if it doesn't?
we didn't include one, but it probably would be a good idea.
>> When multiple certificates are available for that
>> JID, the <ds:KeyName/> will identify which to use.
>> 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,
>> 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
> 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.).
I guess it could be but then that would cause some confusion with the RFC.
We have tested out "hacked" IQ approach with several XMPP server and clients
and they all seem to ignore it so it don't think it will cause many
> <snip>huge stanzas :)</snip>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3732 bytes
Desc: not available
More information about the Standards