Peter Saint-Andre wrote: > Dirk Meyer wrote: >> Simon Josefsson wrote: >>> Each client generate an OpenPGP key for the user when she creates an >>> account. Instead of verifying a SAS in your example above, the users >>> needs to verify the OpenPGP fingerprint. If a SHA-1 hash is too >>> techno-babbly, a human-readable transformation of the fingerprint could >>> be used. >> >> Or we use TLS-RSP the first time and use that password to gain the >> trust. After that I know it is you and I know your OpenPGP key for the >> next time. This makes it possible to use a password only once and use >> OpenPGP after that. It could also auto-sign keys with a minimum trust >> level once I verified you with RSP. >> >>> Advanced users can configure the client to use their already >>> existing OpenPGP key if they want to re-use it for XMPP, which >>> allows for re-use of the existing web of trust. >> >> You could also sign your new key with the old one trusting yourself. > > Would we still need user keys and client keys?
I would prefer these two kinds of keys. If I have bots acting on my behalf I want to way to remove that trust once they gone bad, e.g. stolen or hacked. But that may be a special use case for bots... > One nice thing about OpenPGP is that we could re-use XEP-0027 for the > offline messaging case: > > http://www.xmpp.org/extensions/xep-0027.html ... for offline messaging we can assume it is the user key we need and encryt the offline messages with that key. I have to read some more details about OpenPGP and how to have several keys for one user. Maybe we use the "global" web of trust for the user keys and put all signed client keys on a pubsub server so you can look them up. Maybe we do not want our client keys to be in global keyrings either. My bank sends me encrypted mails on changes on my acount. For that reason my PGP key has a long password. I may care less about XMPP. I would hate to type in a password every time. And my bots sure need a key without password. But maybe the c2c user talk is completly different from c2c remote control. In my use case X.509 certificates and TLS-RSK seems to be exactly what I need, but I need a least sign all my client keys somehow (setting up a private CA is very complicated or can someone send me script doing that WITHOUT user interaction?). I agree that OpenPGP sounds better when creating a web of trust. I have some ideas how to fit that all into a userfriendly flow. I can write a XEP proposal about what happens on starttls tomorrow. But before I do that I have one question: can I add additional tags inside <starttls> and the <proceed>? Or is it a violation of the core? The tags would be completly optional so they won't break clients not supporting them. Dirk, going to bed now -- Work is the greatest thing in the world, so save some for tomorrow.
