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='[EMAIL PROTECTED]/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. /psa
smime.p7s
Description: S/MIME Cryptographic Signature
