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

Peter Saint-Andre stpeter at jabber.org
Tue Jul 3 18:41:07 UTC 2007

Joe Hildebrand wrote:
> I just talked to stpeter IRL (he's all of 10 feet from me; should have
> done that first thing this morning!), 

I just measured. It's 15 feet. :P

> and made sure he understood what I
> was after.  I'm replying to Rachel's mail, since it hits on the two (in
> my mind) remaining interesting questions, namely:
> 1) is it necessary to explicitly flag that we're doing hashes?
> I like Kevin Smith's suggestion that the receiver should always do the
> hash.  For old clients, the hash will never match, but it's the same
> policy decision to allow old clients as to allow broken senders that
> send bad hashes.

I like that too. But I also agree with Dave that we want to future-proof
this. What if 3 years from now we want to use SHA-256 and 7 years from
now we want to use an algorithm that emerges from the current NIST work?
 It might be good to include a 'hash' attribute whose value is one of
the hash function text names from the IANA registry (but the value
defaults to MD5 or whatever we settle on now so that you don't have to
include it until we decide to allow alternate algorithms).

> 2) do we need ext in the hash world?
> Rachel makes a good point that without ext, more data has to be cached,
> since there will be redundant features associated with different ver's. 
> I think it's a toss-up; no ext's is considerably simpler for all
> involved; no partitioning of features on the sender side and no unions
> on the receiving side.

I don't think we need 'ext' in the hash world.

> To be clear and explicit, all in one place, here is what I'm recommending:
> <presence from='bard at shakespeare.lit/globe'>
>   <c xmlns='http://jabber.org/protocol/caps'
>      node='http://psi-im.org/caps'
>      ver='big-long-hash-goes-here'/>
> </presence>
> Again, I think simplicity dictates that we pick a single hash algorithm
> and stick with it; I'm almost entirely disinterested in what that
> algorithm is, as long as it doesn't provide output that has too many
> bytes in it.

Too many bytes, my dear Mozart!

What is too many bytes? Too many bytes for what purpose? As noted, 3
years from now we might decide to use SHA-256 or whatever even if the
hashes are longer because the security properties are preferable.

So yes let's settle on one hash algorithm to start, but let's not close
the door to other algorithms in the future if needed.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070703/5b7adb97/attachment.bin>

More information about the Standards mailing list