== Why I want direct certificate checking instead of having to rely on CAs

The common SSL model is that you verify someone's good nature by
checking to see that their certificate is signed by an approved CA.
For example, if you are verifying that hosts you are connecting to
are approved you would make up a CA certificate, then make up a bunch
of host certificates and sign them with the CA certificate. When you
connect to a machine, you verify that its certificate is signed by your
CA certificate.

(Except that that's a simplification; you actually need to verify that
the certificate is signed *and* that some identifying information in it
is correct, such as the machine's hostname being the CN.)

The alternate approach is to directly check that each
host's server certificate is in your list of approved certificates
(and perhaps that it comes from the host that you expect it to). I
maintain that this is the better approach for situations such as host
verification.

The problem with the CA approach is dealing with bad certificates.
First, you need to use not just a CA check but CA plus [[CRL
http://en.wikipedia.org/wiki/Certificate_revocation_list]], because if
you just check for your CA signature the only thing you can do when a
host certificate is compromised is to change to a new CA certificate,
which invalidates *all* current host certificates. Unfortunately, CRLs
are not widely used in the wild, so they are not necessarily well
supported in tools.

Even with CA plus CRL you still have the risk that an attacker has
managed to get some signed host certificates of his own (whether
by quietly compromising your keys or by surreptitiously inserting
things into your processing pipeline). Since you do not have copies of
these certificates yourself (unless you catch one live during a host
verification attempt), you cannot generate CRL entries for them; if
you think this may have happened, your only recourse is to change your
entire CA certificate.

By contrast, directly checking that you know each host's server
certificate is much easier and more direct. You have a complete
list of what certificates you accept and who you accept them from.
If a certificate is not there, you *know* it will not be accepted;
invalidating a bad certificate is as simple and precise as _rm_.

(Plus, you do not have to maintain and keep secure a CA signing setup.)

What this boils down to is that the CA approach is 'everything that
is not explicitly forbidden is permitted' (if it is signed by your CA
certificate it is allowed unless it is in your CRL), whereas direct
certificate checking is 'everything that is not explicitly permitted
is forbidden' (it is only accepted if it is in your list of good
certificates). The latter is a much stronger security model, plus
is easier to manage until you grow quite large.