[Standards] Re: [jdev] XEP-0115: Entity Capabilities

[Joe Hildebrand]

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://  
>> www.unicode.org/unicode/reports/tr10/)
>
> 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?

>> - 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 wire.

>> 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  
> smaller.

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?

> We send these out, currently, with every presence update, correct?  
> Is it worth looking at an alternate mechanism, or a generalized  
> presence-delta? (After all, I'm pretty sure that this data won't  
> change as often as my status).

There's a server optimization that keeps it from going out as often,  
but I don't know that it's been implemented.

> I have to admit, I have an odd feeling that combining all  
> extensions together might generate a better result, too, but that's  
> nothing more than a gut feeling.

It probably depends upon how often extensions are turned on and off,  
whether the server optimization is in effect, and the like.  I  
suppose there's nothing stopping the writer of an entity from doing  
this, and never sending ext.

-- 
Joe Hildebrand