as pure asside ... any SSL server certificate signed by any CA in my browswer's
CA list is acceptable.
for list of current valid signing CA's in a typical browswer see:
http://www.garlic.com/~lynn/aepay4.htm#comcert14
http://www.garlic.com/~lynn/aepay4.htm#comcert16
my broswer makes no distinction on which CA signed what ... and/or even what
they signed. If I get
a certificate signed by any CA in my browswers list that says foo.bar ... and I
think i'm connecting
to foo.bar ... then the SSL connection will go thru.
given that the supposed justification for SSL certificates is weaknesses in the
domain name infrastructure integrity ... and they beef up the domain name
infrastructure integrity (in part so that SSL certificate issuing operations ...
like any from the above list ... can rely on domain names not having been
hijacked) ... then it eliminates that as a business case & justification for SSL
certificates.
There are a lot of short-comings of the existing SSL certificate infrastructure.
To a large extent, most PKI definitions are purely hypothetical (there is the
line someplace, in theory there is no difference between theory and practice,
but in practice there is) ... trivial example is that most PKI definitions
include things like CRLs for dealing with revoked or compromised
certificates/private keys ... and yet the SSL infrastructure doesn't have any of
that in it (even tho client checking of server SSL domain certificates accounts
for 99.999999% of all such PKI operations that occur in the world today).
Ben Laurie