On Mon, 20 Nov 2000 Lynn.Wheeler@firstdata.com wrote:
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
This is mistifying to me - there are apparently enough in there that it *should* be possible for someone to purchase one or a few and start offering an alternate source of certs. Or has Verisign gone and purchased all of them already? What would happen if one of those private keys were found and made public? I suspect there would be a lot of lawyers and suing and claims of trade secrets made, with significant intimidation of anyone who dared make a cert for themselves rather than paying for one the way the good lord intended. It would, of course, result in no practical loss of security whatsoever, since man in the middle attacks never happen.
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.
Yes, getting the public key of the domain as part of the DNS lookup is better engineering all around. It would also be nicer for services like Akamai which spew out different IPs and for the same domain name, and are currently forced to use the exact same private key in every one of those machines.
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).
Revocation just plain doesn't work. The only practical solution is online verification. -Bram Cohen