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

[Joe Hildebrand]

On Jun 27, 2007, at 2:32 AM, Jacek Konieczny wrote:

> That is not true. Years ago I have proposed other solution: instead of
> announcing client name version and caps clients should announce digest
> (e.g. MD5 or SHA) of normalized set of supported features. The list
> would have to be obtained only once per feature set and it could be
> verified. The traffic would not be much bigger than with current
> solution and the 'cache taint' problem would be gone. And
> implementations could be simpler (no need for capability registry --
> namespace registry is enough) and less error-prone (when a new  
> namespace
> is added the digest would change 'automatically'. Currently developers
> have to manually update version or capability string).
>
> I think the digest could be used with current specification too -- as
> the only capability string, bound with all the supported  
> namespaces. But
> XEP-0115 is not optimized for such usage and says nothing about digest
> verification.

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/)
- 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)
- sort the features by URI
- for each feature, append the URI to E  (note: any information  
inside a feature will be ignored)
- calculate the MD5 sum for E
- use this for the version number or extension name

Example (adapted from XEP-115, example 2):

<presence from='romeo at montague.net/home'>
   <c xmlns='http://jabber.org/protocol/caps'
      node='http://exodus.jabberstudio.org/caps'
      ver='730c80b442e150dd5e19a31f8edfa8b1'
      ext='d6224a352df544cfde1fbce177301c67  
d0ef9e8327acf5873d16fe083b4d3f3f'/>
</presence>

The receiving client SHOULD check the hashes, after doing the IQ/gets:

md5(clientpchttp://jabber.org/protocol/disco#infohttp://jabber.org/ 
protocol/disco#itemshttp://jabber.org/protocol/feature-neghttp:// 
jabber.org/protocol/muc) = 730c80b442e150dd5e19a31f8edfa8b1
md5(clientpchttp://jabber.org/protocol/bytestreamshttp://jabber.org/ 
protocol/sihttp://jabber.org/protocol/si/profile/file-transfer) =  
d6224a352df544cfde1fbce177301c67
md5(clientpchttp://jabber.org/protocol/xhtml-im) =  
d0ef9e8327acf5873d16fe083b4d3f3f

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.

Analysis:
- Existing entities, both sending and receiving, should work fine
- Over time, we can phase in entities that send md5 versions and ext's
- Receiving clients that care about security can start checking MD5  
hashes of the features to check for poisoning.
- Downside: more bytes in presence than today.
- Assertion: anything else we do will be at least this bad if not worse.

If we add these bits to -115, will everyone agree to never bring up  
changing caps again, and to all agree on that the next time a n00b  
comes around?

-- 
Joe Hildebrand