Some discussion:

<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.
<wjt> *ServerTLSConnection?
<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”
<sjoerd> hrm
<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
<sjoerd> nod
<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
<stefw> s/connection/handshake
<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 ?
<stefw> yes
<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'
<wjt> right
<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.
<sjoerd> nod
<wjt> okay, so this sounds like a plausible strategy

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/143.