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

xep-0274.xml 40KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645
  1. <?xml version='1.0' encoding='UTF-8'?>
  2. <!DOCTYPE xep SYSTEM 'xep.dtd' [
  3. <!ENTITY % ents SYSTEM 'xep.ent'>
  4. %ents;
  5. <!ENTITY SIGNATURE "&lt;Signature/&gt;">
  6. <!ENTITY REFERENCE "&lt;Reference/&gt;">
  7. <!ENTITY SIGNEDINFO "&lt;SignedInfo/&gt;">
  8. <!ENTITY KEYINFO "&lt;KeyInfo/&gt;">
  9. <!ENTITY SIGNATUREPROPERTIES "&lt;SignatureProperties/&gt;">
  10. <!ENTITY MANIFEST "&lt;Manifest/&gt;">
  11. <!ENTITY XMPPprop "&lt;XMPPproperties/&gt;">
  12. <!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) &lt;<link url='http://tools.ietf.org/html/rfc3851'>http://tools.ietf.org/html/rfc3851</link>&gt;.</note>" >
  13. <!ENTITY CMS "<span class='ref'><link url='http://tools.ietf.org/html/rfc3852'>CMS</link></span> <note>RFC 3852: Cryptographic Message Syntax (CMS) &lt;<link url='http://tools.ietf.org/html/rfc3852'>http://tools.ietf.org/html/rfc3852</link>&gt;.</note>" >
  14. <!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 &lt;<link url='http://www.jfcom.mil/about/facts_prt/MNIS.pdf'>http://www.jfcom.mil/about/facts_prt/MNIS.pdf</link>&gt;.</note>" >
  15. <!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>" >
  16. <!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 &lt;<link url='http://www.w3.org/TR/xmldsig-core/'>http://www.w3.org/TR/xmldsig-core/</link>&gt;.</note>" >
  17. <!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 &lt;<link url='http://www.w3.org/TR/xptr'>http://www.w3.org/TR/xptr</link>&gt;.</note>" >
  18. ]>
  19. <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
  20. <xep>
  21. <header>
  22. <title>Design Considerations for Digital Signatures in XMPP</title>
  23. <abstract>This document discusses considerations for the design of Digital Signatures in XMPP,
  24. including use cases and requirements. The document also discusses various ways XML Digital
  25. Signatures could be used in XMPP.</abstract> &LEGALNOTICE; <number>0274</number>
  26. <status>Deferred</status>
  27. <type>Informational</type>
  28. <sig>Standards</sig>
  29. <approver>Council</approver>
  30. <dependencies>
  31. <spec>XMPP Core</spec>
  32. <spec>XEP-0001</spec>
  33. </dependencies>
  34. <supersedes/>
  35. <supersededby/>
  36. <shortname>N/A</shortname>
  37. &kdz;
  38. <revision>
  39. <version>0.4</version>
  40. <date>2011-01-28</date>
  41. <initials>kdz</initials>
  42. <remark>
  43. <p>Update/fix references.</p>
  44. </remark>
  45. </revision>
  46. <revision>
  47. <version>0.3</version>
  48. <date>2011-01-12</date>
  49. <initials>kdz</initials>
  50. <remark>
  51. <p>Update discussions based upon introduction of Encapsulated Digital Signatures in XMPP, an
  52. alternative to XEP-0285.</p>
  53. </remark>
  54. </revision>
  55. <revision>
  56. <version>0.2</version>
  57. <date>2010-09-29</date>
  58. <initials>kdz</initials>
  59. <remark>
  60. <p>Update discussions based upon introduction of Digital Signatures in XMPP.</p>
  61. </remark>
  62. </revision>
  63. <revision>
  64. <version>0.1</version>
  65. <date>2009-09-15</date>
  66. <initials>psa</initials>
  67. <remark>
  68. <p>Initial published version as accepted for publication by the XMPP Council.</p>
  69. </remark>
  70. </revision>
  71. <revision>
  72. <version>0.0.1</version>
  73. <date>2009-08-20</date>
  74. <initials>kdz</initials>
  75. <remark>
  76. <p>Proto-XEP draft.</p>
  77. </remark>
  78. </revision>
  79. </header>
  80. <section1 topic="Introduction" anchor="intro">
  81. <p>Digital signatures may be used to provide a number of security services, including message
  82. authentication, message integrity and non-repudiation. There are many use cases for Digital
  83. Signatures in the Extensible Messaging and Presence Protocol (&xmpp;).</p>
  84. <p>XMPP can be described as a mean for exchanging structured information or stanzas between two
  85. or more entities. To accomplish this exchange, a number of other entities may be involved. For
  86. instance, communication of a stanza between two client entities will typically involve one or
  87. more server entities. Entities may exchange stanzas through service entities, such as a chat
  88. room service, to effect one-to-many communications.</p>
  89. <p>Any entity involved in the exchange of a stanza may have wish to include one or more digital
  90. signatures for the benefit of any entity involved in the exchange:</p>
  91. <ul>
  92. <li>A client might wish to sign information it exchanges with another client for the benefit
  93. of this client (e.g, to provide message origin authentication service and content integrity
  94. service)</li>
  95. <li>A client might wish to sign a message in order to bind a Security Label to that
  96. message.</li>
  97. <li>A client may wish to sign information it sends to a chat room for the benefit of the chat
  98. room service and/or for the benefit of room occupants.</li>
  99. <li>The chat room service may wish to sign information it forwards to room occupants for the
  100. benefit of room occupants, such as to bind the client's JID to the client's room JID.</li>
  101. <li>A server involved in the exchange of a stanza between two clients may wish to sign
  102. information for the benefit of another server involved in the exchange (e.g., to provide
  103. delivery path validation).</li>
  104. <li>A server may wish to add additional data to a message, for example a Security Label, and
  105. bind that data to the message with a digital signature.</li>
  106. </ul>
  107. <p>Digital signatures are provided to serve specific purposes. These purposes might include
  108. authentication of a particular entity involved in the exchange and integrity of information
  109. that entity provided.</p>
  110. <p>This document discusses <link url="#design">considerations for the design</link> of
  111. general-purpose digital signature extension for XMPP. The document discusses <link url="#uses"
  112. >use cases</link> and <link url="#requires">requirements</link>, as well as explores the
  113. solution space. The document also discusses <link url="#existing">existing solutions</link> in
  114. this area.</p>
  115. <p>This document contains a numerous examples intended to aide in the discussion of design
  116. issues. The examples are examples generally abbreviated and often use informal syntaxes.</p>
  117. </section1>
  118. <section1 topic="Use Cases" anchor="uses">
  119. <section2 topic="Use in directed one-to-one stanzas" anchor="direct-1to1-use">
  120. <p>Directed one-to-one stanzas are stanzas which are exchanged between two entities, the
  121. originator of the stanza and intended recipient of that stanza, without exchanging through
  122. services which provide re-direction of stanzas (such as a groupchat service). The stanza may
  123. be handled by one or more other entities.</p>
  124. <p>Examples of directed one-to-one stanzas include chat &MESSAGE; used in one-to-one chat
  125. sessions and &IQ; stanzas (excepting those exchanged through services providing <link
  126. url="redirect-1to1-use">re-direction</link>).</p>
  127. <p>The originator may wish to provide a signature for the benefit of the intended recipient.
  128. The intended recipient could use this signature to authenticate the originator and to ensure
  129. integrity of originator provided information.</p>
  130. <p>Entities handling the stanza may wish to provide a signature for the benefit of the
  131. intended recipient. For instance, where a originator is a client and does not provide a
  132. signature, the client's server may wish to provide a signature for the benefit of the
  133. intended recipient. The intended recipient could use this signature to authenticate this
  134. server and to ensure integrity of the information as forwarded by this server. </p>
  135. </section2>
  136. <section2 topic="Use in redirected one-to-one stanzas" anchor="redirect-1to1-use">
  137. <p>Redirected one-to-one stanzas which are exchanged between two entities, the originator of
  138. the stanza and intended recipient of that stanza, through a service which provides
  139. re-direction of stanzas. The stanza may be handled by one or more other entities. </p>
  140. <p>A multi-user chat (MUC) 'private message' is an example of redirected one-to-one
  141. stanza.</p>
  142. <p>The originator's server may wish to provide a signature for the benefit of the re-direction
  143. service. The service could use this signature to authenticate the originator and to ensure
  144. integrity of originator provided information.</p>
  145. <p>The originator may wish to provide a signature for the benefit of the intended recipient.
  146. The intended recipient could use this signature to authenticate the originator and to ensure
  147. integrity of originator provided information. However, this signature would by itself not
  148. establish any relationship between the signer and 'from' address in the stanza as received,
  149. nor does it establish this signature establish that the stanza was processed by the
  150. re-direction service. As in the <link url="#direct-1to1-use">directed one-to-one
  151. stanza</link>, a originating client's server may wish to provide a signature for the
  152. benefit of the intended recipient.</p>
  153. <p>The re-direction service may wish to provide a signature for the benefit of the intended
  154. recipient. The intended recipient could use this signature to authenticate the service and
  155. hence establish the service processed the stanza. The intended recipient could also use the
  156. signature to ensure the integrity of the information as redirected by the service.</p>
  157. </section2>
  158. <section2 topic="Use in redirected one-to-group stanzas" anchor="redirect-1toG-use">
  159. <p>Redirected one-to-many stanzas which are exchanged between two or more entities, the
  160. originator of the stanza and a group of recipients, through a service which provides
  161. re-direction of stanzas of a single stanza to a set of recipients. The stanza may be handled
  162. by one or more other entities. </p>
  163. <p>A multi-user chat (MUC) message to all occupants is an example of redirected one-to-group
  164. stanza.</p>
  165. <p>The originator's server may wish to provide a signature for the benefit of the re-direction
  166. service. The service could use this signature to authenticate the originator and to ensure
  167. integrity of originator provided information.</p>
  168. <p>The originator may wish to provide a signature for the benefit of each recipient in the
  169. group. Each recipient could use this signature to authenticate the originator and to ensure
  170. integrity of originator provided information. However, this signature would by itself not
  171. establish any relationship between the signer and the 'from' address in the stanza as
  172. received, nor does it establish this signature establish that the stanza was processed by
  173. the re-direction service. As in the <link url="#direct-1to1-use">directed one-to-one
  174. stanza</link>, a originating client's server may wish to provide a signature for the
  175. benefit of the each recipient.</p>
  176. <p>The re-direction service may wish to provide a signature for the benefit of each recipient
  177. in the group. Each recipient could use this signature to authenticate the service and hence
  178. establish the service processed the stanza. Each could also use the signature to ensure the
  179. integrity of the information as redirected by the service.</p>
  180. </section2>
  181. <section2 topic="Use in presence stanzas" anchor="presence-use">
  182. <p>The presence can be viewed as a specialized "publish-subscribe" mechanism. Commonly the
  183. publishing entity sends a &PRESENCE; stanza to a presence service and the presence service
  184. than forwards the stanza to each subscriber. In basic user presence, the publishing entity
  185. is the user's client and the presence service is presence service is the provided by this
  186. client's server. In this case, the 'to' address is empty.</p>
  187. <p>The publisher may wish to sign the signature for the benefit of each subscriber. Each
  188. subscriber could use this signature to authenticate the publisher and to ensure integrity of
  189. publisher provided information.</p>
  190. <p>The presence service may wish to provide a signature for the benefit of each subscriber.
  191. Each subscriber could use this signature to authenticate the service and hence establish the
  192. service processed the stanza. Each could also use the signature to ensure the integrity of
  193. the information as redirected by the service.</p>
  194. <p>A presence stanza may also directed to another entity, possibly through a re-direction
  195. service. This use is similar to the <link url="#direct-1to1-use">directed one-to-one</link>
  196. and <link url="#redirect-1to1-use">redirected one-to-one</link> cases detailed above.</p>
  197. </section2>
  198. </section1>
  199. <section1 topic="General Requirements" anchor="requires">
  200. <p>For the purposes of this memo, the following requirements are stipulated for a general
  201. solution: </p>
  202. <ol start="1">
  203. <li>The extension shall support client signing of stanzas.</li>
  204. <li>The extension shall support service (e.g., multi-user chat service) signing of
  205. stanzas.</li>
  206. <li>The extension shall support server signing stanzas.</li>
  207. <li>The extension shall support multiple signatures in a stanza. That is, multiple entities
  208. can sign a stanza.</li>
  209. <li>The extension shall support signing of &IQ; stanzas.</li>
  210. <li>The extension shall support signing of &MESSAGE; stanzas, including chat and
  211. groupchat.</li>
  212. <li>The extension shall support signing of &PRESENCE; stanzas.</li>
  213. <li>The extension shall support selective signing of stanzas. That is, a signer can sign
  214. select portions of a stanza.</li>
  215. <li>The extension shall support signing of externally referenced object. That is, the
  216. signature may include a message digest of an external object, such as an HTTP accessible
  217. content.</li>
  218. <li>The extension shall allow selective verification of signed elements. </li>
  219. <li>The extension shall allow independent handling of verification errors in signed
  220. content.</li>
  221. <li>The extension shall allow signers to provide signed copies of data likely to be modified
  222. by intermediate entities, such as stanza 'to' and 'from' attributes.</li>
  223. <li>The extension should avoid duplication of content.</li>
  224. <li>The extension must provide a means for relating signed content with unsigned content.</li>
  225. <li>The extension should support querying for key information in XMPP (e.g., &IQ;).</li>
  226. <li>The extension should support communicating key information through their XMPP-published
  227. vCard.</li>
  228. <li>The extension should be designed such that the successful verification of a signature is
  229. independent of the extension support in entities involved in the exchange.</li>
  230. <li>The extension should be compatible with object encryption, supporting encryption of signed
  231. content, signing of encrypted content, and signing of encrypted signed content (e.g., triple
  232. wrap content).</li>
  233. </ol>
  234. <p>Some of above requirements may well be, if not outright mutually exclusive, in opposition to
  235. each other. It is suspected that set of reasonable solutions meeting all of the above
  236. requirements may be empty. To produce a reasonable solution, it is expected that some of the
  237. above requirements be eliminated and hence limiting the solution to some subset of the
  238. applications of digital signatures in XMPP.</p>
  239. </section1>
  240. <section1 topic="Existing Solutions" anchor="existing">
  241. <section2 topic="XMPP E2E" anchor="xmpp-e2e">
  242. <p>The &IETF; standardized a signing and encryption facility for XMPP known as &xmppe2e;. XMPP
  243. E2E is based upon Secure/Multipurpose Internet Message Extensions (&SMIME;) and the
  244. Cryptographic Message Syntax (&CMS;). As it's name implies, XMPP E2E is intended to be an
  245. end-to-end solution. That is, it enables a sender to sign content sent to a specific
  246. recipient.</p>
  247. <p>An advantage of the XMPP E2E approach is that it uses an encapsulating signature which
  248. protects the signed content from alteration as it is exchanged over an XMPP network. A
  249. disadvantage is that implementations which do not support XMPP E2E cannot make use of the
  250. signed content.</p>
  251. <p>At the time of this writing, XMPP E2E has not been widely implemented. XMPP E2E appears to
  252. have limited applicability. </p>
  253. </section2>
  254. <section2 topic="PGP signatures in XMPP" anchor="xmpp-e2e">
  255. <p>The &xep0027; (XMPP PGP), like the XMPP E2E, uses an encapsulating signature to protects
  256. the signed content from alteration as it is exchanged over an XMPP network. Like XMPP E2E,
  257. it is intended to be an end-to-end solution.</p>
  258. <p>At the time of this writing, XMPP PGP has not been widely implemented (though some
  259. implementations do exist). XMPP PGP appears to have limited applicability.</p>
  260. </section2>
  261. <section2 topic="Encapsulating Digital Signatures in XMPP" anchor="xmpp-e2e">
  262. <p>The &xep0285; (XMPP EgDSIG), like the XMPP E2E and XMPP PGP, uses an encapsulating
  263. signature to protects the signed content from alteration as it is exchanged over an XMPP
  264. network.</p>
  265. <p>Unlike XMPP E2E and XMPP PGP, the solution is not intended to be strictly end-to-end in
  266. that multiple signers and verifiers where contemplated, now of which is necessarily an end
  267. entity. However, like XMPP E2E, it does not supported <em>optimistic signing</em>.</p>
  268. </section2>
  269. <section2 topic="CDCIE-CCP" anchor="cdcie-ccp">
  270. <p>Alternative approaches have been developed. For instance, the Cross Domain Collaborative
  271. Information Environment (&CDCIE;) Client Chat Protocol (&CDCIE-CCP;), an XMPP-based
  272. protocol, supports signing of XMPP stanzas utilizes XML digital signatures (&XMLDSIG;)
  273. "enveloped" signatures over the whole stanza.</p>
  274. <p>An advantage of the CDCIE-CCP approach is that, because it uses an encapsulated signature,
  275. implementations need not support CDCIE-CPP to make use of the stanza. The disadvantage is
  276. that the signature always over the entire stanza. Alteration of the stanza, as is common
  277. (often required) when exchanging stanzas over an XMPP network, will invalidate the
  278. signature.</p>
  279. <p>While this approach has been implemented and deployed to some extent, the approach appears
  280. to have applicability limited to the CDCIE.</p>
  281. </section2>
  282. <section2 topic="Encapsulated Digitial Signatures in XMPP" anchor="xmpp-ed-dsig">
  283. <p>The &xep0290; (XMPP DSIG) is an encapsulated signature proposal similar to that
  284. signed manifest approach suggested below. This approach is intended to support a wide range of
  285. uses and applications including <em>optimistic signing</em> in general communciations.</p>
  286. <p>Unlike CDCIE-CCP approach, XMPP DSIG signatures are not "enveloped" signatures over the
  287. whole stanza but signatures over an object which details the stanza contents.</p>
  288. </section2>
  289. </section1>
  290. <section1 topic="Protocol Design Discussion" anchor="design">
  291. <section2 topic="Encapsulated v. Encapsulating Signatures" anchor="encap">
  292. <p>An encapsulating signature is a signature approach that encapsulates the signed content
  293. within the signature syntax. An encapsulated signature is a signature approach where the
  294. signature syntax in encapsulated within the structure of the signed content. XMPP E2E and
  295. XMPP PGP are examples of the former. CDCIE-CCP and XMPP DSIG are examples of the latter.</p>
  296. <p>The following example illustrates, using pseudo language, an encapsulating signature over a
  297. &MESSAGE; stanza.</p>
  298. <example caption="Encapsulating Signature"><![CDATA[
  299. <encapslating-signature>
  300. <signedInfo>
  301. <message to='romeo@example.net' type='chat'>
  302. <body>Art thou not Romeo, and a Montague?</body>
  303. </message>
  304. </signedInfo>
  305. <signature-over-signedInfo/>
  306. </encapslating-signature>
  307. ]]></example>
  308. <p>To transfer a signed &MESSAGE; using an encapsulating signature, one needs to send it
  309. within &MESSAGE; stanza. </p>
  310. <example caption="Transfer of an Encapsulating Signature"><![CDATA[
  311. <message to='romeo@example.net' type='chat'>
  312. <encapslating-signature>
  313. <signedInfo>
  314. <message to='romeo@example.net' type='chat'>
  315. <body>Art thou not Romeo, and a Montague?</body>
  316. </message>
  317. </signedInfo>
  318. <signature-over-signedInfo/>
  319. </encapslating-signature>
  320. </message>
  321. ]]></example>
  322. <p>The following example illustrates, using pseudo language, an encapsulated signature over a
  323. &MESSAGE; stanza. </p>
  324. <example caption="Encapsulated Signature"><![CDATA[
  325. <message to='romeo@example.net' type='chat'>
  326. <body>Art thou not Romeo, and a Montague?</body>
  327. <encapsulated-signature>
  328. <signature-over-message/>
  329. </encapsulated-signature>
  330. </message>
  331. ]]></example>
  332. <p>Applicability of a simple (non-nesting) encapsulating signatures, such as in XMPP E2E and
  333. XMPP PGP, are generally limited to end-to-end use cases. That is, cases where the originator
  334. of a stanza signs the stanza and send it through the XMPP network to its intended recipient,
  335. and only the intended recipient is expected to make use of the signed content. Entities
  336. between the signer and the intended recipient are expected to forward of the stanza without
  337. regard to the encapsulating signature, and without themselves signing the stanza. The
  338. approach does not require forwarding entities to support the signing extension.</p>
  339. <p>Simple encapsulating signatures have limited applicability in MUC and PubSub use cases. For
  340. instance, an occupant can sign its submissions to the service for the benefit of the service
  341. and the service can sign reflected stanzas to occupants. In providing non-anonymous chat
  342. rooms, in addition to signing the reflected content, the service should include and sign the
  343. stanza it received when it was signed. This allows the occupants verify the content the
  344. service purports to have received, and to determine whether the reflected content is
  345. consistent given this. The following example illustrates an encapsulating signature over a
  346. groupchat &MESSAGE; stanza.</p>
  347. <example caption="MUC submission with Encapsulating Signature"><![CDATA[
  348. <message from='hag66@shakespeare.lit/pda' to='darkcave@chat.shakespeare.lit'
  349. type='groupchat' xml:lang='en'>
  350. <encapslating-signature>
  351. <signed-info>
  352. <message
  353. to='darkcave@chat.shakespeare.lit'
  354. type='groupchat'
  355. xml:lang='en'>
  356. <body>Harpier cries: 'tis time, 'tis time.</body>
  357. </message>
  358. </signed-info>
  359. <signature-value>...</signature-value>
  360. </encapslating-signature>
  361. </message>
  362. ]]></example>
  363. <p>The following examples illustrates the signed reflection of the above stanza.</p>
  364. <example caption="MUC reflection with Encapsulating Signature"><![CDATA[
  365. <message from='darkcave@chat.shakespeare.lit/thirdwitch'
  366. to='crone1@shakespeare.lit/desktop' type='groupchat' xml:lang='en'>
  367. <encapslating-signature>
  368. <signed-info>
  369. <message
  370. from='darkcave@chat.shakespeare.lit/thirdwitch'
  371. to='crone1@shakespeare.lit/desktop' type='groupchat' xml:lang='en'>
  372. <body>Harpier cries: 'tis time, 'tis time.</body>
  373. </message>
  374. <derived-from>
  375. <message from='hag66@shakespeare.lit/pda'
  376. to='darkcave@chat.shakespeare.lit' type='groupchat' xml:lang='en'>
  377. <encapslating-signature>
  378. <signedInfo>
  379. <message to='darkcave@chat.shakespeare.lit'
  380. type='groupchat' xml:lang='en'>
  381. <body>Harpier cries: 'tis time, 'tis time.</body>
  382. </message>
  383. </signedInfo>
  384. <signature/>
  385. </encapslating-signature>
  386. </message>
  387. </derived-from>
  388. </signed-info>
  389. <signature-value>...</signature-value>
  390. </encapslating-signature>
  391. </message>
  392. ]]></example>
  393. <p>In encapsulated signature solutions, as in CDCIE-CCP, any entities can make use of the
  394. signed content even if they do not support the signing extension. If the signature is over
  395. the entire stanza, as in CDCIE-CCP, the signature is likely not to be valid when the stanza
  396. is passed through multiple entities prior to verification. Hence, when the signature is over
  397. the entire stanza, the encapsulating signature approach applicability is generally limited
  398. to cases where there no entities between the signer and verifier. However, as discussed
  399. <link url="#stanza-siging">below</link>, encapsulated selective signatures are generally
  400. more applicable.</p>
  401. </section2>
  402. <section2 topic="Selective Signing" anchor="select">
  403. <p>While an entity could provide a signature to be over the entire stanza, such signatures are
  404. likely be invalidated as the stanza exchanged over the XMPP. This is because XMPP allows
  405. and, in many cases, requires stanza to be modified as they are forwarded.</p>
  406. <p>For instance, a client with the JID "juliet@example.com/Balcony" might send the following
  407. signed stanza:</p>
  408. <example caption="Signature over entire stanza"><![CDATA[
  409. <message to='romeo@example.net' type='chat' xml:lang='en'>
  410. <subject>Love</subject>
  411. <body>Art thou not Romeo, and a Montague?</body>
  412. <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  413. <SignedInfo>
  414. ...
  415. <Reference URI="">
  416. <Transforms>
  417. <Transform
  418. Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
  419. </Transforms>
  420. ...
  421. </Reference>
  422. </SignedInfo>
  423. <SignatureValue>...</SignatureValue>
  424. ...
  425. </Signature>
  426. </message>
  427. ]]></example>
  428. <p>The example.com server is required, per &xmppcore;, to add a 'from' attribute to the
  429. &MESSAGE; element before forwarding it to the example.net server. The example.net server is
  430. required to replace the 'to' attribute with the full JID of the romeo@example.net client it
  431. intends to forward the message to. These alternatations will "break" the signature.</p>
  432. <p>XMLDSIG provides for a facility to selective sign XML content. For instance, the client
  433. could sign the &SUBJECT; and &BODY; element and their content. However, this by itself would
  434. not cover key aspects of the stanza, such that it was a chat &MESSAGE; addressed to a
  435. particular JID and sent from a particular JID. XMLDSIG allows for enveloping signatures,
  436. that is a signature that signs a data object contained within the &SIGNATURE; element. The
  437. solution could define an element, such as &XMPPprop; used below, for including properties of
  438. the stanza in the signature. </p>
  439. </section2>
  440. <section2 topic="Replay attack protection" anchor="replay">
  441. <p>The signature in Example 1 does not provide any protection against replay attack. To
  442. address replay attack, as well as other concerns, XMLDSIG defines the &SIGNATUREPROPERTIES;
  443. element for including information items about the generation of the Signature, such as the
  444. date/time the signature was generated. </p>
  445. </section2>
  446. <section2 topic="Manifest Signing" anchor="manifest">
  447. <p>While one could have &SIGNATURE; which included a &REFERENCE; element for each of four
  448. elements discussed above within its &SIGNEDINFO; element, this would require reference
  449. validation for each &REFERENCE; (See 2.3 of XMLDSIG). To provide greater flexibility over
  450. handling of absent references and broken digest values, a &MANIFEST; can be constructed and
  451. only it signed.</p>
  452. <p>Putting all of the above together, the client might send the following signed stanza:</p>
  453. <example caption="Client signed message"><![CDATA[
  454. <message to='romeo@example.net' type='chat' xml:lang='en'>
  455. <subject id='X-subj'>Love</subject>
  456. <body id='X-body'>Art thou not Romeo, and a Montague?</body>
  457. <Signature xmlns="http://www.w3.org/2000/09/xmldsig#" Id="sig">
  458. <SignedInfo>
  459. ...
  460. <Reference URI="#X-manifest">...</Reference>
  461. </SignedInfo>
  462. <SignatureValue>...</SignatureValue>
  463. <Object>
  464. <Manifest id='X-manifest'>
  465. <Reference URI="#X-subj">...</Reference>
  466. <Reference URI="#X-body">...</Reference>
  467. <Reference URI="#X-xmppprop">...</Reference>
  468. <Reference URI="#X-sigprop">...</Reference>
  469. </Manifest>
  470. </Object>
  471. <Object>
  472. <XMPPproperties id='X-xmppprop'>
  473. <stanza>message</stanza>
  474. <type>chat</type>
  475. <from>juliet@example.com</from>
  476. <to>romeo@example.net</to>
  477. </XMPPproperties>
  478. </Object>
  479. <Object>
  480. <SignatureProperties id="X-sigprop" Target="#X-sig">
  481. <SignatureProperty Target="#timestamp">
  482. <timestamp>2009-08-03T13:33:00Z</timestamp>
  483. </SignatureProperty>
  484. </SignatureProperties>
  485. </Object>
  486. </Signature>
  487. </message>
  488. ]]></example>
  489. </section2>
  490. <section2 topic="Unambigious identification of content" anchor="id">
  491. <p>The signature references needs to unambiguously identify content in stanza even in face of
  492. subsequent modification of that stanza. Failure to unambiguously identify signed content
  493. would also be problematic.</p>
  494. <p>In the above example, signed child elements of the stanza were identified by 'id'
  495. attribute. As stanzas may be forwarded into any XMPP stream, such identifiers needs to
  496. remain unique.</p>
  497. <p>Use of an extension attribute to identify elements may be problematic. In particular, the
  498. XMPP specifications provide no assurance that this attribute would be forwarded with
  499. element. While one could identify signed content by other means, such as &XPointer;, these
  500. means would not unambiguously identify the signed content in the face of subsequent stanza
  501. modification. </p>
  502. <p>The an 'id' attribute is could be used (or possibly 'xml:id'), it may be appropriate for
  503. the XMPP entity inserting a child element into a stanza to provide an 'xml:id' attribute
  504. regardless of what stanza content it might sign.</p>
  505. </section2>
  506. <section2 topic="Multiple Signatures" anchor="multisig">
  507. <p>Multiple entities can sign a stanza. A single entity may sign a stanza multiple times,
  508. typically on different occasions.</p>
  509. <p>Each signer simply adds their &SIGNATURE; element to the stanza, typically as the last
  510. element. A &SIGNATURE; may sign other signatures, or portions thereof.</p>
  511. <p>While a simple chat &MESSAGE; typically transits through only one or two XMPP servers and a
  512. groupchat &MESSAGE; may typically transits one to three XMPP servers, a stanza might include
  513. far more than four &SIGNATURE; elements.</p>
  514. </section2>
  515. <section2 topic="Optimistic Signing" anchor="optimistic">
  516. <p>Some users design the ability to <em>optimistic signing</em> of stanzas. That is, to sign
  517. all stanzas adhere to a configured criteria, such as all &MESSAGE; stanzas, they send. A key
  518. aspect of optimistic signing is that receiving entities not supporting the signing extension
  519. should be able to make use the message content (excluding the signature information) while
  520. those receiving entities supporting the extension can make use of the message content and
  521. the signature information.</p>
  522. <p>Optimistic signing is available in E-mail through the use of S/MIME detached signatures.
  523. Use of S/MIME detached signatures can be problematic. Mail systems, especially restribution
  524. services such as mailing lists, are notorious for changing the signed content and hence
  525. breaking the signature.</p>
  526. <p>In XMPP, as stanzas are generally altered in transit and hence optimistic signing will be
  527. fragile at best. Through use of selective signing and manifesting, issues may be mitigated
  528. to some degree. It is doubtful that a solution exists that provides optimistic signing and
  529. reliability verification.</p>
  530. <section3 topic="Dual content" anchor="dual">
  531. <p>One possible optimistic signing solution is for stanzas to carry <em>alternative</em>
  532. sets of content, an unsigned content alternative and a signed content alternative. The
  533. premise of this approach is that an entity supporting the signing extension could make use
  534. of the signed content alternative while an entity not supporting the signing extension
  535. could make use of the unsigned content alternative. The approach has been suggested to as
  536. a mechanism for support extension-unaware entities downstream of extension-unware
  537. groupchat (or like) services use of the stanza content.</p>
  538. <p>The following example not only illustrate this approach, but highlights some of the
  539. issues with this approach:</p>
  540. <example caption="Dual content message"><![CDATA[
  541. <message from='hag66@shakespeare.lit/pda' to='darkcave@chat.shakespeare.lit/laptop'
  542. type='groupchat' xml:lang='en'>
  543. <body>No.</body>
  544. <encapslating-signature>
  545. <signed-info>
  546. <message to='darkcave@chat.shakespeare.lit' type='groupchat' xml:lang='en'>
  547. <body>Yes.</body>
  548. </message>
  549. </signed-info>
  550. <signature-value>...</signature-value>
  551. </encapslating-signature>
  552. <delay xmlns='urn:xmpp:delay'
  553. from='shakespeare.lit'
  554. stamp='2002-09-10T23:08:25Z'/>
  555. </message>
  556. ]]></example>
  557. <p>But it should be obvious that the signed and unsigned contents are not proper
  558. alternatives. The signed content presumedly is what the signer sent. The unsigned content
  559. is presumedly a modified version of what the signer sent. The modifications are generally
  560. important to the entity making use of the stanza. In the above example, note that the
  561. to/from addresses of the signed content differ from the unsigned content. Note as well
  562. that the unsigned content contains a &gt;delay/&lt; element indicating that the stanza was
  563. delayed in transit. Such modifications are generally important to the proper processing of
  564. the content by not only this entity, but entities to which the content might be forwarded
  565. to. Dual content, even in absence of attacks, simply complicates such processing. </p>
  566. <p>Note that the &BODY; element values differ between the signed and unsigned content. While
  567. it reasonable straight forward (though significant work) to determine that the signed and
  568. unsigned content differ, it is extermely difficult to to determine whether the changes are
  569. due to normal processing or an attack.</p>
  570. <p>Dual content adds significant blot. In simple cases, the approach effective doubles the
  571. content. However, in some use cases, the appraoch may lead to multiple doublings of the
  572. content.</p>
  573. <p>It must be noted that verifying entities downstream of a redistribution will need some
  574. mechanism to determine who signed the stanza, determine what signer is an appropriate
  575. signer, and to obtain the public key of that signer. While certain information can be
  576. placed in key data, the question of whether the signer is an appropriate signer for
  577. purported sender (e.g., a room subscriber) generally would require information from the
  578. redistribution service, and this would generally require the redistribution service to
  579. support an extension to make that information available to entities desiring to verify the
  580. signature(s). If one accepts the premise that downstream verification of redistributed
  581. stanzas, such as via a MUC service, cannot be performed without extension and cooperation
  582. of the redistribution service, then it follows that dual content can be avoided by having
  583. the MUC service also support the signing extension.</p>
  584. <p>Dual content approaches should be avoided.</p>
  585. </section3>
  586. </section2>
  587. <section2 topic="Key Info" anchor="key-info">
  588. <p>While a signer may provide a &KEYINFO; element within the &SIGNATURE;, doing so will
  589. significantly increase the size of the &SIGNATURE; element. As implementations may enforce a
  590. maximum stanza size as small as 10,000 bytes, use of &KEYINFO; in stanza signatures should
  591. be limited.</p>
  592. <p>It is also noted there are cases where the signer may not want to expose the key
  593. information to all entities involved in the exchange of stanza.</p>
  594. <p>There are a number of ways key information may be published, such as in user's vCard. Key
  595. information can also be provided at request, such as by &IQ;.</p>
  596. </section2>
  597. </section1>
  598. <section1 topic="Security Considerations" anchor="seccon">
  599. <p>Care must be taken in the design of not only ensure it provides an effective digital
  600. signature solution for XMPP, but is designed itself with security in mind. This section
  601. discussions some security issues in providing a digital signature solution. The design should
  602. consider a general digital signature issues as well issues specific to the technologies
  603. used/involved, and particulars of the solution.</p>
  604. <p>Due to the nature of XML and XMPP, an effective general digital signing solution for XMPP is
  605. likely to be quite complex. This document suggests nothing less. With complexity comes
  606. significant security risk. To minimize this risk, the solutions should avoid reinvention of
  607. needed technology, such as signature and key information syntaxes, by reusing well established
  608. and understood technologies such as XMLDSIG. Solutions should also favor simple and widely
  609. used features of such technologies over esoteric or rarely used features</p>
  610. <p>Designers of the solution should be mind full of security considerations discussed in XMLDSIG
  611. (regardless of whether XMLDSIG is used in the solution)</p>
  612. <p>If XMLDSIG is used, a number of security considerations would be introduced into the
  613. solution. Implementations need to take special care in processing XMLDSIG &SIGNATURE; elements
  614. to avoid a wide range of attacks. For instance, an attacker could attempt to mount a Denial of
  615. Service attack by sending a &SIGNATURE; purporting to sign arbitrary large and complex
  616. content. Or an attacker could attempt to mount a Distributed Denial of Service sending a
  617. message to a chatroom that containing &SIGNATURE; with multiple references to large content
  618. hosted at the attack target in hopes that each room participant will repeated fetch it. A
  619. &SIGNATURE; element might also contain circler references.</p>
  620. </section1>
  621. </xep>