Peter Saint-Andre <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> Brendan Taylor <[EMAIL PROTECTED]> writes: >> >>> I've posted a description (with screenshots) of Gajim 0.12's end-to-end >>> encryption UI: <http://necronomicorp.com/lab/gajim-0.12-esessions-ui> >>> >>> I think it's generally a good model and would like to be able to do >>> something similar, whatever system we end up with. >> >> That's useful, it looks like a fairly good user experience. >> >> XMPP could use TLS and OpenPGP and achieve a similar user experience, >> here's how: >> >> Each client generate an OpenPGP key for the user when she creates an >> account. > > Or, presumably, a self-signed DSA or RSA key?
You mean a X.509 certificate? Sure. >> 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. 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. > > Right, or re-use an existing X.509 cert (some organizations issue the > latter to their employees) or obtain such a cert from a CA (e.g., the > one we run at xmpp.net). The difference is that there is no simple web-of-trust mechanism that allows client X.509 certificates to cross-sign each other. You can specify one, but then it begs the question why you don't use OpenPGP instead. >> Advanced clients could notice when the remote's OpenPGP key is already >> trusted via the web-of-trust, and then print both the OpenPGP >> fingerprint and the names of all keys in the OpenPGP trust path. This >> allows users to have more confidence of the remote identity before >> verifying the OpenPGP fingerprint herself. > > Right. > > As far as I can see, we would treat all of the following in roughly > the same way: > > - X.509 cert > - OpenPGP key Yup. > - DSA key > - RSA key Using raw RSA/DSA keys are often more complicated than it sounds: you need to invent several thing (e.g., naming, signing hierarchies, and algorithm agility) that is already done in OpenPGP and X.509. > Some of these might be more trusted than others (e.g., CA-issued cert, > OpenPGP key that's in my WoT), but all of them can be used to show a > fingerprint (or potentially SAS, or shared password a la SRP) to the > user. Right. > The first interaction might involve a leap of faith (in the case of > self-signed keys). Or if we can figure out a way to check fingerprints > with other trusted entities on the network (e.g., people in my contact > list), the leap of faith might be slightly less scary (e.g. this is > what some people do now for ssh -- ask the server admin who creates > your account what the fingerprint should be). Yes. I believe a leap-of-faith ssh-style approach for simplicity combined with a web-of-trust mechanism for re-use of earlier leap-of-faith assumptions would be ideal. /Simon
