Adjusted format to include multiple hashes in one element; modified namespace versioning rules to align with common practice; added service discovery features for various algorithms.
This document defines a new XML element that can be used in any XMPP protocol extension. An example follows.
+This document defines a new XML element (and child elements) that can be used in any XMPP protocol extension. An example follows.
- 2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU=
-
+
+ 2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU=
+
+ ]]>
+ The <hashes/> element MAY contain more than one <hash/> child, as in the following example.
+
+ 2AfMGH8O7UNPTvUVAM9aK13mpCY=
+ 2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU=
+
]]>
The value of the 'algo' attribute MUST be one of the values from the &ianahashes; maintained by &IANA;.
This document defines the XML namespace 'urn:xmpp:hashes:0'. The document MUST be updated, and the namespace version MUST be incremented, whenever the XSF wishes to modify the list of mandatory, recommended, deprecated, and obsolete algorithms.
-The MD2 algorithm is not used in any XMPP protocols and has been deprecated by the IETF (see &rfc6149;).
@@ -116,6 +127,32 @@These recommendations ought to be reviewed yearly by the &COUNCIL;.
If an entity supports the protocol defined herein, it MUST report that by including a &xep0030; feature of "urn:xmpp:hashes:0" in response to disco#info requests, along with one service discovery feature for each algorithm it supports:
+In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
+This entire document discusses security.
This document requires no interaction with the ®ISTRAR;.
+This specification defines the following XML namespace:
+The ®ISTRAR; shall include the foregoing namespace in its registry at &NAMESPACES;, as governed by &xep0053;.
+An entity SHOULD provide one service discovery feature for each algorithm it supports. Ideally these features would be of the form "urn:iana:hash-function-text-names:foo" (where "foo" is the name of an algorithm registered with the IANA); however there is no urn:iana namespace at present. Until there is, we use features of the form "urn:xmpp:hash-function-text-names:foo" instead. Therefore the registry submission is as follows.
+
+ urn:xmpp:hash-function-text-names:md5
+ Support for the MD5 hashing algorithm
+ XEP-xxxx
+
+
+ urn:xmpp:hash-function-text-names:sha-1
+ Support for the SHA-1 hashing algorithm
+ XEP-xxxx
+
+
+ urn:xmpp:hash-function-text-names:sha-224
+ Support for the SHA-224 hashing algorithm
+ XEP-xxxx
+
+
+ urn:xmpp:hash-function-text-names:sha-256
+ Support for the SHA-256 hashing algorithm
+ XEP-xxxx
+
+
+ urn:xmpp:hash-function-text-names:sha-384
+ Support for the SHA-384 hashing algorithm
+ XEP-xxxx
+
+
+ urn:xmpp:hash-function-text-names:sha-512
+ Support for the SHA-512 hashing algorithm
+ XEP-xxxx
+
+ ]]>
+ Thanks to Dave Cridland, Waqas Hussain, Glenn Maynard, and Remko Tronçon for their input.