On Fri Aug 22 16:22:54 2008, Jonathan Schleifer wrote:
If we have a CA, we need to warn for self-signed certs. But if we
do it like Firefox 3 - which some here considered the right way -
it will scare users away - they can't talk or won't use crypto at
all.
Fair comment - but that's assuming we have One True CA, which, in
practical terms, is very unlikely. Even within the Internet At Large,
where we have xmpp.net to give us free certificates, I don't think
users will want to bother with getting certificates signed the
majority of the time.
So CA-signed certificates would be the exception, and not the norm -
and planning for this reality will hopefully mean we don't fall into
S/MIME insanity.
Another problem is that a CA means a single point of failure. If
that CA is broken, someone can forge everyone.
Well, you do have to go some to completely subvert a CA. Assuming
that someone managed it, then I imagine there'd be a few security
updates going out, in quite a bit of noise, and to do it in a way
that the CA themselves didn't notice would be impressive.
Plus I don't trust CAs generally.
I can go along with this. That Peter chap who runs the xmpp.net one
seems a bit dodgy.
Seriously, though, X.509 PKI is used in-house in a lot of places, so
trusting the CA is a pretty reasonable thing to do in those cases.
With the big corporate CAs, there is so much cash at stake, an error
would be a disaster, so if the basis for your mistrust is that their
money-grabbing evil corporates, that's probably true, but plays into
your hands in this case.
So what's left?
* Self-signed keys
* GPG
* SRP
The problem with self-signed keys is that the fingerprint you need
to verify is very long and most users just won't verify it.
That's okay - fingerprint verification is just one option. You could
also - in parallel, in fact - do a number of alternate verification
methods, some of which could look very, very like the SAS used in
ESessions.
Actually, I suspect we'll see mostly leap-of-faith and CA. Asking
around Isode - and we're arguably a security-aware bunch of people -
it turns out we've all relied on leap-of-faith for the SSH key to our
primary firewall.
So whatever we do, we absolutely must ensure that client developers
are doing good leap-of-faith. (And if you do that, other verification
methods can take advantage of it).
The problem with GPG is that this is geeks-only.
Oh, if you do the whole Web Of Trust thing, it's really geeky. But if
you do leap-of-faith or SAS-a-like with it, it works equivalently to
the above - Simon was already suggesting this, actually, although Ekr
suggested some improvements.
FWIW, I suspect some geeky users will want to reuse their existing
PGP keys, but they'll be in a small minority.
The problem with SRP is bots.
I'm not convinced about SRP, for a number of reasons, not least that
SRP has seen vanishingly small deployment compared to the other two
methods, and it doesn't leverage any existing infrastructure.
So, I think we shouldn't concentrate on one of these. We should
have more than 1 way. For example, if we have SRP and self-signed
certs, we'd be fine. For bots, we could also add a CA so bots of
the same owner trust each other by just having the root cert.
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).
I'm assuming that during TLS handshaking, both sides can agree on
which of X.509 or OpenPGP to use, but I don't know if this could be
heterogeneous - I'd guess not, which would mean that you'd always
need to have an X.509 certificate to hand, but you might want to use
a OpenPGP key as well.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
