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
