mirror of https://github.com/moparisthebest/xeps
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
651 lines
40 KiB
651 lines
40 KiB
<?xml version='1.0' encoding='UTF-8'?> |
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [ |
|
<!ENTITY % ents SYSTEM 'xep.ent'> |
|
%ents; |
|
<!ENTITY SIGNATURE "<Signature/>"> |
|
<!ENTITY REFERENCE "<Reference/>"> |
|
<!ENTITY SIGNEDINFO "<SignedInfo/>"> |
|
<!ENTITY KEYINFO "<KeyInfo/>"> |
|
<!ENTITY SIGNATUREPROPERTIES "<SignatureProperties/>"> |
|
<!ENTITY MANIFEST "<Manifest/>"> |
|
<!ENTITY XMPPprop "<XMPPproperties/>"> |
|
<!ENTITY SMIME "<span class='ref'><link url='http://tools.ietf.org/html/rfc3851'>S/MIME</link></span> <note>RFC 3851: Secure/Multipurpose Internet Mail Extensions (S/MIME) <<link url='http://tools.ietf.org/html/rfc3851'>http://tools.ietf.org/html/rfc3851</link>>.</note>" > |
|
<!ENTITY CMS "<span class='ref'><link url='http://tools.ietf.org/html/rfc3852'>CMS</link></span> <note>RFC 3852: Cryptographic Message Syntax (CMS) <<link url='http://tools.ietf.org/html/rfc3852'>http://tools.ietf.org/html/rfc3852</link>>.</note>" > |
|
<!ENTITY CDCIE "<span class='ref'><link url='http://www.jfcom.mil/about/facts_prt/MNIS.pdf'>CDCIE</link></span> <note>USFCOM fact sheet: Multinational Information Sharing and the Cross Domain Collaborative Information Environment <<link url='http://www.jfcom.mil/about/facts_prt/MNIS.pdf'>http://www.jfcom.mil/about/facts_prt/MNIS.pdf</link>>.</note>" > |
|
<!ENTITY CDCIE-CCP "<span class='ref'>CDCIE-CCP</span> <note>Cross Domain Collaborative Information Environment (CDCIE) Chat Client Protocol Specification, Version 2.0, Trident Systems, Inc., 12 March 2008</note>" > |
|
<!ENTITY XMLDSIG "<span class='ref'><link url='http://www.w3.org/TR/xmldsig-core/'>XMLDSIG</link></span> <note>XML Signature Syntax and Processing, W3C Recommendation, 10 June 2008 <<link url='http://www.w3.org/TR/xmldsig-core/'>http://www.w3.org/TR/xmldsig-core/</link>>.</note>" > |
|
<!ENTITY XPointer "<span class='ref'><link url='http://www.w3.org/TR/xptr'>XPointer</link></span> <note>XML Pointer Language (XPointer), W3C Recommendation, 8 June 2001 <<link url='http://www.w3.org/TR/xptr'>http://www.w3.org/TR/xptr</link>>.</note>" > |
|
]> |
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?> |
|
<xep> |
|
<header> |
|
<title>Design Considerations for Digital Signatures in XMPP</title> |
|
<abstract>This document discusses considerations for the design of Digital Signatures in XMPP, |
|
including use cases and requirements. The document also discusses various ways XML Digital |
|
Signatures could be used in XMPP.</abstract> &LEGALNOTICE; <number>0274</number> |
|
<status>Deferred</status> |
|
<type>Informational</type> |
|
<sig>Standards</sig> |
|
<approver>Council</approver> |
|
<dependencies> |
|
<spec>XMPP Core</spec> |
|
<spec>XEP-0001</spec> |
|
</dependencies> |
|
<supersedes/> |
|
<supersededby/> |
|
<shortname>N/A</shortname> |
|
&kdz; |
|
<revision> |
|
<version>0.4.1</version> |
|
<date>2018-11-03</date> |
|
<initials>pep</initials> |
|
<remark>Fix a bunch of typos, batch-style.</remark> |
|
</revision> |
|
<revision> |
|
<version>0.4</version> |
|
<date>2011-01-28</date> |
|
<initials>kdz</initials> |
|
<remark> |
|
<p>Update/fix references.</p> |
|
</remark> |
|
</revision> |
|
<revision> |
|
<version>0.3</version> |
|
<date>2011-01-12</date> |
|
<initials>kdz</initials> |
|
<remark> |
|
<p>Update discussions based upon introduction of Encapsulated Digital Signatures in XMPP, an |
|
alternative to XEP-0285.</p> |
|
</remark> |
|
</revision> |
|
<revision> |
|
<version>0.2</version> |
|
<date>2010-09-29</date> |
|
<initials>kdz</initials> |
|
<remark> |
|
<p>Update discussions based upon introduction of Digital Signatures in XMPP.</p> |
|
</remark> |
|
</revision> |
|
<revision> |
|
<version>0.1</version> |
|
<date>2009-09-15</date> |
|
<initials>psa</initials> |
|
<remark> |
|
<p>Initial published version as accepted for publication by the XMPP Council.</p> |
|
</remark> |
|
</revision> |
|
<revision> |
|
<version>0.0.1</version> |
|
<date>2009-08-20</date> |
|
<initials>kdz</initials> |
|
<remark> |
|
<p>Proto-XEP draft.</p> |
|
</remark> |
|
</revision> |
|
</header> |
|
|
|
<section1 topic="Introduction" anchor="intro"> |
|
<p>Digital signatures may be used to provide a number of security services, including message |
|
authentication, message integrity and non-repudiation. There are many use cases for Digital |
|
Signatures in the Extensible Messaging and Presence Protocol (&xmpp;).</p> |
|
<p>XMPP can be described as a mean for exchanging structured information or stanzas between two |
|
or more entities. To accomplish this exchange, a number of other entities may be involved. For |
|
instance, communication of a stanza between two client entities will typically involve one or |
|
more server entities. Entities may exchange stanzas through service entities, such as a chat |
|
room service, to effect one-to-many communications.</p> |
|
<p>Any entity involved in the exchange of a stanza may have wish to include one or more digital |
|
signatures for the benefit of any entity involved in the exchange:</p> |
|
<ul> |
|
<li>A client might wish to sign information it exchanges with another client for the benefit |
|
of this client (e.g, to provide message origin authentication service and content integrity |
|
service)</li> |
|
<li>A client might wish to sign a message in order to bind a Security Label to that |
|
message.</li> |
|
<li>A client may wish to sign information it sends to a chat room for the benefit of the chat |
|
room service and/or for the benefit of room occupants.</li> |
|
<li>The chat room service may wish to sign information it forwards to room occupants for the |
|
benefit of room occupants, such as to bind the client's JID to the client's room JID.</li> |
|
<li>A server involved in the exchange of a stanza between two clients may wish to sign |
|
information for the benefit of another server involved in the exchange (e.g., to provide |
|
delivery path validation).</li> |
|
<li>A server may wish to add additional data to a message, for example a Security Label, and |
|
bind that data to the message with a digital signature.</li> |
|
</ul> |
|
<p>Digital signatures are provided to serve specific purposes. These purposes might include |
|
authentication of a particular entity involved in the exchange and integrity of information |
|
that entity provided.</p> |
|
|
|
<p>This document discusses <link url="#design">considerations for the design</link> of |
|
general-purpose digital signature extension for XMPP. The document discusses <link url="#uses" |
|
>use cases</link> and <link url="#requires">requirements</link>, as well as explores the |
|
solution space. The document also discusses <link url="#existing">existing solutions</link> in |
|
this area.</p> |
|
|
|
<p>This document contains a numerous examples intended to aide in the discussion of design |
|
issues. The examples are examples generally abbreviated and often use informal syntaxes.</p> |
|
</section1> |
|
|
|
<section1 topic="Use Cases" anchor="uses"> |
|
<section2 topic="Use in directed one-to-one stanzas" anchor="direct-1to1-use"> |
|
<p>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.</p> |
|
<p>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 <link |
|
url="redirect-1to1-use">re-direction</link>).</p> |
|
<p>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.</p> |
|
<p>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. </p> |
|
</section2> |
|
|
|
<section2 topic="Use in redirected one-to-one stanzas" anchor="redirect-1to1-use"> |
|
<p>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. </p> |
|
<p>A multi-user chat (MUC) 'private message' is an example of redirected one-to-one |
|
stanza.</p> |
|
<p>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.</p> |
|
<p>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 <link url="#direct-1to1-use">directed one-to-one |
|
stanza</link>, a originating client's server may wish to provide a signature for the |
|
benefit of the intended recipient.</p> |
|
<p>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.</p> |
|
</section2> |
|
|
|
<section2 topic="Use in redirected one-to-group stanzas" anchor="redirect-1toG-use"> |
|
<p>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. </p> |
|
<p>A multi-user chat (MUC) message to all occupants is an example of redirected one-to-group |
|
stanza.</p> |
|
<p>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.</p> |
|
<p>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 <link url="#direct-1to1-use">directed one-to-one |
|
stanza</link>, a originating client's server may wish to provide a signature for the |
|
benefit of the each recipient.</p> |
|
<p>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.</p> |
|
</section2> |
|
|
|
<section2 topic="Use in presence stanzas" anchor="presence-use"> |
|
<p>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.</p> |
|
<p>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.</p> |
|
<p>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.</p> |
|
<p>A presence stanza may also directed to another entity, possibly through a re-direction |
|
service. This use is similar to the <link url="#direct-1to1-use">directed one-to-one</link> |
|
and <link url="#redirect-1to1-use">redirected one-to-one</link> cases detailed above.</p> |
|
</section2> |
|
</section1> |
|
|
|
<section1 topic="General Requirements" anchor="requires"> |
|
<p>For the purposes of this memo, the following requirements are stipulated for a general |
|
solution: </p> |
|
<ol start="1"> |
|
<li>The extension shall support client signing of stanzas.</li> |
|
<li>The extension shall support service (e.g., multi-user chat service) signing of |
|
stanzas.</li> |
|
<li>The extension shall support server signing stanzas.</li> |
|
<li>The extension shall support multiple signatures in a stanza. That is, multiple entities |
|
can sign a stanza.</li> |
|
<li>The extension shall support signing of &IQ; stanzas.</li> |
|
<li>The extension shall support signing of &MESSAGE; stanzas, including chat and |
|
groupchat.</li> |
|
<li>The extension shall support signing of &PRESENCE; stanzas.</li> |
|
<li>The extension shall support selective signing of stanzas. That is, a signer can sign |
|
select portions of a stanza.</li> |
|
<li>The extension shall support signing of externally referenced object. That is, the |
|
signature may include a message digest of an external object, such as an HTTP accessible |
|
content.</li> |
|
<li>The extension shall allow selective verification of signed elements. </li> |
|
<li>The extension shall allow independent handling of verification errors in signed |
|
content.</li> |
|
<li>The extension shall allow signers to provide signed copies of data likely to be modified |
|
by intermediate entities, such as stanza 'to' and 'from' attributes.</li> |
|
<li>The extension should avoid duplication of content.</li> |
|
<li>The extension must provide a means for relating signed content with unsigned content.</li> |
|
<li>The extension should support querying for key information in XMPP (e.g., &IQ;).</li> |
|
<li>The extension should support communicating key information through their XMPP-published |
|
vCard.</li> |
|
<li>The extension should be designed such that the successful verification of a signature is |
|
independent of the extension support in entities involved in the exchange.</li> |
|
<li>The extension should be compatible with object encryption, supporting encryption of signed |
|
content, signing of encrypted content, and signing of encrypted signed content (e.g., triple |
|
wrap content).</li> |
|
</ol> |
|
<p>Some of above requirements may well be, if not outright mutually exclusive, in opposition to |
|
each other. It is suspected that set of reasonable solutions meeting all of the above |
|
requirements may be empty. To produce a reasonable solution, it is expected that some of the |
|
above requirements be eliminated and hence limiting the solution to some subset of the |
|
applications of digital signatures in XMPP.</p> |
|
</section1> |
|
|
|
<section1 topic="Existing Solutions" anchor="existing"> |
|
<section2 topic="XMPP E2E" anchor="xmpp-e2e"> |
|
<p>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 its 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.</p> |
|
<p>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.</p> |
|
<p>At the time of this writing, XMPP E2E has not been widely implemented. XMPP E2E appears to |
|
have limited applicability. </p> |
|
</section2> |
|
<section2 topic="PGP signatures in XMPP" anchor="xmpp-e2e"> |
|
<p>The &xep0027; (XMPP PGP), like the XMPP E2E, uses an encapsulating signature to protects |
|
the signed content from alteration as it is exchanged over an XMPP network. Like XMPP E2E, |
|
it is intended to be an end-to-end solution.</p> |
|
<p>At the time of this writing, XMPP PGP has not been widely implemented (though some |
|
implementations do exist). XMPP PGP appears to have limited applicability.</p> |
|
</section2> |
|
<section2 topic="Encapsulating Digital Signatures in XMPP" anchor="xmpp-e2e"> |
|
<p>The &xep0285; (XMPP EgDSIG), like the XMPP E2E and XMPP PGP, uses an encapsulating |
|
signature to protects the signed content from alteration as it is exchanged over an XMPP |
|
network.</p> |
|
<p>Unlike XMPP E2E and XMPP PGP, the solution is not intended to be strictly end-to-end in |
|
that multiple signers and verifiers where contemplated, now of which is necessarily an end |
|
entity. However, like XMPP E2E, it does not supported <em>optimistic signing</em>.</p> |
|
</section2> |
|
<section2 topic="CDCIE-CCP" anchor="cdcie-ccp"> |
|
<p>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.</p> |
|
<p>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.</p> |
|
<p>While this approach has been implemented and deployed to some extent, the approach appears |
|
to have applicability limited to the CDCIE.</p> |
|
</section2> |
|
<section2 topic="Encapsulated Digitial Signatures in XMPP" anchor="xmpp-ed-dsig"> |
|
<p>The &xep0290; (XMPP DSIG) is an encapsulated signature proposal similar to that |
|
signed manifest approach suggested below. This approach is intended to support a wide range of |
|
uses and applications including <em>optimistic signing</em> in general communciations.</p> |
|
<p>Unlike CDCIE-CCP approach, XMPP DSIG signatures are not "enveloped" signatures over the |
|
whole stanza but signatures over an object which details the stanza contents.</p> |
|
</section2> |
|
</section1> |
|
|
|
<section1 topic="Protocol Design Discussion" anchor="design"> |
|
<section2 topic="Encapsulated v. Encapsulating Signatures" anchor="encap"> |
|
<p>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 and |
|
XMPP PGP are examples of the former. CDCIE-CCP and XMPP DSIG are examples of the latter.</p> |
|
|
|
<p>The following example illustrates, using pseudo language, an encapsulating signature over a |
|
&MESSAGE; stanza.</p> |
|
<example caption="Encapsulating Signature"><![CDATA[ |
|
<encapslating-signature> |
|
<signedInfo> |
|
<message to='romeo@example.net' type='chat'> |
|
<body>Art thou not Romeo, and a Montague?</body> |
|
</message> |
|
</signedInfo> |
|
<signature-over-signedInfo/> |
|
</encapslating-signature> |
|
]]></example> |
|
|
|
<p>To transfer a signed &MESSAGE; using an encapsulating signature, one needs to send it |
|
within &MESSAGE; stanza. </p> |
|
<example caption="Transfer of an Encapsulating Signature"><![CDATA[ |
|
<message to='romeo@example.net' type='chat'> |
|
<encapslating-signature> |
|
<signedInfo> |
|
<message to='romeo@example.net' type='chat'> |
|
<body>Art thou not Romeo, and a Montague?</body> |
|
</message> |
|
</signedInfo> |
|
<signature-over-signedInfo/> |
|
</encapslating-signature> |
|
</message> |
|
]]></example> |
|
<p>The following example illustrates, using pseudo language, an encapsulated signature over a |
|
&MESSAGE; stanza. </p> |
|
<example caption="Encapsulated Signature"><![CDATA[ |
|
<message to='romeo@example.net' type='chat'> |
|
<body>Art thou not Romeo, and a Montague?</body> |
|
<encapsulated-signature> |
|
<signature-over-message/> |
|
</encapsulated-signature> |
|
</message> |
|
]]></example> |
|
<p>Applicability of a simple (non-nesting) encapsulating signatures, such as in XMPP E2E and |
|
XMPP PGP, 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.</p> |
|
<p>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.</p> |
|
<example caption="MUC submission with Encapsulating Signature"><![CDATA[ |
|
<message from='hag66@shakespeare.lit/pda' to='darkcave@chat.shakespeare.lit' |
|
type='groupchat' xml:lang='en'> |
|
<encapslating-signature> |
|
<signed-info> |
|
<message |
|
to='darkcave@chat.shakespeare.lit' |
|
type='groupchat' |
|
xml:lang='en'> |
|
<body>Harpier cries: 'tis time, 'tis time.</body> |
|
</message> |
|
</signed-info> |
|
<signature-value>...</signature-value> |
|
</encapslating-signature> |
|
</message> |
|
]]></example> |
|
<p>The following examples illustrates the signed reflection of the above stanza.</p> |
|
<example caption="MUC reflection with Encapsulating Signature"><![CDATA[ |
|
<message from='darkcave@chat.shakespeare.lit/thirdwitch' |
|
to='crone1@shakespeare.lit/desktop' type='groupchat' xml:lang='en'> |
|
<encapslating-signature> |
|
<signed-info> |
|
<message |
|
from='darkcave@chat.shakespeare.lit/thirdwitch' |
|
to='crone1@shakespeare.lit/desktop' type='groupchat' xml:lang='en'> |
|
<body>Harpier cries: 'tis time, 'tis time.</body> |
|
</message> |
|
<derived-from> |
|
<message from='hag66@shakespeare.lit/pda' |
|
to='darkcave@chat.shakespeare.lit' type='groupchat' xml:lang='en'> |
|
<encapslating-signature> |
|
<signedInfo> |
|
<message to='darkcave@chat.shakespeare.lit' |
|
type='groupchat' xml:lang='en'> |
|
<body>Harpier cries: 'tis time, 'tis time.</body> |
|
</message> |
|
</signedInfo> |
|
<signature/> |
|
</encapslating-signature> |
|
</message> |
|
</derived-from> |
|
</signed-info> |
|
<signature-value>...</signature-value> |
|
</encapslating-signature> |
|
</message> |
|
]]></example> |
|
<p>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 |
|
<link url="#stanza-siging">below</link>, encapsulated selective signatures are generally |
|
more applicable.</p> |
|
</section2> |
|
<section2 topic="Selective Signing" anchor="select"> |
|
<p>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.</p> |
|
<p>For instance, a client with the JID "juliet@example.com/Balcony" might send the following |
|
signed stanza:</p> |
|
<example caption="Signature over entire stanza"><![CDATA[ |
|
<message to='romeo@example.net' type='chat' xml:lang='en'> |
|
<subject>Love</subject> |
|
<body>Art thou not Romeo, and a Montague?</body> |
|
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> |
|
<SignedInfo> |
|
... |
|
<Reference URI=""> |
|
<Transforms> |
|
<Transform |
|
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> |
|
</Transforms> |
|
... |
|
</Reference> |
|
</SignedInfo> |
|
<SignatureValue>...</SignatureValue> |
|
... |
|
</Signature> |
|
</message> |
|
]]></example> |
|
<p>The example.com server is required, per &xmppcore;, 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.</p> |
|
|
|
<p>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. </p> |
|
</section2> |
|
|
|
<section2 topic="Replay attack protection" anchor="replay"> |
|
<p>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. </p> |
|
</section2> |
|
|
|
<section2 topic="Manifest Signing" anchor="manifest"> |
|
<p>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.</p> |
|
|
|
|
|
<p>Putting all of the above together, the client might send the following signed stanza:</p> |
|
<example caption="Client signed message"><![CDATA[ |
|
<message to='romeo@example.net' type='chat' xml:lang='en'> |
|
<subject id='X-subj'>Love</subject> |
|
<body id='X-body'>Art thou not Romeo, and a Montague?</body> |
|
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" Id="sig"> |
|
<SignedInfo> |
|
... |
|
<Reference URI="#X-manifest">...</Reference> |
|
</SignedInfo> |
|
<SignatureValue>...</SignatureValue> |
|
<Object> |
|
<Manifest id='X-manifest'> |
|
<Reference URI="#X-subj">...</Reference> |
|
<Reference URI="#X-body">...</Reference> |
|
<Reference URI="#X-xmppprop">...</Reference> |
|
<Reference URI="#X-sigprop">...</Reference> |
|
</Manifest> |
|
</Object> |
|
<Object> |
|
<XMPPproperties id='X-xmppprop'> |
|
<stanza>message</stanza> |
|
<type>chat</type> |
|
<from>juliet@example.com</from> |
|
<to>romeo@example.net</to> |
|
</XMPPproperties> |
|
</Object> |
|
<Object> |
|
<SignatureProperties id="X-sigprop" Target="#X-sig"> |
|
<SignatureProperty Target="#timestamp"> |
|
<timestamp>2009-08-03T13:33:00Z</timestamp> |
|
</SignatureProperty> |
|
</SignatureProperties> |
|
</Object> |
|
</Signature> |
|
</message> |
|
]]></example> |
|
</section2> |
|
<section2 topic="Unambigious identification of content" anchor="id"> |
|
<p>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.</p> |
|
|
|
<p>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.</p> |
|
|
|
<p>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. </p> |
|
|
|
<p>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.</p> |
|
</section2> |
|
|
|
<section2 topic="Multiple Signatures" anchor="multisig"> |
|
<p>Multiple entities can sign a stanza. A single entity may sign a stanza multiple times, |
|
typically on different occasions.</p> |
|
|
|
<p>Each signer simply adds their &SIGNATURE; element to the stanza, typically as the last |
|
element. A &SIGNATURE; may sign other signatures, or portions thereof.</p> |
|
|
|
<p>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.</p> |
|
</section2> |
|
<section2 topic="Optimistic Signing" anchor="optimistic"> |
|
<p>Some users design the ability to <em>optimistic signing</em> of stanzas. That is, to sign |
|
all stanzas adhere to a configured criteria, such as all &MESSAGE; stanzas, they send. A key |
|
aspect of optimistic signing is that receiving entities not supporting the signing extension |
|
should be able to make use the message content (excluding the signature information) while |
|
those receiving entities supporting the extension can make use of the message content and |
|
the signature information.</p> |
|
<p>Optimistic signing is available in E-mail through the use of S/MIME detached signatures. |
|
Use of S/MIME detached signatures can be problematic. Mail systems, especially restribution |
|
services such as mailing lists, are notorious for changing the signed content and hence |
|
breaking the signature.</p> |
|
<p>In XMPP, as stanzas are generally altered in transit and hence optimistic signing will be |
|
fragile at best. Through use of selective signing and manifesting, issues may be mitigated |
|
to some degree. It is doubtful that a solution exists that provides optimistic signing and |
|
reliability verification.</p> |
|
<section3 topic="Dual content" anchor="dual"> |
|
<p>One possible optimistic signing solution is for stanzas to carry <em>alternative</em> |
|
sets of content, an unsigned content alternative and a signed content alternative. The |
|
premise of this approach is that 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 approach has been suggested to as |
|
a mechanism for support extension-unaware entities downstream of extension-unware |
|
groupchat (or like) services use of the stanza content.</p> |
|
<p>The following example not only illustrate this approach, but highlights some of the |
|
issues with this approach:</p> |
|
<example caption="Dual content message"><![CDATA[ |
|
<message from='hag66@shakespeare.lit/pda' to='darkcave@chat.shakespeare.lit/laptop' |
|
type='groupchat' xml:lang='en'> |
|
<body>No.</body> |
|
<encapslating-signature> |
|
<signed-info> |
|
<message to='darkcave@chat.shakespeare.lit' type='groupchat' xml:lang='en'> |
|
<body>Yes.</body> |
|
</message> |
|
</signed-info> |
|
<signature-value>...</signature-value> |
|
</encapslating-signature> |
|
<delay xmlns='urn:xmpp:delay' |
|
from='shakespeare.lit' |
|
stamp='2002-09-10T23:08:25Z'/> |
|
</message> |
|
]]></example> |
|
<p>But it should be obvious that the signed and unsigned contents are not proper |
|
alternatives. The signed content presumedly is what the signer sent. The unsigned content |
|
is presumedly a modified version of what the signer sent. The modifications are generally |
|
important to the entity making use of the stanza. In the above example, note that the |
|
to/from addresses of the signed content differ from the unsigned content. Note as well |
|
that the unsigned content contains a >delay/< element indicating that the stanza was |
|
delayed in transit. Such modifications are generally important to the proper processing of |
|
the content by not only this entity, but entities to which the content might be forwarded |
|
to. Dual content, even in absence of attacks, simply complicates such processing. </p> |
|
<p>Note that the &BODY; element values differ between the signed and unsigned content. While |
|
it reasonable straight forward (though significant work) to determine that the signed and |
|
unsigned content differ, it is extermely difficult to to determine whether the changes are |
|
due to normal processing or an attack.</p> |
|
<p>Dual content adds significant blot. In simple cases, the approach effective doubles the |
|
content. However, in some use cases, the appraoch may lead to multiple doublings of the |
|
content.</p> |
|
<p>It must be noted that verifying entities downstream of a redistribution will need some |
|
mechanism to determine who signed the stanza, determine what signer is an appropriate |
|
signer, and to obtain the public key of that signer. While certain information can be |
|
placed in key data, the question of whether the signer is an appropriate signer for |
|
purported sender (e.g., a room subscriber) generally would require information from the |
|
redistribution service, and this would generally require the redistribution service to |
|
support an extension to make that information available to entities desiring to verify the |
|
signature(s). If one accepts the premise that downstream verification of redistributed |
|
stanzas, such as via a MUC service, cannot be performed without extension and cooperation |
|
of the redistribution service, then it follows that dual content can be avoided by having |
|
the MUC service also support the signing extension.</p> |
|
<p>Dual content approaches should be avoided.</p> |
|
</section3> |
|
</section2> |
|
<section2 topic="Key Info" anchor="key-info"> |
|
<p>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.</p> |
|
<p>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.</p> |
|
<p>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;.</p> |
|
</section2> |
|
</section1> |
|
|
|
<section1 topic="Security Considerations" anchor="seccon"> |
|
<p>Care must be taken in the design of not only ensure it provides an effective digital |
|
signature solution for XMPP, but is designed itself with security in mind. This section |
|
discussions some security issues in providing a digital signature solution. The design should |
|
consider a general digital signature issues as well issues specific to the technologies |
|
used/involved, and particulars of the solution.</p> |
|
<p>Due to the nature of XML and XMPP, an effective general digital signing solution for XMPP is |
|
likely to be quite complex. This document suggests nothing less. With complexity comes |
|
significant security risk. To minimize this risk, the solutions should avoid reinvention of |
|
needed technology, such as signature and key information syntaxes, by reusing well established |
|
and understood technologies such as XMLDSIG. Solutions should also favor simple and widely |
|
used features of such technologies over esoteric or rarely used features</p> |
|
<p>Designers of the solution should be mind full of security considerations discussed in XMLDSIG |
|
(regardless of whether XMLDSIG is used in the solution)</p> |
|
<p>If XMLDSIG is used, a number of security considerations would be introduced into the |
|
solution. Implementations need to take special care in processing XMLDSIG &SIGNATURE; elements |
|
to avoid a wide range of attacks. For instance, an attacker could attempt to mount a Denial of |
|
Service attack by sending a &SIGNATURE; purporting to sign arbitrary large and complex |
|
content. Or an attacker could attempt to mount a Distributed Denial of Service sending a |
|
message to a chatroom that containing &SIGNATURE; with multiple references to large content |
|
hosted at the attack target in hopes that each room participant will repeated fetch it. A |
|
&SIGNATURE; element might also contain circler references.</p> |
|
</section1> |
|
</xep>
|
|
|