[JDEV] XMPP implementation questions

[Justin Karneges]

> The main topics mentioned to me relate to security, specifically SASL
> for authentication, TLS for channel encryption, and CPIM + S/MIME for
> end-to-end encryption. Do people think they will be able to integrate
> existing libraries for these protocols into their applications (or write
> their own support, as Rob Norris recently did for SASL in jabberd2)? How
> likely is it that existing clients will implement draft-ietf-xmpp-e2e,
> which uses CPIM and S/MIME for end-to-end encryption?

I feel the redundancy between TLS and SASL makes things confusing, but I'm not 
sure what we can do about it.  For client connections, SASL is what 99% of 
people need.  The only advantage of TLS is login-by-certificate, which I 
think will be rare in the grand scheme.  It would be nice if client authors 
could forgo the use of TLS if they don't plan to support such a rare feature.

> From discussions so far, my sense is that SASL and TLS support will be
> added once it's in the jabberd server, but that client developers are
> fairly resistant to adding support for the end-to-end encryption spec
> given the need to parse CPIM formats (no existing libraries as far as I
> know) and support S/MIME (for which there are libraries, although the
> use of S/MIME is not very "Jabberish").

>From what I understand, SASL and TLS are already in jabberd2.  I plan to 
implement the protocols in my client and test against it.

e2e is clearly important.  I don't think CPIM formatting is the end of the 
world, but it sure does seem alien to Jabber.  If it becomes the standard, I 
will implement it, but I'd rather it were something else..

For the actual encryption, we have S/MIME (which, as far as I know, is 
encryption by X509).  Fine, but we also have OpenPGP (JEP-27) and the more 
complicated JEP-102, which supports "ad-hoc" security.  Where is a client 
author to begin?

-Justin