Joe Hildebrand wrote: > > 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?
+1 to "simpler to implement". >>> - 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. +1. >>> 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? Not that I see: http://www.iana.org/assignments/urn-namespaces Could we use urn:uuid: as defined in RFC 4122 but specify a different algorithm? Alternatively we could specify urn:xmpp:hash: or whatever since we control the urn:xmpp: tree. :) Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
