[Standards] Re: [jdev] XEP-0115: Entity Capabilities
stpeter at jabber.org
Mon Jul 2 22:42:37 UTC 2007
Joe Hildebrand wrote:
> On Jun 29, 2007, at 3:40 AM, Dave Cridland wrote:
>> On Thu Jun 28 23:12:25 2007, Joe Hildebrand wrote:
>>> The current spec could absolutely be used for this. The hardest
>>> part is spec'ing how to generate a string that has all of the
>>> capabilities, so that you can run the hash. Canonical XML is
>>> massive overkill, but, for example, if we just said:
>>> - For all sorting, use the Unicode Collation Algorithm (http://
>> Feh. UTF-8 encode then i;octet - much faster, just as stable, and a
>> heck of a lot simpler to implement, especially given that namespaces
>> will be us-ascii anyway (hence UTF-8). RFC4790 defines this. (i;basic
>> uses TR10, but ISTR it's not yet ready).
> +1. What's the standards-language way of saying that?
+1 to "simpler to implement".
>>> - Initialize an empty string E
>>> - sort the identities by category, then type
>>> - for each identity, append the category, then the type (if it
>>> exists) to E (note: any information inside an identity will be ignored)
>> I'd propose something mildly more structured here, really such that
>> it's simpler to view by eye to ensure the formatting and ordering is
>> correct. This has no security impact, it's just easier to implement.
> I'm not sure why readability is important here. It's never going on the
>>> For better security, we could use HMAC, and/or a different hash
>>> function. One option would be that, if H is the result of the
>>> hash/hmac function, then V, the version string, is formed by
>>> prepending its algorithm and a $, something like:
>> E = *(cat-line) *(feat-line)
>> H = <hash/hmac of E>
>> V = hash-func-name "$" H
>> hash-func-name = hash-name / "HMAC-" hash-name
>> hash-name = "MD5" / "SHA1" / "SHA-256"
>> We mandate that HMAC-MD5 is used, but a future specification MAY
>> change this requirement. MD5 does have the minor advantage of being
> I think this is overkill. Finding a one-way collision in a hash
> function seems like adequate protection against a DoS attack. The
> simpler this is to check, and the less ways of messing it up, the more
> likely it will be to get implemented. Let's just pick a single
> algorithm and stick with it.
>>> If the receiving client detects an inconsistency, it MUST NOT use
>>> the information it received, and SHOULD show an error of some kind.
>>> For backwards-compatibility, any version number that is not 32
>>> octets long consisting only of [0-9a-f] MUST be treated as if it
>>> does not implement MD5 checking.
>> We've got slightly better error checking if we explicitly tag the data
>> with the prefix defined by the V ABNF production above.
> Fine. But let's just pick one prefix. Is there a urn:hash: URI scheme?
Not that I see:
Could we use urn:uuid: as defined in RFC 4122 but specify a different
Alternatively we could specify urn:xmpp:hash: or whatever since we
control the urn:xmpp: tree. :)
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards