mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 10:12:19 -05:00
typo + line endings
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1977 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
345316ee84
commit
ca1d6db7db
94
xep-0115.xml
94
xep-0115.xml
@ -221,7 +221,7 @@
|
||||
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
<p>The protocol defined herein addresses the following requirements:</p>
|
||||
<ol>
|
||||
<ol start='1'>
|
||||
<li>Clients must be able to participate even if they support only &xmppcore;, &xmppim;, and <cite>XEP-0030</cite>.</li>
|
||||
<li>Clients must be able to participate even if they are on networks without connectivity to other XMPP servers, services offering specialized XMPP extensions, or HTTP servers.<note>These first two requirements effectively eliminated <cite>XEP-0060</cite> as a possible implementation of entity capabilities.</note></li>
|
||||
<li>Clients must be able to retrieve information without querying every entity with which they communicate.</li>
|
||||
@ -270,7 +270,7 @@
|
||||
<section2 topic='Generation Method' anchor='ver-gen'>
|
||||
<p>In order to help prevent poisoning of entity capabilities information, the value of the verification string MUST be generated according to the following method.</p>
|
||||
<p>Note: All sorting operations MUST be performed using "i;octet" collation as specified in Section 9.3 of &rfc4790;.</p>
|
||||
<ol>
|
||||
<ol start='1'>
|
||||
<li>Initialize an empty string S.</li>
|
||||
<li>Sort the service discovery identities <note>A registry of service discovery identities is located at &DISCOCATEGORIES;.</note> by category and then by type and then by xml:lang (if it exists), formatted as CATEGORY '/' [TYPE] '/' [LANG] '/' [NAME]. Note that each slash is included even if the TYPE, LANG, or NAME is not included.</li>
|
||||
<li>For each identity, append the 'category/type/lang/name' to S, followed by the '<' character.</li>
|
||||
@ -278,11 +278,11 @@
|
||||
<li>For each feature, append the feature to S, followed by the '<' character.</li>
|
||||
<li>If the service discovery information response includes <cite>XEP-0128</cite> data forms, sort the forms by the FORM_TYPE (i.e., by the XML character data of the <value/> element).</li>
|
||||
<li>For each extended service discovery information form:
|
||||
<ol>
|
||||
<ol start='1'>
|
||||
<li>Append the XML character data of the FORM_TYPE field's <value/> element, followed by the '<' character.</li>
|
||||
<li>Sort the fields by the value of the "var" attribute.</li>
|
||||
<li>For each field:
|
||||
<ol>
|
||||
<ol start='1'>
|
||||
<li>Append the value of the "var" attribute, followed by the '<' character.</li>
|
||||
<li>Sort values by the XML character data of the <value/> element.</li>
|
||||
<li>For each <value/> element, append the XML character data, followed by the '<' character.</li>
|
||||
@ -295,14 +295,27 @@
|
||||
</ol>
|
||||
</section2>
|
||||
<section2 topic='Simple Generation Example' anchor='ver-gen-simple'>
|
||||
<p>Consider an entity whose category is "client", whose service discovery type is "pc", whose service discovery name is "Exodus 0.9.1", and whose supported features are "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", and "http://jabber.org/protocol/muc". Using the SHA-1 algorithm, the verification string would be generated as follows:</p>
|
||||
<ol>
|
||||
<li>S = ''</li>
|
||||
<li>Only one identity: "client/pc"</li>
|
||||
<li>S = 'client/pc//Exodus 0.9.1<'</li>
|
||||
<li>Sort the features: "http://jabber.org/protocol/caps", "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc".</li>
|
||||
<li>S = 'client/pc//Exodus 0.9.1<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<'</li>
|
||||
<li>ver = QgayPKawpkPSDYmwT/WM94uAlu0=</li>
|
||||
<p>Consider an entity whose category is "client", whose service discovery type is "pc", whose service discovery name is "Exodus 0.9.1", and whose supported features are "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", and "http://jabber.org/protocol/muc". Using the SHA-1 algorithm, the verification string would be generated as follows (note: line breaks in the verification string are included only for the purposes of readability):</p>
|
||||
<ol start='1'>
|
||||
<li>
|
||||
<p>S = ''</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Only one identity: "client/pc"</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>S = 'client/pc//Exodus 0.9.1<'</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Sort the features: "http://jabber.org/protocol/caps", "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc".</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>S = 'client/pc//Exodus 0.9.1<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<
|
||||
<br />http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<'</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>ver = QgayPKawpkPSDYmwT/WM94uAlu0=</p>
|
||||
</li>
|
||||
</ol>
|
||||
</section2>
|
||||
<section2 topic='Complex Generation Example' anchor='ver-gen-complex'>
|
||||
@ -345,33 +358,58 @@
|
||||
</iq>
|
||||
</code>
|
||||
<p>Using the SHA-1 algorithm, the verification string would be generated as follows (note: line breaks in the verification string are included only for the purposes of readability):</p>
|
||||
<ol>
|
||||
<li>S = ''</li>
|
||||
<li>Two identities: "client/pc/Psi" and "client/pc/Ψ"</li>
|
||||
<li>S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<'</li>
|
||||
<li>Sort the features: "http://jabber.org/protocol/caps", http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc".</li>
|
||||
<li>S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info
|
||||
<br /><http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc'.</li>
|
||||
<li>Sort the extended service discovery forms by FORM_TYPE (there is only one: "urn:xmpp:dataforms:softwareinfo").</li>
|
||||
<li>S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<urn:xmpp:dataforms:softwareinfo<'</li>
|
||||
<li>Sort the fields by var and append the value(s): "ip_version<ipv4<ipv6", "os<Mac", "os_version<10.5.1", "software<Psi", "software_version<0.11".</li>
|
||||
<li>S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<urn:xmpp:dataforms:softwareinfo<ip_version<ipv4<ipv6<os<Mac<os_version<10.5.1<software<Psi<software_version<0.11<'</li>
|
||||
<li>ver = q07IKJEyjvHSyhy//CH0CxmKi8w=</li>
|
||||
<ol start='1'>
|
||||
<li>
|
||||
<p>S = ''</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Two identities: "client/pc/Psi" and "client/pc/Ψ"</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<'</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Sort the features: "http://jabber.org/protocol/caps", http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc".</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>
|
||||
S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<
|
||||
<br />http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<'.
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Sort the extended service discovery forms by FORM_TYPE (there is only one: "urn:xmpp:dataforms:softwareinfo").</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<
|
||||
<br />http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<urn:xmpp:dataforms:softwareinfo<'</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Sort the fields by var and append the value(s): "ip_version<ipv4<ipv6", "os<Mac", "os_version<10.5.1", "software<Psi", "software_version<0.11".</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<
|
||||
<br />http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<urn:xmpp:dataforms:softwareinfo<
|
||||
<br />ip_version<ipv4<ipv6<os<Mac<os_version<10.5.1<software<Psi<software_version<0.11<'</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>ver = q07IKJEyjvHSyhy//CH0CxmKi8w=</p>
|
||||
</li>
|
||||
</ol>
|
||||
</section2>
|
||||
<section2 topic='Processing Method' anchor='ver-proc'>
|
||||
<p>When an entity receives a value of the 'ver' attribute that appears to be a verification string generated in accordance with the generation method defined in this specification, it MUST process the 'ver' according to the following method.</p>
|
||||
<ol>
|
||||
<ol start='1'>
|
||||
<li>Verify that the <c/> element includes a 'hash' attribute. If it does not, ignore the 'ver' or treat it as generated in accordance with the <link url='#legacy'>Legacy Format</link> (if supported).</li>
|
||||
<li>If the value of the 'hash' attribute does not match one of the processing application's supported hash functions, do the following:
|
||||
<ol>
|
||||
<ol start='1'>
|
||||
<li>Send a service discovery information request to the generating entity.</li>
|
||||
<li>Receive a service discovery information response from the generating entity.</li>
|
||||
<li>Do not validate or globally cache the verification string as described below; instead, the processing application SHOULD associate the discovered identity+features <em>only</em> with the JabberID of the generating entity.</li>
|
||||
</ol>
|
||||
</li>
|
||||
<li>If the value of the 'hash' attribute matches one of the processing application's supported hash functions, validate the verification string by doing the following:
|
||||
<ol>
|
||||
<ol start='1'>
|
||||
<li>Send a service discovery information request to the generating entity.</li>
|
||||
<li>Receive a service discovery information response from the generating entity.</li>
|
||||
<li>If the response includes more than one service discovery identity with the same category/type/lang/name, consider the entire response to be ill-formed.</li>
|
||||
@ -538,7 +576,7 @@
|
||||
<li>Given knowledge of a particular value S used as the input message to the hash function, an attacker can find a value S' that yields V (this is known as a "second preimage attack").</li>
|
||||
</ul>
|
||||
<p>In practice, a preimage attack would need to meet all of the following criteria in order to be effective against the entity capabilities protocol:</p>
|
||||
<ol>
|
||||
<ol start='1'>
|
||||
<li>The hashing algorithm used would need to be found not only theoretically but practically vulnerable to first or second preimage attacks (e.g., this is not yet true of the MD5 or SHA-1 algorithms, but may become true in the future).</li>
|
||||
<li>An attacker would need to find an input message X or S' that matches the hash V for a particular value of V or S, which may not be practical given that (a) the values of S used as input to the hash function in entity capabilities are relatively short and (b) cryptanalysis to date indicates that existing hash functions may not be vulnerable to preimage attacks except in the case of relatively long input messages (on the order of 2<span class='super'>55</span> blocks).</li>
|
||||
<li>The input message X or S' would need to conform to the structure of S as specified under <link url='#ver'>Verification String</link>, including the order of service discovery identity or identities followed by service discovery features, delimited by the '<' character and sorted using "i;octet" collation.</li>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user