CDR: Re: Public Key Infrastructure: An Artifact...

Bram Cohen bram at gawth.com
Mon Nov 20 14:11:58 PST 2000


On Mon, 20 Nov 2000 Lynn.Wheeler at 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





More information about the cypherpunks-legacy mailing list