[jdev] Algorithms and XMPP

Peter Saint-Andre stpeter at stpeter.im
Sat Feb 20 21:52:13 CST 2010


Hi Waqas!

On 2/20/10 6:21 PM, Waqas Hussain wrote:
> There are a number of algorithms an XMPP developer needs to deal with,
> either directly or through a library. Some of these are defined in XEPs,
> while some are external specifications which we work with.
> 
> These include:
> 
> * DIGEST-MD5
> * SCRAM
> * Entity capabilities hashing
> * JID escaping
> 
> Over the years, I’ve seen people trying to implement these through trial
> and error, and frequently getting them done only partially correctly.
> After helping people fix their DIGEST-MD5 implementations at least a
> dozen times, I think we have a problem.

There's certainly a problem with DIGEST-MD5. Hopefully we can leave it
behind and settle on SCRAM going forward.

> I propose that we start a small project to act as an aggregator for
> existing open source implementations which could be used as references.

That's a great idea.

> Once we have that going, an implementation selected for its readability
> could become the (official?) reference implementation.

We've never had reference implementations. I'm not even quite sure what
"reference implementation" means. :)

One approach would be to write an implementation in C and then write
wrappers for that implemenation in Python, Lua, etc. This seems to be a
popular approach for things like security (OpenSSL) and i18n (libidn),
and might make sense for things like caps hashing and JID escaping.

> What this would achieve:
> 
> 1. It would save people writing new implementations hours and hours of
> guesswork
> 2. It would make new implementations more interoperable, reducing the
> chance of mistakes
> 3. It would make existing implementations more visible, improving the
> chance of mistakes being found and reported, and implementations being
> reused
> 4. For experimental XEPs this would give direct evidence of how simple
> or complex an algorithm is, what the edge cases are, and if it could be
> simplified without losing its important characteristics

Those are all excellent goals.

> In fact I wouldn’t mind it being required that any XEP moving beyond
> Experimental have implementations available for the algorithms it
> defines, under a permissive license.

Currently the XSF requires two implementations (one open-source) for
advancement from Draft to Final. I think it's worth discussing what's
required for a XEP to move along in the XSF's standards process, but I
think that topic is separate from the main body of your message.

> I’m hoping to not be the only one who sees this as a problem we should
> solve. What does everyone else think?

I think let's create a few page about this at wiki.xmpp.org and get to
work. :)

Peter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20100220/5665852f/attachment.bin>


More information about the JDev mailing list