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

Peter Saint-Andre stpeter at jabber.org
Mon Jul 2 22:42:37 UTC 2007


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

-------------- 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/20070702/59d3e9e3/attachment.bin>


More information about the Standards mailing list