Support client certificates on XMPP connections. This would be built around gtls and use its client certificate support.
<wjt> sjoerd: hey, stefw and i are just chatting about how client certificates might work
* stefw thinks that ServerAuthentication is for server certificates, not necessarily for client ones.
<stefw> oops, yeah right, that one :)
<wjt> sjoerd: IIRC you had some ideas about this?
<sjoerd> not about client certificates, we had some ideas about channel binding though
<wjt> sjoerd: i'm not sure at which point the client certificate would get poked into Gabble — a pre-connection ServerAuthentication channel, with Gabble (or Wocky) handling SASL EXTERNAL internally, maybe?
<sjoerd> but that's different
<-- lamalex has quit (Quit: Ex-Chat)
<sjoerd> have an interface on Channel.Type.ServerTLSConnection for it?
i don't know what the ordering is tbh
<sjoerd> stefw: how do client certificates work, does the server first give you its certificates and then you give it yours or ?
<stefw> no, you start off a handshake with the client certificates.
<sjoerd> right, so client-first
<wjt> yeah, there could be an interface on ServerTLSConnection for it. Either way, we need a way for the CM to know whether or not a UI is going to offer a cert
<stefw> the gtls model is that if you got it wrong, then the handshake happens again.
<wjt> we could have a connection parameter which means “i've got a client cert for this account”
<wjt> and then have the ServerTLSConnection channel pop up early with an extra poke-in-a-client-cert method?
<sjoerd> if it's client first it shouldn't be a ServerTLSConnection really
<stefw> sjoerd: no the client certificate is generally requested by the server as part of the handshake
the server sends the DN's it'll accept.
<sjoerd> because that assume it has the server certificate by the time it pops up
<wjt> that's true
there could be a new channel type
<stefw> but that's irrelevant, since we should probably use this disconnect-and-try-again model.
<wjt> which could pop up, and if there's no client which handles it MC will Close() it
<wjt> and then the CM would just start the TLS session without a client certificate
<sjoerd> pop up a channel saying: Do we have client certificates for these DNs and then it pokes it in indeed
<stefw> sjoerd: wjt: but in many cases we won't really know which client certificate to send until a connection has already happened.
<wjt> but if there's a handler for Channel.Type.TLSClientCertificate, that handler can decide yay or nay
<wjt> sure, the handshake can start
and if the server asks for a client cert, we can pop up the channel
if the channel gets Close()d with no cert, the CM can tell the server “sorry, don't have that”?
<stefw> wjt: technically yes, but if we're going to use gtls that would require changes to the API.
although we can try and push for those changes.
<sjoerd> stefw: so how does gtls ask for client certificates ?
<stefw> it makes does one handshake, sees that the server wants client certificates, disconnects, then fires off the signal
when it gets its client certificates, it does another handshake.
<sjoerd> by disconnect do you mean, it closes the tcp connection completely ?
<wjt> interesting strategy
<sjoerd> also, makes me sad
<stefw> it seems a bit broken to me
<wjt> and by interesting, i mean broken :)
<stefw> because the server can either request or require client certificates
the gtls model works okay with 'require'
<stefw> but not so well with 'request'
<sjoerd> looks like we should fix gtls
<wjt> yeah, i'd vote for fixing gtls
<stefw> yeah, dan said it was very complex
<wjt> and then we could pop up the channels as needed
<stefw> but i think it's worth getting this right.
<wjt> okay, so this sounds like a plausible strategy