Public Key Infrastructure: An Artifact...

[Lynn.Wheeler at firstdata.com]

note also that current SSL infrastructure is vulnerable to things like domain
name hijacking; aka, at least part of SSL protocol is to make sure that you
really are talking to the host that you think you are talking to ... i.e. the
SSL certificate contains host/domain name (all this, in theory because of
weaknesses in the domain name infrastructure) ... and when SSL goes to check
something in the certificate ... it is checking the hostname/domainname against
the hostname/domain name that the browser is using.

However, SSL-certificate issuing CAs have to rely on the domain name
authoritative infrastructure with regard to issuing SSL-certificates & domain
name ownership issues ... this is the same authoratative infrastructure that
supposedly can't be relied on and justifies having a the whole SSL-certificate
infrastructure to begin with.

In any case, the domain name infrastructure has been looking at ways to beef up
the integrity of its operation ... like having public keys registered as part of
domain name registration. Now, if domain name infrastructure is going to use
public key registration as part of beefing up its integrity ... that would
medicate  much of the justification for the SSL-certicate infrastructure.

Furthermore, if a higher integrity domain name infrastructure included public
keys in the domain name record ... clients could request a real-time, trusted
copy of the public key as a adjunct to host-name lookup.  This would further
eliminate the requirement for any certificate involvement in the majority of the
existing SSL transaction operation (i.e. client gets the public key at the same
time hostname resolution is done ... the client can trust a real-time
host/domain name because of the improvement in the domain name infrastructure
integrity ... and at the same time it can trust a real-time publickey for the
same host/domain).






Bram Cohen <bram at gawth.com> on 11/18/2000 11:15:38 AM