Bill Frantz <> writes:

>So my reaction is to say that it's all a big stinking pile and try to develop
>systems and procedures that don't rely on CAs. (e.g. curl with a copy of the
>server's self-signed certificate, the Petname toolbar, etc.)

The problem with this is that recent changes in browser UI (particularly in
FF3) make it really, really hard to work with anything but cert-vending-
machine certificates.  It could be argued that of all the (public) CAs out
there, CACert is the most trustworthy because they're the only one not
motivated by money to crank out as many certs as possible as cheaply as
possible (although the last time I checked they also do email-verification-
only certs, so it may be more a theoretical advantage than a real one).

Of course with the universal implicit cross-certification present in browsers
this is all a moot point because the whole thing is only as secure as the
least reliable, least digilent sub-sub-sub-CA in the whole dogpile (insert
Matt Blaze PKI quote here).

>If SSL/TLS had as part of its handshake, a list of CAs that are acceptable to
>the client, I could configure my browser with only high-reputation CAs.

Uhh, how is that meant to work?

In any case even if it did, every time you went to a site using a cert vending
machine not on your list the browser wouldn't let you connect (or at least not
without serious amounts of messing around, which means that eventually you'd
add it to your list just to get rid of the nuisance).

This is unfixably broken.  We've been trying the same broken thing for fifteen
years now and it still hasn't started to work.  The solution is to look at
alternatives like mechanisms that protect relationships (challenge-response
mutual auth like TLS-SRP and TLS-PSK), not a nonfunctional mechanism which,
even if it worked perfectly, could only protect mostly-meaningless names.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to

Reply via email to