July 2011


Digital signatures are a key part of modern secure communication to provide authentication and integrity services. This paper looks at requirements for using digital signatures with XMPP messages, and how these are addressed by XEP-0290 (Encapsulated Digital Signatures in XMPP), which Isode believes will evolve to be the de jure standard for XMPP message signatures. Finally the paper looks at support for XEP-0290 in Isode’s M-Link and M-Link Edge products.

Creative Commons License


The technical details of how digital signatures on XMPP messages work are quite intimidating, and even the list of high level requirements is quite technical. This section gives a few example scenarios to show how digital signatures can be applied to XMPP messages and the benefits of doing so.

End to End Signature


End to End Signature


In this example, the sender of an XMPP message signs it, when it is sent. This signature is then passed through all of the intermediate servers and is verified by the message recipient. This allows the recipient to verify a number of things:

  1. That the message really was sent by the user claiming to. This gives protection against messages forgery.
  2. That the content of the message has not been changed. This gives protection against the message being tampered with in transit.
  3. The time the message was sent. This gives protection against replay of an old message, which could have significantly different meaning or validity in the new context.

MUC Signature


MUC Signature


In this second scenario a message is sent to a MUC (Multi-User Chat) room, and the MUC room adds another signature. The client can then verify both signatures, which enables the user to verify a number of things:

  1. All of the things that were verified in the first scenario, using the original message signature. These remain important.
  2. The second signature enables the receiver to determine that the message really did go through the MUC room. This guards against a message being created and signed (correctly) and then modified to look as if it went through the MUC room, where it did not.

Guard Signature (Cross Domain)


Guard Signature


In this third scenario, the sender and receiver are working in different security domains connected by an XMPP Guard. Security labels are used, and the message sender adds a security label. At the boundary, the Guard strips the original signature and label and adds new ones, which are received and verified by the message recipient.

The sender's security label indicates the sensitivity of the message, and will be used by the guard to control message transfer across the boundary. The security label will be bound to the message by the digital signature. This is important, to prevent the security label from being removed or tampered with.

In many boundary scenarios, as in this one, the security (label) policy on each side of the guard is different, and so the security label needs to be changed at the boundary to an appropriate label that will be valid in the recipient’s domain. One option would be to remove the original label, add a new one and have the gateway sign the new message, while retaining the original signature for the recipient to verify; so there could be a double signature as in the MUC scenario. In this example, the original signature is stripped. This is because the recipient will not have a PKI trust path to the sender and so the original signature is of little value. The recipient does trust the guard and the signature applied by the guard, and can rely on the guard to verify the sender’s signature.

Requirements for XMPP Message Signatures

Having seen how XMPP message signatures can be used, a more detailed list of requirements for an XMPP message signature solution can be set out:

  1. Message Origin Authentication. Need to be able to verify the XMPP message originator.
  2. Content Integrity. Need to be able to verify that message content has not been tampered with.
  3. Validation of signature time. To prevent replay attacks.
  4. Signature by server entities, including:
    • Server or service domain, to validate message handling by server. This will be particularly useful where messages are not signed by the originator (e.g., from a client not supporting digital signatures).
    • MUC Room (as in the second scenario)
    • PubSub Node. See the Isode whitepaper [XMPP PubSub]
    • XMPP Boundary Guard.
  5. Ability to have multiple signatures.
  6. Ability to bind Security Labels to messages.
  7. Signing to be provided in a way that does not change basic message syntax. This will allow signed messages to be handled by standard clients that do not have any digital signature support. This in turn enables “Optimistic” signing, so that an entity can add a signature without having to first check on the capabilities of entities that will subsequently handle the message.
  8. Ability to deal with standard ways in which XMPP servers and services modify messages. In particular:
    • Addition of delay timestamps (e.g., for offline messages).
    • Modification of from and to for MUC messages.
    • Change of XML encoding (some servers rewrite XML, and this is allowed).

Complementary Security Services

Message signature is only one of a number of security services relevant to XMPP. Three security services related to digital signatures are considered here.

Peer Authentication

Digital signatures can be used in both of the XMPP core XMPP protocols. These are based on SASL EXTERNAL authentication using X.509 PKI (Public Key Infrastructure).

Digital signatures are the best way to handle server to server authentication. They provide significantly better security than use of dial-back, and it also enables the connection between a pair of servers to use a single TCP connection. PKI based peer to peer authentication for servers is a good choice for all XMPP deployments.

Digital signatures can also be used to verify clients to servers. This provides good security, although may be less convenient for some users than password based authentication. It also enables a client to verify that it is connecting to the correct server. This 'hop by hop' authentication is complementary to the end to end security of message signatures.

Link Data Confidentiality

TLS (Transport Layer Security) can be provided for client to server connections and for server to server connections. TLS will be used where digital signatures are used for peer authentication, as SASL EXTERNAL is based on TLS. If peer authentication is needed without data confidentiality, a TLS Cipher Suite that provides data integrity only can be selected. Use of TLS prevents network eavesdropping of data, but does not prevent server level attacks. Also, the choice to use TLS is per-hop, and so the sender will not in general know if TLS is used for all connections.

End to End Encryption

There is ongoing work to add end to end encryption to XMPP, so that the sender of a message can encrypt data sent, and then it is decrypted by the recipient. End to end encryption ensures that servers and other intermediate components cannot read or modify the data being transferred. This is specified in End-to-End Object Encryption for the Extensible Messaging and Presence Protocol (XMPP).

This approach has similarities to an approach to digital signatures discussed later (using encapsulating signatures). Many applications of digital signatures explicitly require that data is not encrypted, for example to enable mappings by gateways at organizational boundaries, and to ensure that all data is checked. For this reason, standardized approaches to digital signatures need to be independent of this planned approach for end to end encryption.

Why Standardization

It can be seen from the scenarios given earlier that a number of different entities will be involved with signing and verifying digital signatures. For these sorts of scenarios to work in a large scale environment, standards for digital signatures are crucial. Relying on a single vendor for all components is unrealistic.


Isode has been pro-actively working to develop XEP-0290 (Encapsulated Digital Signatures in XMPP), which we believe will be the basis for a future standards for XMPP digital signatures. Key features of XEP-0290:

  • The digital signatures are based on 'XML DSIG', XML Signature Syntax and Processing which is a W3C standard for signing XML documents using X.509 digital signatures. As XMPP is XML based, it seemed sensible and desirable to adopt an existing standard for signing XML documents.
  • The signature is 'encapsulated', which means that it is carried within a standard XMPP message, and that elements which do not signature aware will just ignore the signature bits. This 'transparent' approach is desirable, and enables optimistic signing (when you do not know if other components can handle the signature).
  • Elements of the message have independent signatures, so that you can determine independently if each part has changed. This is important, as there may be valid reasons to change some parts of the message while it is in transit, and the receiver will not be concerned that this has happened.

Here is an example message. This is taken from XEP-0290, and explained in more detail there.

<message from='juliet@capulet.net'

<thread xmlns:d="urn:xmpp:dsig:0" d:id="xxxx-1">8996aef0-061d-012d-347a-549a200771aa</thread>
<body xmlns:d="urn:xmpp:dsig:0" d:id="xxxx-2">Wherefore art thou, Romeo?</body>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/
<Reference URI="#stanza-desc">

<Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>


<stanza-desc id="stanza-desc" xmlns="urn:xmpp:dsig:0">
<Transforms><Transform Algorithm="urn:xmpp:dsig:transform:0"/></Transform>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<message from='juliet@capulet.net'

<reference URI='urn:xmpp:dsig:ref:0#xxxx-1'>...</reference>
<reference URI='urn:xmpp:dsig:ref:0#xxxx-2'>...</reference>



This message looks rather scary at first glance, but it is quite straightforward to see what is going on. The bulk of the XML is necessary for digital signature, and comes straight from XML DSIG. Specific points to note:

  1. The digital signature is in the block <Signature> … </Signature>, which is the bulk of the example.
  2. The original message also has two elements of the form xmlns:d="urn:xmpp:dsig:0" d:id="xxxx-1">, which are references that allow the signature to reference specific independent elements of the message. If these references and the signature block are removed, a familiar and simple XMPP message remains.
  3. Details of the signature are defined by XML DSIG. Key features to note:
    • SignatureMethod, defines the cryptography used for the signature.
    • SignatureValue is the actual signature.
    • DigestValue is a hash of the elements in the 'Transform' section, which is signed and used to verity the message. The Transform section contains:
      • Copies of the original outer message elements (from, id, to, type).
      • Hashes of the two referenced elements included in the signature, so that these can be independently verified.
      • A timestamp (to prevent replay attacks, and give a verifiable time of signature).
        A more detailed description of this is provided in XEP-0290.

Other Approaches

A general review of requirements for XMPP digital signatures and approaches to provide this is given in XEP-0274 (Design Considerations for Digital Signatures in XMPP).

A key alternate approach is set out in XEP-0285 (Encapsulating Digital Signatures in XMPP). (Note that this is Encapsulating in contrast to Encapsulated). An encapsulating signature is opaque and wraps the entire XMPP message. A key benefit is that this is a simpler approach, and avoids issues of element reference and canonicalization that the encapsulated (transparent) approach has. The key difficulty is that signed messages can only be handled by elements that can process the signatures, so an entity signing the message needs to determine if signatures can be correctly handled by recipient and/or relevant intermediate components. We believe that this will make an encapsulating approach very hard to deploy, and so have concluded that the encapsulated approach of XEP-0290 is the best approach.

We also note that the CDCIE Client Chat Protocol, which JChat and TransVerse implement, uses an enveloped XML DSIG approach (which is a specialized encapsulated signature form). As this signature is over the entire XMPP stanza, the signature will generally be broken at other entities, such as at MUC rooms and any other XMPP servers involved in the exchange, due to XMPP required stanza modifications (such as to/from address changes). This approach is not generally viable.

Certificate Publishing

In order to verify an X.509 digital signature, one or more Certificates (issued by an X.509 Certificate Authority) are needed by the verifier. In particular, the Certificate issued to the 'signer' is needed. Many protocols that use digital signatures allow for the 'signer' to provide certificates to the verifier, and this approach is often used. The signer will generally have the necessary certificate, and the verifier may not.

Certificates are quite large and, unlike XML based signatures, do not compress well. XMPP often involves exchange of large numbers of messages, and so it would be inefficient to transfer certificates with every message. So XEP-0290 does not allow for this.

A natural XMPP approach to this problem is for the sender to publish appropriate certificates, in a manner that interested parties can discover and retrieve using XMPP IQ (Information Query) messages.

There is ongoing work by a number of parties to specify a standardized approach to doing this, and this will be a key element of the final standardized solution for XMPP digital signatures.

M-Link & M-Link Edge Support for Digital Signatures

Isode is developing XEP-0290 support in its XMPP Server (M-Link) and XMPP Boundary Server (M-Link Edge). This capability is working in house, and we can share with interested parties. We expect to include XEP-0290 in a product release in 2011.

It might seem that the 'first' place to provide digital signature support is in an XMPP client, so that end to end services can be provided. There is significant advantage to starting with the server, as this will enable deployment in environments where some or all clients do not support digital signatures. The following digital signature services have been implemented in M-Link:

  • Signature verification. Digital signatures can be verified, and messages rejected where a signature check fails. Signature checking results can be included in the message, so that 'last hop' server verification information can be provided to clients that cannot verify the signatures themselves.
  • Signing on submission. M-Link can sign an XMPP message on behalf of a client that does not sign messages. This can be constrained (e.g., to only sign where the client has verified using TLS digital signatures and message integrity is guaranteed by TLS protection between client and server). Having the server sign is important when signatures are required by external systems and boundary guards.
  • MUC signing. MUC rooms and other components can add digital signatures to messages.
  • Boundary processing by M-Link Edge. This can be simply to add a signature, or can be more complex. For example to strip a signature, map security labels, and then sign again. In many situations, signing at the boundary is important, as recipients will be able to verify boundary signatures, but not originator signatures.

We believe that this will be sufficient to provide useful deployment of XMPP digital signature, prior to XMPP client support.


This paper has described why XMPP digital signatures are important, how XEP-0290 encapsulated (transparent) digital signatures work, and why we believe XEP-0290 will be the open standard for XML digital signatures.