Directed one-to-one stanzas are stanzas which are exchanged between two entities, the originator of the stanza and intended recipient of that stanza, without exchanging through services which provide re-direction of stanzas (such as a groupchat service). The stanza may be handled by one or more other entities.

Examples of directed one-to-one stanzas include chat &MESSAGE; used in one-to-one chat sessions and &IQ; stanzas (excepting those exchanged through services providing re-direction).

The originator may wish to provide a signature for the benefit of the intended recipient. The intended recipient could use this signature to authenticate the originator and to ensure integrity of originator provided information.

Entities handling the stanza may wish to provide a signature for the benefit of the intended recipient. For instance, where a originator is a client and does not provide a signature, the client's server may wish to provide a signature for the benefit of the intended recipient. The intended recipient could use this signature to authenticate this server and to ensure integrity of the information as forwarded by this server.

Redirected one-to-one stanzas which are exchanged between two entities, the originator of the stanza and intended recipient of that stanza, through a service which provides re-direction of stanzas. The stanza may be handled by one or more other entities.

A multi-user chat (MUC) 'private message' is an example of redirected one-to-one stanza.

The originator's server may wish to provide a signature for the benefit of the re-direction service. The service could use this signature to authenticate the originator and to ensure integrity of originator provided information.

The originator may wish to provide a signature for the benefit of the intended recipient. The intended recipient could use this signature to authenticate the originator and to ensure integrity of originator provided information. However, this signature would by itself not establish any relationship between the signer and 'from' address in the stanza as received, nor does it establish this signature establish that the stanza was processed by the re-direction service. As in the directed one-to-one stanza, a originating client's server may wish to provide a signature for the benefit of the intended recipient.

The re-direction service may wish to provide a signature for the benefit of the intended recipient. The intended recipient could use this signature to authenticate the service and hence establish the service processed the stanza. The intended recipient could also use the signature to ensure the integrity of the information as redirected by the service.

Redirected one-to-many stanzas which are exchanged between two or more entities, the originator of the stanza and a group of recipients, through a service which provides re-direction of stanzas of a single stanza to a set of recipients. The stanza may be handled by one or more other entities.

A multi-user chat (MUC) message to all occupants is an example of redirected one-to-group stanza.

The originator's server may wish to provide a signature for the benefit of the re-direction service. The service could use this signature to authenticate the originator and to ensure integrity of originator provided information.

The originator may wish to provide a signature for the benefit of each recipient in the group. Each recipient could use this signature to authenticate the originator and to ensure integrity of originator provided information. However, this signature would by itself not establish any relationship between the signer and the 'from' address in the stanza as received, nor does it establish this signature establish that the stanza was processed by the re-direction service. As in the directed one-to-one stanza, a originating client's server may wish to provide a signature for the benefit of the each recipient.

The re-direction service may wish to provide a signature for the benefit of each recipient in the group. Each recipient could use this signature to authenticate the service and hence establish the service processed the stanza. Each could also use the signature to ensure the integrity of the information as redirected by the service.

The presence can be viewed as a specialized "publish-subscribe" mechanism. Commonly the publishing entity sends a &PRESENCE; stanza to a presence service and the presence service than forwards the stanza to each subscriber. In basic user presence, the publishing entity is the user's client and the presence service is presence service is the provided by this client's server. In this case, the 'to' address is empty.

The publisher may wish to sign the signature for the benefit of each subscriber. Each subscriber could use this signature to authenticate the publisher and to ensure integrity of publisher provided information.

The presence service may wish to provide a signature for the benefit of each subscriber. Each subscriber could use this signature to authenticate the service and hence establish the service processed the stanza. Each could also use the signature to ensure the integrity of the information as redirected by the service.

A presence stanza may also directed to another entity, possibly through a re-direction service. This use is similar to the directed one-to-one and redirected one-to-one cases detailed above.

The &IETF; standardized a signing and encryption facility for XMPP known as &xmppe2e;. XMPP E2E is based upon Secure/Multipurpose Internet Message Extensions (&SMIME;) and the Cryptographic Message Syntax (&CMS;). As it's name implies, XMPP E2E is intended to be an end-to-end solution. That is, it enables a sender to sign content sent to a specific recipient.

An advantage of the XMPP E2E approach is that it uses an encapsulating signature which protects the signed content from alteration as it is exchanged over an XMPP network. A disadvantage is that implementations which do not support XMPP E2E cannot make use of the signed content.

At the time of this writing, XMPP E2E has not been widely implemented. XMPP E2E appears to have limited applicability.

Alternative approaches have been developed. For instance, the Cross Domain Collaborative Information Environment (&CDCIE;) Client Chat Protocol (&CDCIE-CCP;), an XMPP-based protocol, supports signing of XMPP stanzas utilizes XML digital signatures (&XMLDSIG;) "enveloped" signatures over the whole stanza.

An advantage of the CDCIE-CCP approach is that, because it uses an encapsulated signature, implementations need not support CDCIE-CPP to make use of the stanza. The disadvantage is that the signature always over the entire stanza. Alteration of the stanza, as is common (often required) when exchanging stanzas over an XMPP network, will invalidate the signature.

While this approach has been implemented and deployed to some extent, the approach appears to have applicability limited to the CDCIE.

An encapsulating signature is a signature approach that encapsulates the signed content within the signature syntax. An encapsulated signature is a signature approach where the signature syntax in encapsulated within the structure of the signed content. XMPP E2E is an example of the former. CDCIE-CCP is an example of the latter.

The following example illustrates, using pseudo language, an encapsulating signature over a &MESSAGE; stanza.

To transfer a signed &MESSAGE; using an encapsulating signature, one needs to send it within &MESSAGE; stanza.

The following example illustrates, using pseudo language, an encapsulated signature over a &MESSAGE; stanza.

Applicability of a simple (non-nesting) encapsulating signatures, such as in XMPP E2E, are generally limited to end-to-end use cases. That is, cases where the originator of a stanza signs the stanza and send it through the XMPP network to its intended recipient, and only the intended recipient is expected to make use of the signed content. Entities between the signer and the intended recipient are expected to forward of the stanza without regard to the encapsulating signature, and without themselves signing the stanza. The approach does not require forwarding entities to support the signing extension.

Simple encapsulating signatures have limited applicability in MUC and PubSub use cases. For instance, an occupant can sign its submissions to the service for the benefit of the service and the service can sign reflected stanzas to occupants. In providing non-anonymous chat rooms, in addition to signing the reflected content, the service should include and sign the stanza it received when it was signed. This allows the occupants verify the content the service purports to have received, and to determine whether the reflected content is consistent given this. The following example illustrates an encapsulating signature over a groupchat &MESSAGE; stanza.

The following examples illustrates the signed reflection of the above stanza.

In encapsulated signature solutions, as in CDCIE-CCP, any entities can make use of the signed content even if they do not support the signing extension. If the signature is over the entire stanza, as in CDCIE-CCP, the signature is likely not to be valid when the stanza is passed through multiple entities prior to verification. Hence, when the signature is over the entire stanza, the encapsulating signature approach applicability is generally limited to cases where there no entities between the signer and verifier. However, as discussed below, encapsulated selective signatures are generally more applicable.

While an entity could provide a signature to be over the entire stanza, such signatures are likely be invalidated as the stanza exchanged over the XMPP. This is because XMPP allows and, in many cases, requires stanza to be modified as they are forwarded.

For instance, a client with the JID "juliet@example.com/Balcony" might send the following signed stanza:

The example.com server is required, per &rfc3920;, to add a 'from' attribute to the &MESSAGE; element before forwarding it to the example.net server. The example.net server is required to replace the 'to' attribute with the full JID of the romeo@example.net client it intends to forward the message to. These alternatations will "break" the signature.

XMLDSIG provides for a facility to selective sign XML content. For instance, the client could sign the &SUBJECT; and &BODY; element and their content. However, this by itself would not cover key aspects of the stanza, such that it was a chat &MESSAGE; addressed to a particular JID and sent from a particular JID. XMLDSIG allows for enveloping signatures, that is a signature that signs a data object contained within the &SIGNATURE; element. The solution could define an element, such as &XMPPprop; used below, for including properties of the stanza in the signature.

The signature in Example 1 does not provide any protection against replay attack. To address replay attack, as well as other concerns, XMLDSIG defines the &SIGNATUREPROPERTIES; element for including information items about the generation of the Signature, such as the date/time the signature was generated.

While one could have &SIGNATURE; which included a &REFERENCE; element for each of four elements discussed above within its &SIGNEDINFO; element, this would require reference validation for each &REFERENCE; (See 2.3 of XMLDSIG). To provide greater flexibility over handling of absent references and broken digest values, a &MANIFEST; can be constructed and only it signed.

Putting all of the above together, the client might send the following signed stanza:

The signature references needs to unambiguously identify content in stanza even in face of subsequent modification of that stanza. Failure to unambiguously identify signed content would also be problematic.

In the above example, signed child elements of the stanza were identified by 'id' attribute. As stanzas may be forwarded into any XMPP stream, such identifiers needs to remain unique.

Use of an extension attribute to identify elements may be problematic. In particular, the XMPP specifications provide no assurance that this attribute would be forwarded with element. While one could identify signed content by other means, such as &XPointer;, these means would not unambiguously identify the signed content in the face of subsequent stanza modification.

The an 'id' attribute is could be used (or possibly 'xml:id'), it may be appropriate for the XMPP entity inserting a child element into a stanza to provide an 'xml:id' attribute regardless of what stanza content it might sign.

Multiple entities can sign a stanza. A single entity may sign a stanza multiple times, typically on different occasions.

Each signer simply adds their &SIGNATURE; element to the stanza, typically as the last element. A &SIGNATURE; may sign other signatures, or portions thereof.

While a simple chat &MESSAGE; typically transits through only one or two XMPP servers and a groupchat &MESSAGE; may typically transits one to three XMPP servers, a stanza might include far more than four &SIGNATURE; elements.

One possible signing solution is for stanzas to carry alternative sets of content, an unsigned content alternative and a signed content alternative. An entity supporting the signing extension could make use of the signed content alternative while an entity not supporting the signing extension could make use of the unsigned content alternative. The following example not only illustrate this approach, but a significant issue with this approach:

Note that the &BODY; element values differ in the two alternatives.

An attacker could alter the unsigned content without alerting entities making use the signed content.

Instead of treating the signed and unsigned content as alternatives, the solution could limit use of the signed content to the validation of the unsigned data. However this solution suffers from many same issues encapsulated signatures suffer from, as well as suffering from unnecessary bloat.

Dual content approaches should be avoided.

While a signer may provide a &KEYINFO; element within the &SIGNATURE;, doing so will significantly increase the size of the &SIGNATURE; element. As implementations may enforce a maximum stanza size as small as 10,000 bytes, use of &KEYINFO; in stanza signatures should be limited.

It is also noted there are cases where the signer may not want to expose the key information to all entities involved in the exchange of stanza.

There are a number of ways key information may be published, such as in user's vCard. Key information can also be provided at request, such as by &IQ;.