Public Key Infrastructure: An Artifact...

Ben Laurie ben at algroup.co.uk
Sat Nov 18 13:47:00 PST 2000


Lynn.Wheeler at firstdata.com wrote:
> 
> 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.

How on Earth does that help? The key is already strongly linked to the
domain name - registering it with NetSol (for example) does nothing
interesting except to create another spurious revenue stream for NetSol.

> 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.

Medicate? What?

> 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).

And the benefit of that (apart from lock-in) would be what?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff





More information about the cypherpunks-legacy mailing list