Lynn.Wheeler@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

On Sat, 18 Nov 2000 Lynn.Wheeler@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.

To be fair, this sort of attack is much more involved and must be planned much farther in advance.

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.

This would remove one of the more serious barriers to running an SSL site - the Verisign protection money. The problem with all of these things is that they are still based on creating an association between a domain name and a key, when in fact what you want is an association between some abstract concept of a counterparty which exists in an end user's mind (like, say, amazon) and the ownership of a machine that user's browser is talking to. Unless that problem is fixed, man in the middle is hardly made more difficult - for example, Mallory could break into some random machine on the net and steal it's public key, then hijack local DNS and when someone goes to amazon.com redirect them to amazon.hackeddomain.com, and then proxy to amazon.com - now even SSL says the connection is safe. -Bram Cohen