On Thursday 05 March 2009 08:24:20 Peter Saint-Andre wrote:
> On 3/5/09 8:43 AM, Justin Karneges wrote:
> > This is exactly why I think we should try to find a solution that doesn't
> > require modification to existing TLS APIs.  We've already felt enough
> > pain just from XML APIs being inadequate for XMPP streaming (are people
> > done yet homebrewing their parsers with Java/.NET?).  Let's not repeat
> > all of that again with TLS, at least for the common scenarios we are
> > targetting.
>
> By that reasoning it was stupid for Jeremie to use XML for the original
> Jabber technologies when he started to design them in 1998 (XML was very
> new at the time, library support was missing on many platforms, etc.).

If XML support was hard to come by in 1998, that's a somewhat different issue, 
because then everyone would have been dragging along their own XML library 
anyway.  Had Jabber been designed in 2002, when XML support was available as 
a ready-to-use component of most languages and platforms, then yes I'd say it 
would be smart to try to work within the limits of "standard" XML APIs.

Obviously there's a cost/benefit assessment to be made.  We often make 
compromises in the interest of wider adoption.  Not that you need to be told 
anything about consensus and compromise. :)

> The "common scenarios we are targetting" for e2e are perhaps not so
> common because most people think of TLS as being used between a client
> and a server (a web browser connecting to a web server, an IM client
> connecting to an IM server), not between two human-controlled peers that
> need to perform mutual authentication (probably of end-user certs). So
> it's not clear to me that our scenario is common at all! The "common"
> case for c2s or s2s with mutual authentication involves X.509 certs.

You're right, this is not a common usage of TLS in the general sense.

However, cert/password auth between human-controlled peers will be the most 
common use-case for *us*, and I think it would be best to see if we can 
accomplish this with off-the-shelf parts.  I'd suggest that path be explored, 
and then we can weigh our options.

-Justin

Reply via email to