Jonathan Schleifer wrote: > See above ;). That's why I think a client shouldn't trust ANY CA by > default, but let the user allow to manually add a CA. This would be > interesting in corporations etc., you could just add the corporates' CA > then instead of verifying all fingerprints.
Agreed. Why should I trust some CA I do not know? >> FWIW, I suspect some geeky users will want to reuse their existing >> PGP keys, but they'll be in a small minority. > > Exactly. We can bother with the minorities once we have something that > works. First, we need something that works, then we can extend it. Yes. Only geeks sign keys and are part of the web-of-trust. If we have something that auto-signs keys it could be helpfull up to _one_ level: if we open a private channel and my XMPP client says that Peter (a person I talked to before) has verified your key, it may be ok. But if the app says: you know Peter and Peter knows Dave and he trust Eric which I trust .... hell no. Too many people in that list. >> Well, what makes sense to me is to have X.509 and GPG/PGP. I'd lean >> toward X.509 as MTI, and GPGPGP as a strongly-worded-MAY. Both these >> are supported within TLS, as I udnerstand things (which is, of >> course waaaay less than some here). > > But then we won't have something like SAS, which is absolutely > mandatory if we want it to be Average Joe compatible ;). Is it? You know, Average Joe is very stupid and does not understand the concept. Average Joe opens a secure connection using SAS. The connection is not secure unless they compared the SAS. My guess is that Average Joe will use THAT SAME channel: Joe: "Do you also see hfy7?" Aunt Lili: "Yes" Joe: "Great, secure channel!" Joe and Aunt Lili click 'secure' You know that this is wrong, I know it. But I'm very sure Joe and Aunt Lili do not. And I have a problem with such a string: how to verify it? It is easier to talk about a secure password before opening the connection. Dirk -- This file will self-destruct in five minutes.
