Verifying the TLS certificates is half the problem. If we used an Intermediate CA the CA would have to deal with aunt tillies misplacing their certificates. This bears a huge problem.
If we wanted to use a IC we could try using an OTP over E2E. User would visit clients.xmpp.net/lost and enter their JID. Clients.xmpp.net would establish an E2E session with them and provide an OTP. They would copy and paste the OTP (probably quite huge) into the next page and be issued a new certificate. But that breaks if the client's password has been compromised. Maybe a 'tough luck, be more responsible' approach could be taken: no certificates for miscreants. Really, I have no idea how this would be solved. As for verifying the certificates. Using streams in streams and starttls has the allure that some clients may support this method somewhat non-intuitively. However, you may find that most of those clients would need to be updated to pay special attention to revocation lists. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Peter Saint-Andre > Sent: Tuesday, August 19, 2008 11:59 PM > To: XMPP Security > Subject: Re: [Security] TLS Certificates Verification > > Dirk Meyer wrote: > > Jonathan Dickinson wrote: > >> Requiring serverless messaging is a deceiving lure. > > It is not. That's link-local or zero-configuration networking, and it's > quite a popular technology (see XEP-0174, iChat's Bonjour mode, etc.). > > >> What if the client is behind a symmetric NAT? Or some NAT that > >> simply doesn't working with STUN (or ICE/SIP/whatever)? They can't > >> open a encrypted session? > > > > No, in that case they need the "help" of a server. IMHO the real use > > case for serverless messaging is in the LAN. Back to my application > > control using XMPP: I want to access my set-top box from other > devices > > in my LAN even if my DSL link is down. > > Agreed, this is an important use case. > > >> If there is a XEP that defines a stream in a stream (I think there > >> was), one would open a new stream to a remote contact and simply do > >> a starttls. In the case that both clients can be accessed (if they > >> are behind a supporting NAT, or have a public IP) they can open the > >> stream to each other directly and do a starttls. > > > > That is the basic idea of XEP-0247 with the help of XEP-0246. We > either > > use serverless messaging or XEP-0247 to open a "connection" to the > > peer and use XEP-0246 to open a new stream and use starttls. The > > question we had (and that is the reason I started the discussion) is: > > how to verify the TLS certificates. > > Thanks for bringing the thread back to the original topic. We had some > discussions about this at the XMPP Summit in Portland a month ago, but > no hard conclusions. There's no stable JID (you have a link-local > address) but perhaps the certificate could also be tied to a stable JID > and you form an association between the stable JID and the link-local > JID. > > /psa
