mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 16:55:07 -05:00
XEP-0290/0274 misc updates
also update xep.ent with updated title of XEP-0285.
This commit is contained in:
parent
b264600861
commit
9c7f90d680
81
xep-0274.xml
81
xep-0274.xml
@ -1,6 +1,7 @@
|
||||
<?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/>">
|
||||
@ -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 <<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>" >
|
||||
<!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 <<link url='http://xmpp.org/extensions/inbox/encapsulated-signatures.html'>http://xmpp.org/extensions/inbox/encapsulated-signatures.html</link>>.</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[
|
||||
|
184
xep-0290.xml
184
xep-0290.xml
@ -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>
|
||||
|
2
xep.ent
2
xep.ent
@ -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 <<link url='http://xmpp.org/extensions/xep-0282.html'>http://xmpp.org/extensions/xep-0282.html</link>>.</note>" >
|
||||
<!ENTITY xep0283 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0283.html'>Moved</link></span> <note>XEP-0283: Moved <<link url='http://xmpp.org/extensions/xep-0283.html'>http://xmpp.org/extensions/xep-0283.html</link>>.</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 <<link url='http://xmpp.org/extensions/xep-0284.html'>http://xmpp.org/extensions/xep-0284.html</link>>.</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 <<link url='http://xmpp.org/extensions/xep-0285.html'>http://xmpp.org/extensions/xep-0285.html</link>>.</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 <<link url='http://xmpp.org/extensions/xep-0285.html'>http://xmpp.org/extensions/xep-0285.html</link>>.</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 <<link url='http://xmpp.org/extensions/xep-0286.html'>http://xmpp.org/extensions/xep-0286.html</link>>.</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 <<link url='http://xmpp.org/extensions/xep-0287.html'>http://xmpp.org/extensions/xep-0287.html</link>>.</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 <<link url='http://xmpp.org/extensions/xep-0288.html'>http://xmpp.org/extensions/xep-0288.html</link>>.</note>" >
|
||||
|
Loading…
Reference in New Issue
Block a user