XEP-0290/0274 misc updates

also update xep.ent with updated title of XEP-0285.
This commit is contained in:
Kurt Zeilenga 2011-01-28 07:01:53 -08:00
parent b264600861
commit 9c7f90d680
3 changed files with 113 additions and 154 deletions

View File

@ -1,6 +1,7 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
<!ENTITY SIGNATURE "&lt;Signature/&gt;">
<!ENTITY REFERENCE "&lt;Reference/&gt;">
<!ENTITY SIGNEDINFO "&lt;SignedInfo/&gt;">
@ -14,7 +15,6 @@
<!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 &lt;<link url='http://www.w3.org/TR/xmldsig-core/'>http://www.w3.org/TR/xmldsig-core/</link>&gt;.</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 &lt;<link url='http://www.w3.org/TR/xptr'>http://www.w3.org/TR/xptr</link>&gt;.</note>" >
<!ENTITY xmpp-dsig-new "<span class='ref'><link url='http://xmpp.org/extensions/inbox/encapsulated-signatures.html'>XMPP DSIG</link></span> <note>Encapsulated Digital Signatures in XMPP &lt;<link url='http://xmpp.org/extensions/inbox/encapsulated-signatures.html'>http://xmpp.org/extensions/inbox/encapsulated-signatures.html</link>&gt;.</note>" >%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
@ -35,13 +35,21 @@
<supersededby/>
<shortname>N/A</shortname>
&kdz;
<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>
<p>Update discussions based upon introduction of Encapsulated Digital Signatures in XMPP, an
alternative to XEP-0285.</p>
</remark>
</revision>
<revision>
@ -254,10 +262,18 @@
</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>
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>
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
@ -273,11 +289,11 @@
to have applicability limited to the CDCIE.</p>
</section2>
<section2 topic="Encapsulated Digitial Signatures in XMPP" anchor="xmpp-ed-dsig">
<p>The &xmpp-dsig-new; (XMPP DSIG) is an encapsulated signature proposal similar to
that encapsulated approach suggested below.</p>
<p>Unlike CDCIE-CCP approach, XMPP DSIG signatures are not "enveloped" signatures over the
whole stanza but signatures over a manifest and descriptive objects detailing the stanza
contents.</p>
<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>
@ -285,9 +301,8 @@
<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>
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>
@ -326,13 +341,13 @@
</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>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
@ -523,26 +538,26 @@
<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>
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
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>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[

View File

@ -24,10 +24,20 @@
<shortname>N/A</shortname>
&kdz;
<revision>
<version>0.1</version>
<date>2011-01-26</date>
<initials>psa</initials>
<remark><p>Initial published version.</p></remark>
<version>0.2</version>
<date>2011-01-28</date>
<initials>kdz</initials>
<remark>
<p>Merge manifest and schema-desc objects.</p>
</remark>
</revision>
<revision>
<version>0.1</version>
<date>2011-01-26</date>
<initials>psa</initials>
<remark>
<p>Initial published version.</p>
</remark>
</revision>
<revision>
<version>0.0.1</version>
@ -40,25 +50,30 @@
</header>
<section1 topic="Introduction" anchor="intro">
<p class="box"><em>This document is one of two proposals for digital signatures in XMPP. It
is expected that only one of these proposals be progressed beyond Experimental on
the Standards Track.</em></p>
<p>This document provides a technical specification for Encapsulated Digital Signatures in
Extensible Messaging and Presence Protocol (&xmpp;).</p>
<p>XMPP Digital Signatures may be used to provide signer authentication, data integrity,
non-repudiation, and other security services.</p>
<p>This extension is intended to be highly flexible, supporting a wide range of applications.
The extension not only supports signing by the originator, but by other entities which
handle XMPP stanzas. Multiple entities may independently sign a stanza.</p>
<p>A signed manifest approach is used to allow selective signing (only select elements
may be included in the manifest) and to allow flexibility in handling verification
errors.</p>
<p>This extension is intended to support <em>optimistic signing</em>.</p>
non-repudiation, and other security services.</p>
<p>This extension is intended to be highly flexible, supporting a wide range of
applications. The extension not only supports signing by the originator, but by other
entities which handle XMPP stanzas. Multiple entities may independently sign a
stanza.</p>
<p>A signed manifest approach is used to allow selective signing (only select elements may
be included in the manifest) and to allow flexibility in handling verification
errors.</p>
<p>This extension is intended to support <em>optimistic signing</em>.</p>
<p>This document offers an encapsulated signature approach based upon &w3xmlsig; (XMLDSIG).
Implementations of this extension not required to fully implement the XML DSIG
specification, they may implement only the minimal subset necessary to support this
extension.</p>
<p>It is noted that a number of object-level XMPP digital signature extensions have been
specified over the years. These include &rfc3923; (XMPP E2E), &xep0116; (XMPP PGP),
and &xep0285;. The limited applicability of encapsulating signature approaches in XMPP
is discussed in &xep0274;.</p>
specified over the years. These include &rfc3923; (XMPP E2E), &xep0116; (XMPP PGP), and
&xep0285;. The limited applicability of encapsulating signature approaches in XMPP is
discussed in &xep0274;.</p>
</section1>
<section1 topic="Signing XMPP Stanzas" anchor="stanza">
<p>The process that a sending agent follows for securing stanzas is very similar regardless
@ -76,10 +91,10 @@
<p>This is modified prior to signing as follows:</p>
<ul>
<li>Default attribute values are added. (Namespace declarations are not modified.)</li>
<li>Each child element of the stanza is augmented by a <tt>id</tt> attribute
qualified in the <tt>urn:xmpp:dsig:0</tt> namespace. As these attributes are used to
identify the element within a manifest, they must be sufficient unique.</li>
<li>Default attribute values are added. (Namespace declarations are not modified.)</li>
<li>Each child element of the stanza is augmented by a <tt>id</tt> attribute qualified
in the <tt>urn:xmpp:dsig:0</tt> namespace. As these attributes are used to identify
the element within a manifest, they must be sufficient unique.</li>
</ul>
<example><![CDATA[
<message from='juliet@capulet.net'
@ -94,43 +109,25 @@
<p>The signer builds a stanza description object containing a signer element, the stanza
element, and a timestamp element. The signer element value is the bare JID of the
signing entity. When the signing entity is a service entity, the JID may only contain
service domain. The stanza element is the stanza prepared above with each of its element
replaced by an reference element.</p>
service domain. The stanza-desc element is the stanza prepared above with each of its
child elements replaced by an reference element. The reference element references the
child element via a "urn:xmpp:dsig:ref:0" URI with an anchor of the value of child
element's <tt>d:id</tt>. The value of the reference element is the digest value produced
by the digest method after the specified transforms are applied.</p>
<example><![CDATA[
<stanza id="stanza-desc" xmlns="urn:xmpp:dsig:0">
<stanza-desc id="stanza-desc" xmlns="urn:xmpp:dsig:0">
<signer>juliet@capulet.net</signer>
<Transforms><Transform Algorithm="urn:xmpp:dsig:transform:0"/></Transform>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<message from='juliet@capulet.net'
id='183ef129'
to='romeo@montague.net'
type='chat'>
<reference>xxxx-1</reference>
<reference>xxxx-2</reference>
<reference URI='urn:xmpp:dsig:ref:0#xxxx-1'>...</reference>
<reference URI='urn:xmpp:dsig:ref:0#xxxx-2'>...</reference>
</message>
<timestamp>2010-11-11T13:33:00.123Z</timestamp>
</stanza>
]]></example>
<p>The signer then builds an XMLDSIG Manifest object which references each element via the
<tt>xmpp:dsig:ref:0</tt> URN and provides a digest over the element (after it has
been modified to include a <tt>d:id</tt> attribute) as transformed by the transformation
algorithm.</p>
<example><![CDATA[
<Manifest id="manifest">
<Reference URI="urn:xmpp:dsig:ref:0#xxxx-1">
<Transforms>
<Transform Algorithm="urn:xmpp:dsig:transform:0"/>
</Transform>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
<Reference URI="urn:xmpp:dsig:ref:0#xxxx-2">
<Transforms>
<Transform Algorithm="urn:xmpp:dsig:transform:0"/>
</Transform>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
</Manifest>
</stanza-desc>
]]></example>
<p>The signer then builds a SignedInfo element.</p>
@ -145,13 +142,6 @@
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
<Reference URI="#manifest" Type="http://www.w3.org/2000/09/xmldsig#Manifest">
<Transforms>
<Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
</Transform>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
</SignedInfo>
]]></example>
@ -168,50 +158,27 @@
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
<Reference URI="#manifest" Type="http://www.w3.org/2000/09/xmldsig#Manifest">
<Transforms>
<Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue/>
<Object>
<stanza id="stanza-desc" xmlns="urn:xmpp:dsig:0">
<stanza-desc id="stanza-desc" xmlns="urn:xmpp:dsig:0">
<signer>juliet@capulet.net</signer>
<Transforms><Transform Algorithm="urn:xmpp:dsig:transform:0"/></Transform>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<message from='juliet@capulet.net'
id='183ef129'
to='romeo@montague.net'
type='chat'>
<reference>xxxx-1</reference>
<reference>xxxx-2</reference>
id='183ef129'
to='romeo@montague.net'
type='chat'>
<reference URI='urn:xmpp:dsig:ref:0#xxxx-1'>...</reference>
<reference URI='urn:xmpp:dsig:ref:0#xxxx-2'>...</reference>
</message>
<timestamp>2010-11-11T13:33:00.123Z</timestamp>
</stanza>
</Object>
<Object>
<Manifest id="manifest">
<Reference URI="urn:xmpp:dsig:ref:0#xxxx-1">
<Transforms>
<Transform Algorithm="urn:xmpp:dsig:transform:0"/>
</Transform>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
<Reference URI="urn:xmpp:dsig:ref:0#xxxx-2">
<Transforms>
<Transform Algorithm="urn:xmpp:dsig:transform:0"/>
</Transform>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
</Manifest>
</stanza-desc>
</Object>
</Signature>
]]></example>
<p> The signer than computes the SignatureValue element, processing the Signature element as
<p>The signer than computes the SignatureValue element, processing the Signature element as
a detached signature, and replaces the empty Signature element with it. Finally, the
signer inserts the Signature element into stanza and forwards the stanza as it normally
would.</p>
@ -233,45 +200,22 @@
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
<Reference URI="#manifest" Type="http://www.w3.org/2000/09/xmldsig#Manifest">
<Transforms>
<Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...</SignatureValue>
<Object>
<stanza id="stanza-desc" xmlns="urn:xmpp:dsig:0">
<stanza-desc id="stanza-desc" xmlns="urn:xmpp:dsig:0">
<signer>juliet@capulet.net</signer>
<Transforms><Transform Algorithm="urn:xmpp:dsig:transform:0"/></Transform>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<message from='juliet@capulet.net'
id='183ef129'
to='romeo@montague.net'
type='chat'>
<reference>xxxx-1</reference>
<reference>xxxx-2</reference>
id='183ef129'
to='romeo@montague.net'
type='chat'>
<reference URI='urn:xmpp:dsig:ref:0#xxxx-1'>...</reference>
<reference URI='urn:xmpp:dsig:ref:0#xxxx-2'>...</reference>
</message>
<timestamp>2010-11-11T13:33:00.123Z</timestamp>
<stanza>
</Object>
<Object>
<Manifest id="manifest">
<Reference URI="urn:xmpp:dsig:ref:0#xxxx-1">
<Transforms>
<Transform Algorithm="urn:xmpp:dsig:transform:0"/>
</Transform>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
<Reference URI="urn:xmpp:dsig:ref:0#xxxx-2">
<Transforms>
<Transform Algorithm="urn:xmpp:dsig:transform:0"/>
</Transform>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
</Manifest>
</stanza-desc>
</Object>
</Signature>
</message>

View File

@ -1168,7 +1168,7 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates</link></span> <note>
<!ENTITY xep0282 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0282.html'>DMUC2: Distributed MUC</link></span> <note>XEP-0282: DMUC2: Distributed MUC &lt;<link url='http://xmpp.org/extensions/xep-0282.html'>http://xmpp.org/extensions/xep-0282.html</link>&gt;.</note>" >
<!ENTITY xep0283 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0283.html'>Moved</link></span> <note>XEP-0283: Moved &lt;<link url='http://xmpp.org/extensions/xep-0283.html'>http://xmpp.org/extensions/xep-0283.html</link>&gt;.</note>" >
<!ENTITY xep0284 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0284.html'>Shared XML Editing</link></span> <note>XEP-0284: Shared XML Editing &lt;<link url='http://xmpp.org/extensions/xep-0284.html'>http://xmpp.org/extensions/xep-0284.html</link>&gt;.</note>" >
<!ENTITY xep0285 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0285.html'>Digital Signatures in XMPP</link></span> <note>XEP-0285: Digital Signatures in XMPP &lt;<link url='http://xmpp.org/extensions/xep-0285.html'>http://xmpp.org/extensions/xep-0285.html</link>&gt;.</note>" >
<!ENTITY xep0285 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0285.html'>Encapsulating Digital Signatures in XMPP</link></span> <note>XEP-0285: Encapsulating Digital Signatures in XMPP &lt;<link url='http://xmpp.org/extensions/xep-0285.html'>http://xmpp.org/extensions/xep-0285.html</link>&gt;.</note>" >
<!ENTITY xep0286 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0286.html'>XMPP on Mobile Devices</link></span> <note>XEP-0286: XMPP on Mobile Devices &lt;<link url='http://xmpp.org/extensions/xep-0286.html'>http://xmpp.org/extensions/xep-0286.html</link>&gt;.</note>" >
<!ENTITY xep0287 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0287.html'>Spim Markers and Reports</link></span> <note>XEP-0287: Spim Markers and Reports &lt;<link url='http://xmpp.org/extensions/xep-0287.html'>http://xmpp.org/extensions/xep-0287.html</link>&gt;.</note>" >
<!ENTITY xep0288 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0288.html'>Bidirectional Server-to-Server Connections</link></span> <note>XEP-0288: Bidirectional Server-to-Server Connections &lt;<link url='http://xmpp.org/extensions/xep-0288.html'>http://xmpp.org/extensions/xep-0288.html</link>&gt;.</note>" >